Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When archiving fails with a SQL exception, also output the plugin name in the exception message to help troubleshooting #8600

Closed
mattab opened this issue Aug 19, 2015 · 3 comments
Assignees
Labels
c: Platform For Matomo platform changes that aren't impacting any of our APIs but improve the core itself.
Milestone

Comments

@mattab
Copy link
Member

mattab commented Aug 19, 2015

when running scheduled archiving, via the core:archive command, sometimes one of the sub-processes fails.

Here is an example error we got on production: ERROR [2015-08-19 16:06:42] Got invalid response from API request: ?module=API&method=API.get&idSite=191124&period=day&date=last52&format=php&trigger=archivephp. Response was 'a:2:{s:6:"result";s:5:"error";s:7:"message";s:32:"Invalid bind-variable name ':00'";}'

The challenge is that we do not know where this error was triggered. It could be in core, in a core plugin, or in any third party plugin used by this server.

Suggestion:

What do you think?

(adding to LTS since it will help troubleshooting very much!)

@mattab mattab added this to the 2.15.0 milestone Aug 19, 2015
@tsteur tsteur added the c: Platform For Matomo platform changes that aren't impacting any of our APIs but improve the core itself. label Aug 20, 2015
@tsteur tsteur self-assigned this Aug 20, 2015
@tsteur
Copy link
Member

tsteur commented Aug 21, 2015

BTW: I'd recommend to always keep the log on for archiving then it will be even easier to debug such things (writing to file only). Maybe we need the possibility to define different log writers for different areas (archiver, tracker, UI)...

@mattab
Copy link
Member Author

mattab commented Aug 21, 2015

BTW: I'd recommend to always keep the log on for archiving then it will be even easier to debug such things (writing to file only)

Oh, you remind me that in core:archive, when the API response was an error, it used to always include the backtrace. This way we knew, from the user/client report, directly the backtrace that caused the fatal error...

Maybe we need the possibility to define different log writers for different areas (archiver, tracker, UI)...

Not sure if I got your point, but it's true that we can make troubleshooting even easier, created this issue: When an API request fails during archiving (core:archive), output the backtrace in the error message #8616

@tsteur
Copy link
Member

tsteur commented Aug 21, 2015

My point is that you want log_writers = screen,file; log_level = warn in UI, log_writers = file, log_level=INFO in archiving and maybe sometimes log_writers=file, log_level=DEBUG when tracking to be actually able to trouble shoot things afterwards.

Logging is an important part of an application and it should be on by default, especially for archiver, and write to file. Just having the plugin name in the exception message won't help you much.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c: Platform For Matomo platform changes that aren't impacting any of our APIs but improve the core itself.
Projects
None yet
Development

No branches or pull requests

2 participants