You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the 11/9 Log SIG we discussed whether it was appropriate for event.domain to be defined as an attribute in InstrumentationScope, or is more appropriate an attribute on LogRecord.
We reasoned that LogRecord is more appropriate as follows:
Because InstrumentationScope is a build-time concept, its not appropriate to InstrumentationScopes with the same name / version / schema, but different attributes.
Therefore, it wouldn't be appropriate to have a single InstrumentationScope emit events in more than one event.domain.
This means that emitting events in different domains requires you to emit those events in different InstrumentationScopes.
We did not intend event.domain to impact decisions about how broad or narrow a particular InstrumentationScope is. Perhaps the InstrumentationScope represents an entire application. It should be perfectly valid to emit events in different domains.
Conclusion: Move event.domain to an attribute on LogRecord.
The text was updated successfully, but these errors were encountered:
In the 11/9 Log SIG we discussed whether it was appropriate for
event.domain
to be defined as an attribute in InstrumentationScope, or is more appropriate an attribute on LogRecord.We reasoned that LogRecord is more appropriate as follows:
event.domain
.event.domain
to impact decisions about how broad or narrow a particular InstrumentationScope is. Perhaps the InstrumentationScope represents an entire application. It should be perfectly valid to emit events in different domains.Conclusion: Move
event.domain
to an attribute on LogRecord.The text was updated successfully, but these errors were encountered: