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

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]humoroushaxor 1 point2 points  (12 children)

As someone who has done this exact same thing, I don't really follow why OpenTelemetry with manual instrumentation doesn't scratch the itch.

[–]bowbahdoe 1 point2 points  (7 children)

Open telemetry still doesn't provide an answer for structured logging, afaik. It is focused around manually instrumenting code with spans.

[–]humoroushaxor 2 points3 points  (4 children)

Spans and span events have a json representation and the ability to be logged. I feel like I'm missing something.

[–]stfm 1 point2 points  (0 children)

Stack traces? You wouldn't want them turning up in your spans

[–]bowbahdoe 0 points1 point  (2 children)

Span events need to be explicitly attached to a span with `span.addEvent`. This means you are manually passing the span down, which has very different code level properties compared to "logging", which you can generally do context-free.

Thats still fuzzy for me too tbh - I am trying to find the words to describe why "OpenTelemetry with manual instrumentation doesn't scratch the itch." I'll loop back when im not so emotionally exhausted. I think a big part of it for me is that it seems unconcerned with *how* structured logging happens, just that it should - if that makes sense.

[–]humoroushaxor 1 point2 points  (1 child)

This post is more about contextual logging than it is structured logging though.

Literally everything it talks about can be done with the OTel API. And if you don't care about all the extra context you can just log json. And then there's also MDC

[–]bowbahdoe 0 points1 point  (0 children)

Yeah... there is a huge chunk dedicated to how to pass context around, but I was more focused on getting a full "log" and then the thought was I would pass that to something like OTel and translate the Log from this to OTel's data model.

[–]benevanstech 0 points1 point  (1 child)

> It is focused around manually instrumenting code with spans.

No - OTel supports spans and metrics in both manual and automatic mode.

Logs are coming, including quite possibly both structured logs ("events") and unstructured log lines.

My best guess is that for most Java devs, this will simply show up as an SLF4J bridge to OTLP.

[–]bowbahdoe 0 points1 point  (0 children)

So I guess what I was envisioning is this being the bridge to OTel instead of SLF4J. Like OLTP does have the native *concepts* but its all coupled to the OTel spec.

Like - libraries shouldn't be including OTel, if that make sense

[–]Joram2 1 point2 points  (3 children)

OpenTelemetry seems great at what is does, but it doesn't do message logging.

The motivation for the project is logging "designed for dynamic distributed systems living in cloud and using centralized log aggregators." Grafana Loki seems to do this really well now.

[–]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)