4 ms·
Very much (e.g. timing data, counts like success and error counts and operations should be metrics). If not metrics, then traces. If not metrics or traces, then
by partdavid 4y ago
Very much (e.g. timing data, counts like success and error counts and operations should be metrics). If not metrics, then traces. If not metrics or traces, then business events (e.g. like alerts, audit records). Almost everything that people put in logs actually belongs somewhere else, in my opinion. Which is evidenced by so much of log processing being about turning logs back into whatever it was they were supposed to be in the first place (metrics, distributed traces and business events).
- cpach 4y agoExcuse an old cave man, but in what way does traces and metrics replace logs?
- adra 4y ago"Operation xyz completed in 15.445 seconds." This can be expressed as a metric (or a trace) so that the "operation_xyz_completed" is a metric and 15.445 seconds is evaluated as a metric data point. The result is an easily chart to graph the average, p99, whatever of the operation to gauge if this is normal or exceptional. It's dead simple to alert on metrics as well often, so it helps to unlock alerting. Log alerts are valid but often more limiting without a bunch of parsing or being really naive.
- ilyt 4y agoWell, you usually want metric and trace of it, at the very least if it fails