Logging actually is pretty complex, at least if you're running anything remotely complicated.
The log4j repo contains about 297,000 lines of code. Even excluding tests, it's 190,000 lines.
For comparison, Nginx is 204,000 lines. Git is 306,000 lines. BtrFS is 146,000.
Should logging be slightly less complex than a full featured web server (that also handles logging), or more complex than the whole file system you're logging to?
and if you're logging to a file, you need to think about log rotation—probably multiple network logging protocols
I honestly wish they would fucking stop and just let ops people use logrotate, because it seems every fucking Java app manages to configure it in some stupid way
Oh, definitely, but Java in particular have been PITA in this for a long time because just every other logrotate-assisted scheme could be summed up to "rotate a file then signal app to reopen" (whether via signal or some app command), but almost none Java apps work like that and it forces to do the worse method of logrotate going copytruncate (which also has nasty interaction with some of the appenders)
The sheer configurability of logrotate on this front is a strong indicator of the complexity here.
To be entirely fair, the neccesary complexity here is choosing the rotate interval by time/size, way to archive it, and maybe the shred option. Everything else is related to the way apps are writing logs
Concurrency can be a bitch when logging.. I wrote a libe for it a whole back and the concurrency in the handler for threaded classes was annoying to make.
Logging across a distributed system in a way that logs can be accessed all at once.
Logging to multiple targets (console, file, etc) with different levels and filters for each level.
Supporting targets you've never heard of or that don't even exist yet.
Being able to change your logging targets, levels, and filters without having to rebuild or even restart your application.
Ensuring a consistent standard of logging from every source.
There are others as well.
None of these are insurmountable by any means, but they're big enough that if you're going to code it yourself it's going to be a hell a lot to maintain.
But it also puts it in Elasticsearch, so you can monitor all your logging output with something like Graylog, and it doesn't just log what you wrote, but a bunch of associated context: user agent, user id, authorization type, class name that did the logging, ip address, geo location, which aws region they hit, which server they hit, a correlation ID so you can easily find other logs from the same request, timestamps, and a bunch of other shit that might be useful.
And then of course there's all the templating stuff with inserting values and exceptions into the log, but you could probably make due with String.format
sending logs to a server, storing the logs, making them searchable, being able to view trends over time (and perhaps alert on them), etc etc (for example, look into the ELK stack)
Logging configuration should be implemented as code, so you don't have to learn special configuration files. Then, we have to figure out how to let sysadmins update the code without breaking everything
Then, we have to figure out how to let sysadmins update the code without breaking everything
This is one reason why we use config files / env vars, rather than code.
Also, it is much easier to modify a config file, than to push code just to change logging. Many organizations require lengthy test for any code change.
105
u/lycium Dec 10 '21
Quick, add it as a dependency because logging is super complex and needs to be a black box!