Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Include db and handler context in all db-specific logging #3815
Diagnosing issues for Sync Gateway nodes running multiple databases is more difficult for log messages that don't otherwise identify a database. Including the database name in log messages in a standard way would address this.
Related, but not directly (so feel free to tell me to open my own ticket ;)).
Would it also make sense to surface the handler's serial number in log messages? I know we do something similar for BLIP to tie subsequent messages to their overarching connection/replication, but taking the changes feed for example:
Here the requests are actually the same (because I'm being lazy), but you have to make some inferences about which of the intervening lines relate to
Edit: I didn't notice at first, but the requests are so close together they actually get logged in reverse
I think this should be reasonably easy as most of the cases we care about this have access to the handler...
@JFlath I agree with the general motivation. We've already added additional user context logging to the majority of the changes log lines, so it's already a bit easier to differentiate between these in most cases, but I agree that directly connecting changes/cache level logging with the owning HTTP/blip request would have a lot of value. It probably makes sense to think about in the scope of this ticket, as it suggests a somewhat more verbose method to differentiate between db name, blip context, and HTTP serial numbers.