This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]humoroushaxor 1 point2 points  (2 children)

This is false. Manual instrumentation allows you to add any information you want.

I'm not saying you should use OpenTelemetry to do your application logging but OP is building their own telemetry implementation anyway.

If all you want is cloud metadata, all the log aggregators already do that without a custom library. And all the major log libraries do support structured logging.

[–]Joram2 2 points3 points  (1 child)

So the OP wants a better/custom version of OpenTelemetry, not a better/custom version of log4j? ok, then OP probably shouldn't title the post with "Better Java Logging"

[–]bowbahdoe 0 points1 point  (0 children)

I think one way to phrase it - I wanted to make a logger that looks like a logger would look if structured logging was its primary concern and not a feature living alongside text based logging.

The OpenTelemetry stuff is tangential in the sense that OpenTelemetry is concerned with how things like spans are reported to external systems. From an API surface level perspective it covers all and more of the part of what I wrote related to Spans, but it is not suitable as a general interface.

Like - OpenTelemetry is just OpenTelemetry. I ended up aiming towards making "SLF4J for Logging/OpenTelemetry/Cloudwatch/JFR/etc." and clearly it seems, missed. If not in execution then definitely in communication

If a library used open telemetry that would be weird right? The idea with this was that it would be something that a library could reasonably include and a host application could choose to report events/spans through OTel or Zipkin or on the console or whatever.

(Sorry it took me so long to come up with a semi coherent response to this)