open-telemetry
Using logs to send crashes
The current implementation of the crash reporter feature relies on the use of immediately-ended spans to report crash events, this is most likely due to historical reasons since spans were available first in the Java SDK before log signals, so now that we have logs available, we should send standalone exception events using log signals.
Do you think that eventually this should just be an event? I think I do. Does it make sense to try and send the crash using logs while the events SIG is still getting the events signal sorted out?
Do you think that eventually this should just be an event?
Yes, it makes sense as an event.
Does it make sense to try and send the crash using logs while the events SIG is still getting the events signal sorted out?
I think it depends on how far away we are from getting events sorted out, if we had to wait for long enough that we'd get a considerable size of users in the meantime, I think logs would make more sense during that time to make the whole process (of both, adapting analytics tools to display errors in the meantime as well as migrating to events when they are finally sorted) smoother, for a couple of reasons:
- Spans are designed to cover a period of time and some vendors' analytics tools might have a dedicated UI to show them based on that assumption, if we go with spans in the meantime, this could mean having to add special validations for both, not displaying those types of spans in the "spans UI", and also to display those specific spans as errors (where some vendors might already have used logs in the past to report errors even before the OTel spec mentioned them).
- Regardless of the outcome of how OTel events should look like, their underlying signal will still be logs, so using logs in the meantime is taking a step further in the event's direction, which could considerably make the migration to the events spec smoother when it's ready.
Do you have an estimated ETA for when the events should be fully sorted?
Do you have an estimated ETA for when the events should be fully sorted?
Unfortunately no, and I think you do make a good point about logs and adoption. A span is definitely a more confusing and inappropriate signal in comparison.
Using spans for errors (exceptions) is odd, logs make much more sense to me, and it's semantically closer to just a raw exception. I do think the log should be connected/linked to the running span though, if there's a running span (not mandatory to have one as of now). As a user, I'd like to have spans and/or logs, If I don't want the spans perf. overhead, I'd need to be able to collect logs with errors regardless. If error events will be at some point part of the official protocol but this is far ahead, I think it's worth using logs right away.
Using spans for errors (exceptions) is odd, logs make much more sense to me, and it's semantically closer to just a raw exception.
I agree, although I also understand why it's like that right now, support for OTel logs was quite recently added to the OTel Java SDK so I'm guessing that, by the time this feature was created, spans were the only viable option 😅 but thankfully we now have logs available :)
Thank you for the clarification @breedx-splk, I think I should be able to create a PR on this change this week.
Sure, It's much better having errors as part of spans than not having them at all, just looking at the future :D