4 ms·

That's exactly what I'm railing against. You shouldn't be pushing all these things into the same stream and then separating them out again. You may want to make

That's exactly what I'm railing against. You shouldn't be pushing all these things into the same stream and then separating them out again. You may want to make it easy to generate a debug log when you generate an alert. You shouldn't do that by writing a log. You should have a very different set of parameters for If you're a bank, your login "Logs" shouldn't just be an annotated web request; you should have an explicit "AuthenticationSuccess" type in a non-ephemeral data store, and it should contain more than just "301 /auth 1.2.3.4", it should include information about the factors used to make that decision. Semi-structured logs don't have that, but will be abused to provide that. It should be a type system error to create an AuthSuccess without all that, not a set of default parameters to a generic logging call. Structured logging is great for moving fast, and I use it all the time to make it easy to filter through my debug logs, but levels are an abstraction in debug logs - and handlers are completely an anti-pattern

tptacek 4y ago
You've lost me, because the point of having a handler interface is exactly to be able to do things like ensuring that your "authentication success" events get stored differently than your debug messages. You can see upthread that the trend is kind of in exactly the opposite direction to what you're advocating for: plenty of people think there's no such thing as a log or an audit record, only "events", expressed as otel spans. Have fun with those people! :)