3 ms·
I really do not think that logs belong in any sort of database. Perhaps there is something I have not thought of? Structured logs (of course structured) in a
by worik 5y ago
I really do not think that logs belong in any sort of database. Perhaps there is something I have not thought of?
Structured logs (of course structured) in a simple text file. Rotate the files if your antiquated system cannot handle big files or if you wildly successful crypto currency scam generates many many gigabytes a time period.....
`grep` is your friend!
- chriswarbo 5y agoI like the idea of a simple SQLite DB, but agree it's a bit overkill. In particular, it increases the barrier to writing a log message (what structure/keys/etc. to choose?), which disincentivises logging. The accumulate-then-dump idea doesn't require any database though; just an in-memory buffer (e.g. a linked-list). For example, we can have all ERROR/WARNING/INFO messages output immediately, as is current practice. The difference would be for DEBUG messages: - Common practice is that if DEBUG is set then we'll output DEBUG messages as they're encountered; if DEBUG is not set then we'll skip over them. - The suggestion is that if DEBUG is not set, then instead of skipping messages the logger would put them in a buffer. If an unrecoverable error occurs, we can put a call like `logger.dumpDebug()` in the handler, so all those DEBUG messages will appear in the logs to help us diagnose the error. If no error occurs, the buffer just gets discarded. This obvious takes more memory, but fits well with a request/response setup like a server. Long-running applications/games could either use a ring buffer, or identify points where it makes sense to empty the buffer.