4 ms·
Couple of reasons - 1. You need to stick to compliance requirements. 2. Tracking individual transactions (user complains about $Problem - if you attach a reque
by mugsie 11y ago
Couple of reasons -
1. You need to stick to compliance requirements.
2. Tracking individual transactions (user complains about $Problem - if you attach a request ID to each request, and pass it between all components, you can find the exact problem for that request)
3. Building retrospective graphs is much easier when you have the data to hand, which you can them opitimise into a metric.
Logging is not the only solution, but neither is metrics / monitoring only.
- henrik_w 11y agoWhere I used to work, we had a great system for logging/tracing only sessions we were interested in, while not generating any output for all the other sessions. I wrote about it here: http://henrikwarne.com/2014/01/21/session-based-logging/ http://henrikwarne.com/2014/01/21/session-based-logging/
- mugsie 11y agoThat looks really cool! Will have a look at how we could implement it. One problem is that we run across multiple services, on multiple machines, so we would have to have some way of passing a customer ID into our AZ level logstash forwarders, and find a way of collating ERROR level logs, and sending those transactions up. We also have the problem of customers asking for retrospective issue debug, so having all the logs is useful.
- agopaul 11y agoI'm impressed by how only a few people mentioned what I think it's the main point of application/system logging: debugging problems. Especially in small projects when you don't work 'at scale and you don't have metrics. Am I the only one that stash GBs of low-level log messages in order to diagnose bugs that occurred in the past?