Hacker News Reader

Comment by GauntletWizard | Hacker News Reader

Stop using logging. You're using logging wrong and there is no using it right. Logging (unqualified) is for temporary debugging data. It shouldn't go anywhere or be aggregated unless you need to be debugging, and then it should go to the developer doing the debugging's machine.

Request logging should be done in a structured form. You don't need an indexing solution for this kind of request logging - It's vaguely timestamp ordered, and that's about it. If you need to search it, it gets loaded into a structured data query engine - Spark, or Bigquery/Athena.

Audit logging belongs in a durable database and it requires being written and committed before the request is finished serving - Logging frameworks that dump to disk or stdout obviously fail his requirement.

View on HN

Yes. And when a customer complains about an issue, tell them that your software has no bugs and they should reevaluate what they are doing, because obviously, nothing unexpected happens in your software and any trail of execution that would help developers figure out what happened is just for lamers (see also Go's stance against stack traces).

/s, if it wasn't obvious enough.

I hate software that fails silently because "you don't need logs". It usually shows that it was developed by someone who never had to act as a sysadmin and just never learned the value of good logs. Thinking anyone can predict all the possible ways a service can fail is misguided at best.

Even bad logs are better than no logs. Because at least, you can grep the source code for the log message and you have a starting point for debugging.

in addition to that, the absence of logs is useful information as well —customer swears they submitted the form? ok show me the request line…

I did not say "Don't log anything". I said "Stop using logging", and I'll qualify that (though my original post already did) with "So much". You're using logging for a to of irrelevant actions, and you're trying to sort needles from haystacks when you're better off not piling on the hay.

I agree with the sentiment but logging is incredibly simple to implement and is almost completely vendor agnostic (it's up to the log aggregator to make sense of the log file, not the software to output data in a specific format).

In addition, there's so much software that logs out of the box with limited support for metrics and traces it's not practical to ignore it.

In general though, I agree it's good to avoid if practical. Tracing is much more helpful in most cases especially when helpful context data is attached to traces.

> not the software to output data in a specific format

I like to output structured log anyway. Not JSON as it's not really human readable but at least in "logfmt" format[1] as it's both human readable and easy to parse.

FYI, Go provides `log/slog` which offers structured logging in both formats (JSON and logfmt).

[1] - https://brandur.org/logfmt

I more-so meant there's not a single, standard way. Lots of software uses logging libraries with arbitrary serialization formats but you generally need to take each schema into account (one software might use "error" while another uses "err")

Compared to OpenTelemetry traces (which many vendors support) that has standardized field names with the ability to attach arbitrary data

Reply on news.ycombinator.com