Hacker News Reader

Comment by linkdd | Hacker News Reader

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 :)

View on HN

I 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).

Also note that log4j comes from an era before everything was "cloud-native".

In the Java world before cloud-native we had application servers like Tomcat and JBoss which typically used something like log4j (log4j-core package) to configure what gets logged and where the logs should be shipped to. These application servers where shared and usually hosted more than 1 application. Hence the need to do contextual lookups (jndi and others) to determine log routing or enrich log messages with contextual information.

Applications or libraries running inside these application servers would only implement a logging api (log4j-api package) which is just a facade so every application can write implementation-independant logging and let the application server provide the implementation and configuration.

Now in the cloud-native/12-factor world, the industry has moved away from application servers (or embeds an app-specific server in the container) so it makes sense to just log to stdout and let the container orchestration handle log shipping and filtering. The former role of log4j is now mostly handled by Fluentd, Logstash, Filebeat and friends.

Log4j still has a place though: Having the ability to use ENV vars or commandline flags to influence log levels and packages is still a nice to have. And one feature that is often overlooked is the ability to set contextual information per request. For example authentication middleware can set a userId or requestId in the request context and every log message within the request handling automatically gets logged with that metadata, avoiding the need to pass all this contextual information manually in every log.info(...) statement.

I'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.

The 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.

I'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.

Is 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.

A program working correctly with incorrect input isn't an exceptional case.

"This endpoint cannot be accessed in a CORS improper way" is caught in the library/framework level and doesn't even touch my code - there's no exception for me to catch.

Throwing a checked exception for no access rather than returning "false" from a library call because you passed in all upper case on case sensitive role check would be a decision that I wouldn't agree with.

Another example would be "I want to see the sql generated by hibernate" - that's not exception throwing at all, its me trying to debug what the query is and why the performance is awful.

Have you never had to rely on logs from some JDBC library to figure out an issue in production? There are absolutely many reasons for a library to have logging, specially in the case of libraries providing tooling for anything that deals with networking (clients to any kind of services, serving requests through the network, etc.).

I think that an opaque library in terms of logging is absolutely hell to deal with, I already have my fair share of issues with libraries that don't do enough logging and require painful hours of debugging instead of reading a log...

Built-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.

Some 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.

The 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.

Yeah 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.

Not 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.

Imagine 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.

And 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.

> Example: Python's default logging module.

That's actually a log4j derivative, and imho quite bad.

Care to elaborate?

Not quite. Rather, its design was influenced by log4j, among others:

https://www.python.org/dev/peps/pep-0282/#influences

> pipe them through logstash or something

logstash is also vulnerable to this though

Fluent-bit/fluentd are written in C and ruby :)

There’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.

For me the biggest nuisance is keeping multi-line logs together.

Just 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'

> Am I wrong?

You are not a real Java Programmer then.

Thank gawd for that!

Being 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!

Reply on news.ycombinator.com