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

Event identifier of an integer type #4278

Open
pellared opened this issue Nov 4, 2024 · 2 comments
Open

Event identifier of an integer type #4278

pellared opened this issue Nov 4, 2024 · 2 comments
Labels
sig-issue A specific SIG should look into this before discussing at the spec spec:logs Related to the specification/logs directory

Comments

@pellared
Copy link
Member

pellared commented Nov 4, 2024

What are you trying to achieve?

It may be good to allow having EventId of an integer type (instead of EventName which is always as string) for performance reasons.

Additional context.

In .NET the EventId is a integer with optional name.
https://learn.microsoft.com/en-us/dotnet/api/microsoft.extensions.logging.eventid.-ctor?view=net-8.0

Also see OTel C++:

Related to:

@pellared pellared added spec:logs Related to the specification/logs directory sig-issue A specific SIG should look into this before discussing at the spec labels Nov 4, 2024
@jpkrohling jpkrohling added the triage:deciding:tc-inbox Needs attention from the TC in order to move forward label Nov 4, 2024
@pellared
Copy link
Member Author

pellared commented Nov 4, 2024

I created this issue as I think it was brought up a few times.

My personal opinion, is that for sake of simplicity we should only have Event Name as string for the identifier. The reason is that it is the model of OpenTelemetry Events and not any possible event system/library/software. The OTel Semantic Conventions are using names.

@trask trask removed the triage:deciding:tc-inbox Needs attention from the TC in order to move forward label Nov 5, 2024
@trask
Copy link
Member

trask commented Nov 5, 2024

removed tc-inbox label since it's a sig-issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
sig-issue A specific SIG should look into this before discussing at the spec spec:logs Related to the specification/logs directory
Projects
Status: No status
Development

No branches or pull requests

3 participants