@mattab
This is a performance improvement ticket.
- It is possible to disable piwik.php from tracking (ie. not select/update/insert) from the DB. See the Faq to enable the maintenance mode: http://piwik.org/faq/how-to/#faq_111
- When this is enabled, the webserver will return very quickly the transparent GIF. It will also log the piwik.php request in the apache server logs. It turns out this request contains (by design) the full set of information required by Tracking.
- We should provide a new CRON script that will, replay the piwik.php server logs every 1 minute for example. We could make use of Piwik Bulk Tracking features to import ie. 500 lines at once from the log.
Summary:
Power users will be able to setup Piwik where the Mysql is not required for tracking.
A script will run that will import, every N minutes (for example N=1 or N=60) the Webserver access logs into Piwik.
This script will use our log analytics tool to import the piwik.php requests.
It won't be as "real time" as before since loading logs is asynchronous, but could be set every 1 minute for near real time.
This will make Piwik tracking decoupled from Mysql, more resilient, faster, easier to scale.
Attachment:
piwikphp_import.patch
@anonymous-matomo-user
Attachment: Anonymized logfile with german data + umlauts
mysnip-stats.log-22-00.anon.gz
Thanks to Thomas Seifert who provides Piwik hosted, for this patch!
Thanks for the patch!
Code review/ TO Dos
- if 'cdt' parameter is found in the piwik.php request, do not overwrite it with the access log date, but forward the original 'cdt'
- same for 'cip': if found in the piwik.php? request, forward it and don't use log IP
- idem for 'ua' which should overwrite the log user agent
@cbay
Rather than doing the job in the Recorder class, I'd rather have it in the Parser class, as it's really a parsing thing. Basically, the parser creates a Hit object that has all required properties for the Recorder to use. I'll make changes so that the Hit object has an 'args' property where you can override anything you want.
query_arguments = urlparse.parse_qs(hit.query_string)
for k in query_arguments:
query_arguments[k]=query_arguments[k].pop()
query_arguments[k]=query_arguments[k].encode('raw_unicode_escape').decode('utf-8')This is not very Pythonesque. Don't modify the dictionary as you iterate over it; instead, create a new one:
query_args = dict(
(key, value.pop().encode('raw_unicode_escape').decode('utf-8') for key, value in query_arguments.iteritems())
)Why is it required to do the encode/decode? What format has the string initially?
This is not very Pythonesque. Don't modify the dictionary as you iterate over it; instead, create a new one
I know. As I already told to matt, my language of choice is PHP and for Python I'm just a beginner - you should really have a deep look into it :). I'd love to see what you make out of it.
Why is it required to do the encode/decode? What format has the string initially?
Well, the string is directly from the logfile and without that encode/decode I got garbled characters for page titles with umlauts in german.
Also you really should remove the return True in the beginning of check_http_error - I added it to get rid of some missing imported lines but from the code around it it can only be wrong.
One additional enhancement in my mind would be to skip requests being not piwik.php requests when the replay is enabled.
Could attach a log file with those umlauts?
I've just commited a small change that will let you put your code in the Parser, as I suggested: you now have a 'args' attribute in the Hit object that you can use to override your args.
Regarding the Unicode thing, I'm not 100% sure this is the best way to handle it but this is really not an easy one, as there are so many parameters to think about: the log file encoding, the HTTP encoding, etc. Are we sure we always have UTF8 at this point? Does it depend on Piwik? Anyway, if it works that way, go for it ;)
Send me your next diff when it's ready so I can make a proper review before it gets committed.
I wasn't aware ot that request / proposal, and I've already opened a topic on the forum.
http://forum.piwik.org/read.php?2,100735
Any update since 2 months ? I am also looking into this and it would be great to have the latest status of this ticket. Thanks !
see pull request https://github.com/piwik/piwik/pull/28
Reopening, pending:
- See pull request: https://github.com/piwik/piwik/pull/34
needs to be merged + tested + reviewed to ensure code is 100% correct - add integration test similar to importlogstest but only with piwik.php? logs
@diosmosis
Changeset [changeset:7e93e75012153e5f79d3bac98d9662e43b9df21d] refs this ticket.
In 5dca1a29bd36a17911406b9348cf9982484dbde9: Refs #3632, add integration test for import script replay tracking.
In 4b54ac17d0023323ab381062538b3bf584fe7ae8: Refs #3632, Remove stray debugging code.
In 4d7f93bec0bedd29ee74e003a0bff66b63587928: Refs #3632 More Code coverage for log importer using multiple site IDs
See new FAQ Scaling Piwik Tracking
In 73f33463b1bbf8e7e547edc4f80c0bc7d3198c19: Refs #3632 Adding more tests cases for log replay functionnality
Forcing all recorders and recorders max payload to 1, to prevent random behavior (eg. in Live.getLastVisitsDetails, the pageIdAction may be random order if recorders import data in random thread order)
In b6dfdc06e084f46668c679f0110e5a67146cef43: Refs #3632 test case that _idvc > 1 will set visitor returning status
In fd13666a79962545ac878e4a18d5909ac3923eb8: Refs #3632 Creating a test case: same visitor (same IP + idvisitor) visits the website on two different days.
Visitors on second day is marked as "new" because window_look_back_for_visitor is not set.
In 029bb8794fe24eeb08d52c1aa39d04c64a6496fd: Refs #3632 New test case: replaying logs and forcing a window look back (forceLargeWindowLookBackForVisitor=1)
=> The visitor is now marked as "returning" as expected
In 4328fd817349f70a2210f5e4a7fcd233c4e29387: Refs #3632 Small refactor and support parameter forceLargeWindowLookBackForVisitor=1 in tests when replaying tracking logs
In aae4433b390f4e5d1dee4a02ab63011b1f0d333c: Refs #3632 Check Engagement reports are properly set when replaying logs