@diosmosis opened this Pull Request on December 30th 2018 Member

Fixes #8698
Fixes #8616

Tested in the following contexts:

  • web request (w/ warning/error all logs written to file log, only warning/error shows up in screen)
  • normal console command (fingers crossed handler not used)
  • core:archive top level command (fingers crossed handler not used)
  • core:archive climulti processes (w/ warning/error all logs written to file log
  • when a fatal error occurs

Also made following changes:

  • log more exceptions
  • make backtrace in logs include previous exceptions' backtraces
  • don't use screen writer if in CLI mode (so notifications don't end up on the screen when we don't want them to). could also add a check for trigger=archivephp.
  • always print backtrace if in CLI mode & trigger=archivephp

CC @tsteur not sure which milestone to put this in

@tsteur commented on December 30th 2018 Member

I'll put it into 3.9 for now. Can other plugins get all the logged messages during runtime? To send them eg by email

@diosmosis commented on December 30th 2018 Member

@tsteur added some more changes just now, might want to have another look.

Can other plugins get all the logged messages during runtime?

Not at the moment. We could create a custom FingersCrossedHandler that posts an event when triggered. Or the plugin could grep the logs using the current request ID (that's what I was thinking at first).

@tsteur commented on December 31st 2018 Member

when eg a fatal error occurs, we're sending an email during that request and looking through logs is not really an option as the log files could be many GB big. It would be great if there was some static method or some way to get the logger instance with all the log messages without using events (re performance).

@diosmosis commented on December 31st 2018 Member

I'm not sure there is a way to do that currently. I think FingersCrossedHandler will abandon the saved logs once they are flushed to the internal handler, so they're not all retained. I guess we can try to extend/modify the handler.

Will we ever look into something like loggly/cloudwatch/etc.? If the logs were more easily accessible to us, it might not be needed to have them attached to an email (just a request ID would suffice).

@tsteur commented on December 31st 2018 Member

We will likely look into CloudWatch eventually but we wouldn't send any data to a 3rd party.

I thought there would be maybe some logging handler or writer that could be put in between maybe?

@tsteur commented on December 31st 2018 Member

Also the goal is really to have all information directly in the fatal error email to have immediately all information.

@diosmosis commented on January 3rd 2019 Member

@tsteur Added the ability to get all logs in a request using a new handler. Also removed the INI config from global.ini.php and just check for them in code, so it's easier to remove if we find we don't need to include them later.

@tsteur commented on January 3rd 2019 Member

Also removed the INI config from global.ini.php and just check for them in code, so it's easier to remove if we find we don't need to include them later.

should we maybe create a follow up issue for 3.9 or 3.10 to enable it by default if our tests go well?

@diosmosis commented on January 3rd 2019 Member

should we maybe create a follow up issue for 3.9 or 3.10 to enable it by default if our tests go well?

Makes sense, will do so once this PR is approved.

@Findus23 commented on January 3rd 2019 Member

Will we ever look into something like loggly/cloudwatch/etc.?

It would be amazing if there was an easy way to get all Matomo errors/warnings into sentry.

I originally wanted to integrate Sentry into the Matomo monolog logger, but failed, so at the moment I am just using the default Sentry PHP error logger, which kind of works, but is incredibly hacky and probably doesn't show Matomo errors, just PHP errors and uncaught exceptions.
https://plugins.matomo.org/SentryLogger

Still, using (a self-hosted) Sentry to keep track of Matomo errors has been incredibly helpful as I can keep track of all errors I come across on the server and during development, can see if they occur regularly or just once, have them automatically grouped and see stack traces including all variables that were set during the exceptions.

Screenshot ![grafik](https://user-images.githubusercontent.com/6266037/50664320-ee668b00-0fac-11e9-8ecb-37d446a7a7c3.png)

So if there is any way (for a plugin) to get all errors and warnings including stack traces in Matomo to send it to Sentry, it would be really helpful for me (and guessing by the fact that nearly 500 people have downloaded the really specific plugin, probably others too).

Having better error backtraces sounds also really useful for debugging odd issues on the forum.

@diosmosis commented on January 3rd 2019 Member

Didn't know about sentry, if there are any issues w/ integrating w/ Matomo that I can help w/, let me know, will probably want to use that on my personal matomo instance ;)

@diosmosis commented on January 4th 2019 Member

So if there is any way (for a plugin) to get all errors and warnings including stack traces in Matomo to send it to Sentry, it would be really helpful for me (and guessing by the fact that nearly 500 people have downloaded the really specific plugin, probably others too).

@Findus23 Just read this, you could try creating a custom log handler. Exceptions will be in the 'exception' property in the context (see eg how ExceptionToTextProcessor uses the property). I think you could use \DI\add or \DI\decorate w/ 'log.handlers' in your plugin to add it. You won't be able to catch exceptions that aren't logged, but we should probably be logging everything.

Powered by GitHub Issue Mirror