18 ms·
The one about using print/console.log/whatever lol. I've always done this, never have I used a library for this, because: - running manually? >myapp.log 2>&
by linkdd 5y ago
The one about using print/console.log/whatever lol.
I've always done this, never have I used a library for this, because:
- running manually? >myapp.log 2>&1
- using systemd? use journalctl
- using docker/kubernetes? capture automatically the stdout/stderr of your containers and pipe them through logstash or something
Real question: why would an application need to know where its logs go? This is not in the business perimeter, but the ops perimeter. Am I wrong?
EDIT:
Most responses are about configuring logging level, output format, etc... This can be done with a print-based approach without sending a request to an external service (which would need to trust you and your inputs).
Example: Python's default logging module.
Still, thank you for your insightful answers :)
- progval 5y agoBuilt-in logging libraries offer more flexibility: you can set the log level of each module to avoid flooding your log files with everything's debug logs, for example. Or you want to write multiple log files with different settings. Also legacy; before systemd/docker/kubernetes, applications had to send to syslog themselves.
- randomNumber7 5y ago> Am I wrong? You are not a real Java Programmer then.
- dylan604 5y agoThank gawd for that!
- Sohcahtoa82 5y agoBeing a Java programmer without being a "real" Java programmer would be a feature, not a bug. Imagine being able to enjoy the Java syntax without feeling the need to write everything with a minimum of three levels of abstraction! Break free of the tyranny of getters and setters! Make that integer public! No more oppression from type introspection! Hang Spring and Hibernate from the gallows! The Java revolution starts TODAY!
- dijit 5y agoNot entirely wrong, but supporting log levels natively is a fairly decent “niceness” instead of parsing text to do it. Text, though, is a pretty universal interface and I would rather wrap a binary and stream it’s output than integrate a logging library natively. I did work with a product once that had local logs in a ring buffer and only shipped “important” logs to centralised storage, and that was nice but required context which can’t be easily gleaned from the content of a message.
- baskire 5y agoThere’s some scaling constraints using stdout with kubernetes. That logging load hits the kublet/control plane. This is an issue for those already pushing k8s up to the edge of its current scalability.
- iudqnolq 5y agoFor me the biggest nuisance is keeping multi-line logs together.
- remram 5y agoJust output JSON! Most log systems will happily consume JSON, and you can easily run it through `jq -r` if you want to read it in your terminal/vi/emacs or use grep. $ ./myapp &>myapp.log # Get error messages mentioning "foobar" $ jq -c 'select(.severity=="error")' | grep "foobar" | jq -r '.message'
- exabrial 5y agoThe real value is parameterized logging, sanitation of sensitive strings, logs per module, and automatic contextual value adds like function name, parameters, line number in the source code. Sysout is good for simple stuff, but a healthy set of audit logs (IE after every branch, and essentially replacing code comments with log statements) really cuts down on time needed to debug production problems. > This is not in the business perimeter, but the ops perimeter. That is a great point. Logging configuration should be provided at runtime, not compiled into the application. That's why most places provide the logging configuration as a runtime parameter.
- junon 5y agoI think you misunderstand the point of log4j. Logging is not free, and outputting to all three of those is quite expensive (especially in the Docker case, and it can even be dangerous as Docker - at least for a long time - did not implement proper backpressure and instead dropped logs). log4j allows libraries to implement logging and allow the end user to worry about where the logs go, at the application level, usually via config on the command line (e.g. modifying classpaths).
- zaphar 5y agoI'm not entirely sure libraries logging is a good idea anyway. I think there is a strong case that logging should be entirely an application concern not a library concern.
- watwut 5y agoThe libraries being able to log what they do helps a lot when debugging production issues. The application does not see inside cache library or hibernate or what not. They themselves being able to log what they do inside helps a lot.
- shagie 5y agoI've got a bug... the application that I've deployed isn't working in this configuration. It's not even hitting my controller for me to be able to log to a file. So, I kick the log level from warn to debug and I see that Spring is booting it because it failed a CORS check. This was much easier than trying to reproduce it in my local system and attach a debugger to it. There is a lot that goes on beneath and behind the code that a person writes within the libraries. I would contend that the log4j vulnerability is because people didn't realize the extent of what was going on beneath and behind. Making a developer blind to what goes on inside a library is not the answer. The "what goes on inside of a library" is indeed a concern for the application and the developer and should be made as easy to access as possible.
- zaphar 5y agoIs this partly due to the fact that everyone is depending on the libraries having logs instead of throwing the correct exception? Then the application could log it.
- pdpi 5y agoThere’s a whole enormous feature set that goes with Java logging that rapidly becomes a huge pain, but being able to easily adjust log levels on a per-class basis is a godsend for debugging certain issues.
- gwbas1c 5y agoSome log libraries allow user configuration of logging. Some configurations can be as mundane as altering logging levels when debugging; other configurations could redirect the logs away from text files to something that preserves semantics. But, depending on what your program is doing, printf/whatever can be "good enough." Coming from the C# world, one of the nice things about log4net is that it has a standard exception formatter, and callbacks whenever anything logs to error. This makes it easier to log unexpected errors and phone home when they happen.
- VWWHFSfQ 5y ago> pipe them through logstash or something logstash is also vulnerable to this though
- dangerbird2 5y agoFluent-bit/fluentd are written in C and ruby :)
- sz4kerto 5y agoImagine a large system that has lots of log.DEBUG statements in its code. If you turn on DEBUG logging, then it logs, say, 10 TB/day. This is a meaningful cost for most organisations, also it is hard to search. Also, you mostly don't need debug level logs. One thing e.g. a logging library gives you is that you can toggle log levels very granularly, e.g. you turn on debug logging for a specific class. Just one example.
- shagie 5y agoAnd with templates, you do log.debug("{} {}", var1, var2, someThrowable) and don't even call toString on those unless you're actually logging them. Compare this to system.err.println("DEBUG: " + var1 + " " + var2 + " " + someThrowable.stackTrace()) -- that creates a StringBuilder, allocates a potentially large String, and then sends it on. There are numerous performance impacts (improvements) at using a logging framework that doesn't log or allocate a String to log what it doesn't need to.
- formerly_proven 5y ago> Example: Python's default logging module. That's actually a log4j derivative, and imho quite bad.
- remram 5y agoYeah as a non-Java user I have to say I'm very surprised. I wouldn't recommend just using print(), but a library needs to do very little (format like printf, filter by level (maybe depending on source file), output to text or JSON). I don't understand how people would use a library as massive as log4j and not bother looking at what's in the box, and what they need to enable/disable. Blaming it on the opensource product seems weird when you grabbed it for free and didn't even read what's written on the box.