[jbreiding]

Logging should be treated as a source for events.

Most log collecting solutions have ways of producing metrics and alerts from logs.

It takes more discipline to be able to understand why a metric or alert happened without supporting logs.

Sourcing logs from multiple services, including dependencies, allow for creating more intelligent metrics.

Treat logs as a stream of events rather than noise created by developers and logs become more useful.

[pm90]

Strong disagree on this. Logs should serve a single purpose of allowing developers to introspect issues with their applications. If you want to generate an event stream, a more flexible and stable architecture would be to emit events deliberately.

Imagine you build all sorts of dashboards and Workflows on top of logs or log based metrics and the dev team changes the structure of the logs or just stops logging. Suddenly all your analytics is out of whack; this is because you created a hidden dependency.

[jbreiding]

I’m not sure about hidden dependency if the metrics break immediately. Important metrics should have alerts when absent or change unexpectedly.

Communication and the decision to depend on the logs as a source of metrics would be key to keeping these systems connected and functioning.

Taking a dependence on logs based metrics without communicating that is the failing here.

The same breakage could happen by depending on the event being emitted and a developer changing the event structure.

Communication and understanding helps both scenarios, not duplicating the effort by emitting logging for debugging, events for auditing and metrics for business.