Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking: Clarity and language around stand-alone Events vs. Span Events #695

Open
breedx-splk opened this issue Feb 6, 2024 · 6 comments
Assignees

Comments

@breedx-splk
Copy link
Contributor

Some of the discussion in #566 included concerns that the spec doesn't (yet) do enough to separate or clarify the distinction between stand-alone events (which happen to leverage logs) and Span Events. (See this comment in particular).

I'm opening this issue in hopes that we can continue this discussion here. Specifically:

  1. Do we need additional clarification that stand-alone events are different entities than span events?
  2. If so, do we need additional details about how they are different?
  3. Where specifically should we change language and make clarifying comments?
@yurishkuro
Copy link
Member

This isn't a semantic convention issue imo, span events defined in the spec / API.

@lmolkova
Copy link
Contributor

lmolkova commented Feb 7, 2024

I believe on the spec level we need to decide if span-events continue to exist on the API and/or proto level and this is not a semconv topic.

If the decision is to deprecate span events in favor of log-based events, we may need some temporary semconv (like otel.status_code) for back-compat story.

I don't see a good story in the semconv if both continue to exist. E.g. would we keep exceptions as span events, update them to be log events, or maintain two different conventions?

@meastp
Copy link

meastp commented Feb 7, 2024

I think an otel-collector connector to convert span-events to log-events and/or add log-events to span-events would be welcome. The reason being back-compat and some vendors visualizing the two events differently (if at all). Having the ability to transform these in a transition period would be valuable, imho.

@kenfinnigan
Copy link
Member

If span events were deprecated, would that mean anyone collecting only traces from their applications does not have the ability to capture events anymore? They would need to add logs collection to capture events?

@breedx-splk
Copy link
Contributor Author

This isn't a semantic convention issue imo, span events defined in the spec / API.

@yurishkuro I'm ok if this moves to spec, I'd just want @jsuereth to be ok with that as well, since he instigated.

@joaopgrassi
Copy link
Member

@jsuereth friendly ping - can we transfer this to the spec repo?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants