These days, after a dozen or so years of dealing with log aggregation and other systems, I just suggest to all our engineers to log a lot less and use (opentracing or opentelemetry) traces and trace events where they would normally use logs. With fields added where you'd otherwise add fields to your structured logs. It really encapsulates all these best practices and then some, for collecting, filtering, and navigating telemetry.

The main exception I can think of is legacy systems that can't really be retrofitted with tracing. In which case you're probably not in a position to implement logging best practices either. I suppose audit is another exception, where you want a longer-term record of what's happened, but even there I think traces get you the much better story of what happened across your environment and you just need a better archival storage solution for them.

Logs and OpenTelemetry are not at all exclusive. One downside of straight-up OTel instrumentation is that id adds a certain overhead in the form of side-requests to the collector.

Most platforms/languages have logging built in, and it's perfectly possible to emit OTel-compatible log messages (like the linked article recommends) and collect them using some agent like Prometheus.

Well the thing is, you can get smart with OTel traces on both the client and the collector by implementing a smarter Sampler. Even something as simple as cached requests for the latest error rates that influence your sample rate can help you catch errors more effectively while limiting overhead and cost. These are things you could do in a logger but it's not part of the design as it is with tracing.

In general, logging is definitely easier and more ubiquitous, but there are a lot more "best practices" that you have to enforce vs simply having been built into the APIs like they've been with distributed tracing.