Logging sucks

Post by simonw » Sun, Dec 21, 2025, 10:51 PM UTC

willempienaar wrote: post #155

simonw wrote: post #126

I hope registering an entire domain name for a blog post doesn't become a trend. I like linking to things that are likely to last a long time - a personal blog is one thing, but expecting people to keep paying the renewal fee every year for a single article feels less likely to me. A good alternative here is subdomains, since those don't have an additional annual fee. https://logging-sucks.boristane.com/ could work w…

I kind of agree, but the message in this particular post does border on https://simonwillison.net/2024/Jul/13/give-people-something-...

Post by flockonus » Sun, Dec 21, 2025, 10:56 PM UTC

simonw wrote: post #126

I hope registering an entire domain name for a blog post doesn't become a trend. I like linking to things that are likely to last a long time - a personal blog is one thing, but expecting people to keep paying the renewal fee every year for a single article feels less likely to me. A good alternative here is subdomains, since those don't have an additional annual fee. https://logging-sucks.boristane.com/ could work w…

Post by hu3 » Sun, Dec 21, 2025, 10:58 PM UTC

wesammikhail wrote: post #125

Illniyar wrote: post #117

While I agree with some of it, I feel like there's a big gotcha here that isn't addressed. Having 1 single wide event, at the end of a request, means that if something unexpected happens in the middle (stack overflow, some bug that throws an error that bypasses your logging system, lambda times out etc...) you don't get any visibility into what happens. You also most likely lose out on a lot of logging frameworks you…

The way I have solved for this in my own framework in PHP is by having a Logging class with the following interface interface LoggerInterface { // calls $this->system(LEVEL_ERROR, ...); public function exception(Throwable $e): void; // Typical system logs public function system(string $level, string $message, ?string $category = null, mixed ...$extra): void; // User specific logs that can be seen in the user's "my hi…

  try {
    // handle request code
  } catch (...) {
    // add exceptions to log
  } final {
    // insert logs into DB
  }

Post by mnahkies » Sun, Dec 21, 2025, 11:00 PM UTC

khazhoux wrote: post #123

mnahkies wrote: post #56

That was difficult to read, smelt very AI assisted though the message was worthwhile, it could've been shorter and more to the point. A few things I've been thinking about recently: - we have authentication everywhere in our stack, so I've started including the user id on every log line. This makes getting a holistic view of what a user experienced much easier. - logging an error as a separate log line to the request…

> That was difficult to read, smelt very AI assisted though the message was worthwhile... It won’t be long before ad computem comments like this are frowned upon.

Post by m3047 » Sun, Dec 21, 2025, 11:06 PM UTC

Veserv wrote: post #61

otterley wrote: post #39

Earlier quoted context omitted.

> Logging is not metrics is not auditing. I espouse a "grand theory of observability" that, like matter and energy, treats logs, metrics, and audits alike. At the end of the day, they're streams of bits, and so long as no fidelity is lost, they can be converted between each other. Audit trails are certainly carried over logs. Metrics are streams of time-series numeric data; they can be carried over log channels or em…

Saying they are all the same when no fidelity is lost is missing the point. The only distinction between logs, traces, and metrics is literally what to do when fidelity is lost. If you have insufficient ingestion rate: Logs are for events that can be independently sampled and be coherent. You can drop arbitrary logs to stay within ingestion rate. Traces are for correlated sequences of events where the entire sequence…