Gotcha. I think we're probably thinking about different kinds of environments - probably the key differentiation is the total volume of logs, the kinds of services we're monitoring, and how bad a given error is.
> Having old logs around is awfully costly for the off chance that they help.
Depends massively on the log volume. I've worked at places that generated terrabytes of logs over the course of a few days, and required very large ES clusters to try to keep on top of it. There was definitely value in having those logs, but it only made sense to retain them for a couple of weeks. It's much less costly for low volume services.
> ...request tracing, which is different...
Ye-es, until it's not. If your current setup isn't yet developed or grown enough to have full request tracing, you can get a long way filtering aggregated logs by a correlation ID. I know it's no substitute for a fully feature tracing system, but in situations where you have limited resourcing you need to prioritise it can get you a long way
> If the problem doesn't happen again after you turn on logging, then the incident is over isn't it? The customer is no longer affected.
That massively depends on the impact of the incident, I think. If it's a "There was a problem playing this title, please try again" kind of deal, it's no biggie.
If it's a "my broadcast TV channel is off air" or "my financial system has crashed in an unexpected way trying to reconcile this transaction" type situation, you might be a little more worried - and the customer is likely going to be very upset for quite a while, and some people with very serious faces might come to talk to you about very large fines.