open-telemetry
Decide what do do with event API / SDK
The event API and SDK have been removed from the spec in favor of extending the log API / SDK with those concepts.
There's also an open PR which would remove the emit event operation from the log API. As shared by @trask in the 1/9 java SIG, other prototype language implementers of events don't see enough value in having separate API and want to roll the functionality into the existing emit log record operation. From opentelemetry-java's perspective, our implementation of emit log record was not designed to be user facing, and is too easy to do the wrong thing from an events standpoint (i.e. accidentally omitting the very critical event name parameter). I am opposed to labeling our emit log record operation as the canonical way to emit events. There's an issue to potentially bring back a dedicated emit event operation later.
This domain is obviously still evolving, but we need to answer the question of what we do with our event API / SDK surface area in the interim. Some options:
- Delete the event API / SDK without a current replacement. Tell anyone that has been prototyping with it to move to emit log record, indicating that this is an interim solution.
- Delete the event API / SDK and add an equivalent user facing / ergonomic to ExtendedLogger in
opentelemetry-api-incubator. Essentially, we exercise our ability to have un-specified syntactic sugar APIs, and classify this new emit event operation as syntactic sugar. - Keep event API / SDK around until the spec gives us a user facing event API.
I would personally favor 1), and not try to pretend we have an end-user-facing Event API. When we have enough instrumentation built that uses events, we should have a better idea of what might make it ergonomically easier to do the right thing with Events, and the corresponding semantic conventions.
I fear that if we, as a community, don't come up with an easy-to-do-the-right-thing end-user facing Events API, the usage of Events will be restricted to those "in the know" about the details of how things are intended to be used. That would be a shame, as we have the opportunity to do something interesting here, and we seem (not java in particular) to be squandering that chance.
I would personally favor 1), and not try to pretend we have an end-user-facing Event API.
👍
When we have enough instrumentation built that uses events, we should have a better idea of what might make it ergonomically easier to do the right thing with Events, and the corresponding semantic conventions.
👍
@breedx-splk given opentelemetry-android's usage of the event API / SDK, I'm interested in what you think about this.
My preference would be to have an experimental Events API that makes things simpler/more convenient than what the logging api provides. I know I'm in the minority with this, which is fine...but I would definitely expect us to have a small event API in Android if there isn't one available in the core java api.
In the absence of an event api in otel java, I would also expect users and third parties to build their own bespoke event api that wraps the logging api...which is...unfortunate.
What about:
- Deleting the existing event API / SDK
- Letting @breedx-splk or whoever is interested sketch out an ergonomic, user-facing emit event operation on ExtendedLogger
This allows us to "close the door" on the prior iteration of event API (i.e. EventLoggerProvider, EventLogger, and SDK corresponding SDK implementations), and prevent giving the impression that these reflect the current direction of the spec. In particular, we need to get rid of code that produces events with event.name attribute, instead of the top level event_name proto field. But at the same time provides a scratch pad for ideas that might eventually resolve https://github.com/open-telemetry/opentelemetry-specification/issues/4357 and which accommodates opentelemetry-android.
Would it make sense to start by building an event API in the Android instrumentation repo, to work out the kinks "in anger", then move it here as experimental once it feels solid? That way @breedx-splk doesn't have to wait for releases for changes to propagate.
Oh I'm totally ok with us "closing the door" on the existing implementation...because I do see that as a way forward. Definitely not waiting on the Android side, we'll build a light thing as needed. Don't let me hold this decision up....I want us to move forward.