3 ms·
Similar mindset as Grafana Loki took for log search, rather than indexing each field like many others do. https://grafana.com/docs/loki/latest/best-practices/
by Too 4y ago
Similar mindset as Grafana Loki took for log search, rather than indexing each field like many others do.
https://grafana.com/docs/loki/latest/best-practices/ https://grafana.com/docs/loki/latest/best-practices/
”don’t add a label for something until you know you need it! Use filter expressions and brute force those logs. It works – and it’s fast.“
Now I don’t advocate brute forcing text as a replacement for a database. But for filing cabinets, like logs with very unpredictable formats, that some admin will look at every once in a blue moon, those 500ms extra per query are nothing. Put it in relation to someone doing it completely manually.
- remram 4y agoIf you can already subset the logs by date and component, scanning the few thousands entries of interest is probably cheaper than maintaining indexes on many fields for all kind of imagined queries. The average-case algorithmic complexity doesn't matter if you can keep N low, even if you run the algorithm a lot.