@mattab opened this Issue on March 26th 2015 Member

The goal of this issue is to try make Safe mode catch all Fatal errors

Edit: this is was started, we now report when some requests were tracking into the wrong Site ID and /or missing token_auth (#13493)

Safe Mode is a nice feature that lets users disable plugins when an error was detected in Piwik. It suggests at the top the plugins to disable which are likely to cause the issue.

There were couple reports in the forums of Fatal errors where the Safe mode did not display and users wondered what to do next (in that case, the next step was to update a third party plugin on the marketplace). If the safe mode was displayed it would have let users disable the plugin and hopefully find the plugin update notice and update it. http://forum.piwik.org/read.php?2,125501

Maybe it's by design but I wasn't sure...

@tsteur commented on March 26th 2015 Member

Which PHP version? If I see this correct the linked Forum post is re Tracking where we do not display it.

@mattab commented on March 27th 2015 Member

Good point, it was in tracker and both users probably found it by looking at piwik.php?... output.

So the scope of this issue maybe is: "How to help users run a stable Piwik when a plugin creates a fatal error in Tracker mode?".

Maybe the "Log viewer" #7239 could help if those fatal errors in tracker are logged in our logger.

@tsteur commented on March 27th 2015 Member

Maybe they simply had a look at the logs on the server?

Log viewer might help, still one needs to have a look at it. Imagine the error occurs only on say 5% of the users (say only when IPv6, or only when from specific country, ...). One wouldn't really notice that and therefore probably also not have a look at the Log viewer. Maybe a daily status report (eg via email) could be something that contains eg the number of tracking request, the number of failed requests (with fatals), etc. There might be even better solutions...

We're surely not the first ones that want to report such problems re "background requests" etc. So there might be already good ideas / solutions out there. Haven't looked.

@jancbeck commented on March 27th 2015

@tsteur I'm one of the two users who reported in the forums. I noticed the error because piwik.php returned an "Internal Server Error" and because I include the tracker via javascript, it showed up in my browsers console. I then locked into Apaches error_log and found the error caused by the plugin. Hope this helps.

@fhemberger commented on March 28th 2015 Contributor

I had the same issue: I noticed there was absolutely nothing being tracked in Piwik starting March, 24th (so it seems to be related to the 2.12.0 release).

I didn't notice any "Safe Mode" hint in the interface, but I found this line in my logs:

PHP Fatal error:  Call to undefined method Piwik\IP::isIPv4() in piwik/plugins/IPv6Usage/IPv6Usage.php on line 96

PHP version is 5.6.5. Updating the plugin fixed it, but traffic of four days has not been tracked because of this.

@mattab commented on March 29th 2015 Member

Updating the plugin fixed it, but traffic of four days has not been tracked because of this.

(Btw in case you want to restore your days of traffic, you can import the server logs for those 4 days via: http://piwik.org/log-analytics/)

@mnapoli commented on March 30th 2015 Contributor

The log viewer could help if the admins visit Piwik. It could show e.g. with a notification/badge if there has been new log entries since the last time they checked the logs.

We could even have a log watchdog that emails admins in case of errors in the log file, but I'm not sure it would have worked in this situation since the watchdog would run in tracker requests and those where in fatal error.

@mattab commented on March 31st 2015 Member

Another case where a plugin not up-to-date caused Tracking API to fail: http://forum.piwik.org/read.php?2,125663,page=1#msg-125766

@tsteur commented on March 31st 2015 Member

Off-topic: We should maybe also be more careful when breaking API's (even if deprecated before) if it is potentially used by Tracker plugins.

An idea: As we build an analytics tool maybe we could even track failed requests and show them in the UI. So people could make use of features like Graphs (history), Insights, CustomAlerts (send an email if more than 10 requests fail) etc

@gaumondp commented on April 1st 2015

@tsteur : Sold for the "send email if more than 10 requests fail".

If not default(email), should be visible for SuperAdmin in the Web interface at least.

@mattab commented on June 23rd 2015 Member

Important: we do not want to only detect when Tracker fails because of outdated plugin, but also we want to detect when any error occurs during tracking. There are many cause of possible failures. For example we're investigating #7945 and the error is due to a broken client side library conflicting with piwik.js causing wrong data to come to the Tracking API. Piwik should in this case also somehow detect and report to Piwik super user that the Tracking API is mis-used and that some data was not tracked.

@hpvd commented on September 8th 2015

Awesome feature!

just some thoughts from https://github.com/piwik/piwik/issues/8732

Would be good if this feature would make it possible:

  1. to find actions e.g. events on your site which were setup faulty (e.g. a needed parameter is missing or...) and fire data to piwik which could not be processed
  2. having a "problem list" accessible from piwik backend, each user could bothering his site-admin to solve this... (and of course it's handy for admin too)
  3. catching problems in production environments without any problems (e.g. performance)
    because one could think of several problems which would not appear within a short testing period...
@mattab commented on September 14th 2022 Member

we can consider this was done in https://github.com/matomo-org/matomo/pull/13493 so will close this one

Powered by GitHub Issue Mirror