Add more logging to background jobs #2066
Conversation
|
I'm a tiny bit concerned about how much this will increase our papertrail log volume... the update_downloads task runs every 10 min :-/ We can change our papertrail settings to filter out those log lines, but then what would the purpose be? |
|
I think the additional log volume will be small compared to our web traffic logging. We can always scale it back if some of the lines end up being unhelpful. Mainly, I'm trying to investigate the occasional jumps in response times and while I don't think its related to background work, it would be nice to have timestamps to see the precise sequence of these events relative to web traffic. |
There was a problem hiding this comment.
This looks good to me.
We should consider using the log crate in the long run. It would give us control over log levels, e.g. making it easy to enable more verbose debug logging for the background worker temporarily to debug an issue. We are already using log in the server binary in a few places (e.g. here), which is a bit inconsistent.
I'm not concerned about the additional log volume. The update_downloads job will emit 432 additional log lines per day when run every ten minutes, and all the other changes combined result in less volume than that.
| match &*args.next().unwrap_or_default() { | ||
|
|
||
| let job = args.next().unwrap_or_default(); | ||
| println!("Enqueueing background job: {}", job); |
There was a problem hiding this comment.
When called locally without a command-line argument, the eror output isn't great, but I guess it's good enough – this isn't a tool meant to be used by many end users.
|
@bors r+ |
|
📌 Commit b32600e has been approved by |
Add more logging to background jobs r? @smarnach
|
☀️ Test successful - checks-travis |
r? @smarnach