Logging Sucks - A review of challenges with logging (loggingsucks.com)
from chaospatterns@lemmy.world to programming@programming.dev on 21 Dec 19:54
https://lemmy.world/post/40523058

#programming

threaded - newest

calcopiritus@lemmy.world on 21 Dec 23:58 next collapse

Generally agree. Except:

Logs that are a “debug diary” are not useless. Their purpose is to debug. That’s why there’s log levels. If you are not interested in that, filter by log levels above debug.

Also, the different formats for fields I see as a necessary evil. Generally, more logs (of verbose log levels) = more good. Which means that there should be as frictionless to write as possible. Forcing a specific format just means that there will be less logs being written.

The json (or any other consistent format) logs seem to be a good idea, but I would keep it to a single debug level (maybe info+error?). So if you want to get wide events, you filter by these log levels to get the full compact picture. But if you are following a debug log chain, it seems a pain to have to search for the “message” field on a potentially order-independent format instead of just reading the log.

TL;DR

Log levels have different purposes, and so they should have different requirements.

public_image_ltd@lemmy.world on 22 Dec 00:34 collapse

Might be a stupid question but wouldn’t it be a good job for fucking AI to read these and tell you where the interesting parts are?

kippinitreal@lemmy.world on 22 Dec 00:59 collapse

LLM would be great to parse all that data, but I think you miss OP’s point. AI can be useful to automate mundane jobs, i.e. jobs you can’t get away from. OP’s point in my view is verbose logs are noisey & difficult to parse, because you’re logging everything unnecessarily. If you Log interesting things and mark them with context & logging levels, Then you can dive in as deep as you need, when you need. Why add complexity (& other hazards) of AI when you can fix the root of the problem first yourself.

DoctorPress@lemmy.zip on 22 Dec 00:37 next collapse

The site being interactive is cool.

azertyfun@sh.itjust.works on 22 Dec 01:03 next collapse

I don’t disagree with the point being made but I think the author is underselling the value of opentelemetry tracing here.

OTEL tracing is not mere plumbing. The SDKs are opinionated and do provide very useful context out of the box (related spans/requests, thrown exceptions, built-in support for common libraries). The data model is easy to use and contextful by default.

It’s more useful if the application developer properly sets attributes as demonstrated, but even a half-assed tracing implementation is still an incredibly valuable addition to logging for production use.

MonkderVierte@lemmy.zip on 22 Dec 04:44 collapse

Today, a single user request might touch 15 services, 3 databases, 2 caches, and a message queue.

And is the user experience any better?

cr1cket@sopuli.xyz on 22 Dec 06:56 collapse

Of course not. But the shareholder value!