Introduce log type field to point to a category of definitions used for log record

[thompson-tomo]

What are you trying to achieve?

I want to be able to set the type of log record I am emitting so that the log record can be transformed from the version specified in the schema url to the latest version.

Additional context.

By having the type field seperate from event name would mean that the event name can become fully qualified for that log record rather than pointing to the type.

Example would be https://opentelemetry.io/docs/specs/semconv/azure/azure-events/ has the name azure.resource.log but that doesn't tell you if it is for Entra ID, App Service etc with the proposal here being the type would be azure.resource.log & then name becomes something like Azure Log: {{service}} aka Azure Log: Entra Id. This would mirror spans.

This would also help with consistency.

If we were to increase the volume of definitions in semconv it would enable an increased chance of the name being fully qualified it does however have the trade off that the ability to transform events into metrics is decreased.

An example would be currently if you wanted to get a count of all azure operations which resulted in a result.type of failed, this would be straight forward as you just need to filter events based on result.type & the event name. If it is now split, this list of event name goes from a single value to a large list which must be managed. With this proposal we would have a field dedicated for systems to use for aggregation, querying & transformation.

_{Tip: React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[pellared]

Is there anything prevents you from using an Event Name that would become fully qualified? Maybe azure.resource.log should be divided into few events e.g. azure.app_service, azure.entra_id?

Consider adding more information in the issue.

[thompson-tomo]

The difficulty becomes what is the definition of fully qualified we should be aiming.

Is just identifying the service sufficient for fully qualified? if so it might work to define each and every variation in semconv but has trade-offs, see updated description. On the other hand does fully qualified mean also including the operation? In which case we would end up defining events similar to dynamodb but that brings more trade-offs.

The key thing would be type is designed for system processes whereas name is designed for a user to know what the event is capturing.

[svrnm]

@thompson-tomo @pellared bumping this up, thanks!

[svrnm]

bumping this up, thanks!

[lmolkova]

top-level EventName is designed exactly for this purpose - it fully qualifies event type within the SchemaURL (this can be guaranteed) and within all events (can't be guaranteed). In other words, when you query for all events with given event name, you should get only events compliant with the definition.

Closing this issue, please reopen if there is a specific concern that we can address in the spec

[hilmarf]

top-level EventName is designed exactly for this purpose - it fully qualifies event type within the SchemaURL (this can be guaranteed) and within all events (can't be guaranteed). In other words, when you query for all events with given event name, you should get only events compliant with the definition.

@lmolkova
Thanks for the clarification. I agree that a fully-qualified top-level EventName (scoped by SchemaURL) is a solid mechanism when you can guarantee consistent naming and schema adoption.

The specific concern I'm trying to raise (and why I'd like to request a reopen / re-evaluation) is that in real-world audit/security/compliance logging, operators often need a coarse, stable classification signal that is intentionally orthogonal to the fine-grained event definition. In heterogeneous environments (multiple teams, vendors, and evolving schemas), "just use a fully-qualified event name" tends to force one of two suboptimal outcomes:

Either you define an extremely large set of audit-related event names and keep that list in sync everywhere (routing, querying, retention policies, alerts).
Or you try to collapse audit use cases into a single "mega audit event", which becomes too broad to be useful.

What we're looking for is a standard way to say "this log record is an audit/security-relevant record" across many different event definitions and SchemaURLs, so it can be consistently routed, prioritized, and governed (e.g., retention/access controls, stricter pipeline handling, etc.) without implying that the OTel spec itself guarantees delivery semantics.

This also seems adjacent to the ongoing SemConv work around sensitive data / GDPR concerns and redaction guidance (e.g., semantic-conventions#128 and semantic-conventions#877): operators need consistent, machine-actionable signals to apply policy safely across many different conventions and instrumentations.

Would you be open to reopening this issue for a narrow discussion focused on whether a dedicated classification attribute (e.g., log.type, with a value such as audit) is appropriate — or, alternatively, what existing standard mechanism you'd recommend to achieve the same cross-schema classification outcome?

I've drafted an initial proposal PR to explore the shape of this in SemConv (on our fork): apeirora#1. Belongs to Audit Logging SIG open-telemetry/opentelemetry-specification#2409

Happy to adjust scope or wording to match what the Logs SIG considers the right direction.