[KaiserPro]

Shipping and diving logs is a bad idea for anything other than last line debug defence.

If you're going to agregate your logs, you're much better off converting them to metrics _on device_. it makes comparison much easier, and storage and pensioning trivial.

[marklar423]

I think a good compromise is having metrics that are always on, with the ability to enable more verbose debugging logs as needed.

[_kb]

It doesn't need to happen on device, just upstream of storage (and as close to the source as possible to minimise transport overheads). Most of the OTel collectors are good at this, but IMO Grafana Alloy is particularly neat.

This works for when you cannot change the log source too (e.g. third party component or even legacy hardware that may be syslog only).

[speedgoose]

I agree. I much prefer Prometheus and Sentry over logs.

[VBprogrammer]

Metrics are useless in my experience for figuring out a problem. For the most part they only tell you that you have a problem. Being able to slice and dice logs that you have faith in is critical in my experience.

[intelVISA]

problem_counter: 1

[_kb]

days_since_problem compresses better if you have long streams of '0'.

[KaiserPro]

Yeah you still need logs, but as a last line.

Metrics tell you when and what went wrong, but unless you've got lots of coverage, its less likely to tell you _why_