What should log integrations set Scope name to?

[tigrannajaryan]

Related to open-telemetry/opentelemetry-php#1049

Log integrations/bridges can set Scope's Name to the integration's name (e.g. "opentelemetry-log4j", "opentelementry-monolog", etc).

Alternatively integrations can see if the bridged library has a concept that is similar to our Scope and use it as the Scope name. Many logging libraries accept some sort of logger identifier or name when you create a logger (e.g. Monolog calls the concept a Channel, log4j has Logger name, etc). Should we use this value as the Scope Name when it matches conceptually?

@open-telemetry/specs-logs-approvers Which of these 2 approaches is the right approach? We need to have a recommendation for integrations/bridges.

[jack-berg]

I thought we had this conversation a while back and decided that the scope name should be set to the logger name (if it matches conceptually), since the idea of the scope name was heavily influenced in design from logger names.

Issue #1215 has more context.

[djaglowski]

Alternatively integrations can see if the bridged library has a concept that is similar to our Scope and use it as the Scope name. Many logging libraries accept some sort of logger identifier or name when you create a logger (e.g. Monolog calls the concept a Channel, log4j has Logger name, etc). Should we use this value as the Scope Name when it matches conceptually?

I understood this is the intended approach wherever possible.

However, if there is no conceptual match, is it then reasonable to use the name of the integration? I think so because it is then the most specific "source" of the log that we can ascribe.

[tigrannajaryan]

I thought we had this conversation a while back and decided that the scope name should be set to the logger name (if it matches conceptually), since the idea of the scope name was heavily influenced in design from logger names.

Issue #1215 has more context.

Sounds good. I was not able to find any corresponding recommendation in the spec. Do we have one? If not let's add it to the spec to make it clear.

[tigrannajaryan]

I think we have a contradiction here in the spec:

The log appender implementation will typically acquire a Logger from the global LoggerProvider at startup time, then call Emit LogRecord for LogRecords received from the application.

If the Logger is obtained once, at startup time then the bridge has to set the scope name to something static. The bridge cannot use a value that is only available when the log record is emitted by the logging library.

Now this is not a normative language and it says "typically" so we have some leeway here.

The problem is that I am not sure how the bridge can ensure the right scope name is used. Is the bridge supposed to obtain a new Logger for every log record it emits? Are we sure this will not have a performance impact (we don't necessarily design GetLogger API to be fast).

[jack-berg]

The problem is that I am not sure how the bridge can ensure the right scope name is used. Is the bridge supposed to obtain a new Logger for every log record it emits? Are we sure this will not have a performance impact (we don't necessarily design GetLogger API to be fast).

This is indeed how the implementation works in java. Here's an old PR where I describe that exact scenario and the importance of optimizing its performance, and here's another PR where I optimize the hot path.

[tigrannajaryan]

The problem is that I am not sure how the bridge can ensure the right scope name is used. Is the bridge supposed to obtain a new Logger for every log record it emits? Are we sure this will not have a performance impact (we don't necessarily design GetLogger API to be fast).

This is indeed how the implementation works in java. Here's an old PR where I describe that exact scenario and the importance of optimizing its performance, and here's another PR where I optimize the hot path.

@brettmc do you think you can also implement this in a reasonably performant way in PHP?

[Oberon00]

One potential problem when using (only) the logger name as scope name could be that there might be name clashes. For example, an application might use some abstraction to forward logging calls to different logging frameworks using the same logger name. Isn't this something that might happen in Java? I might have misremembered it though.

[mateuszrzeszutek]

Isn't this something that might happen in Java?

I think it's unlikely, but still possible -- especially in scenarios where multiple isolated classloaders are involved, e.g. webapps on application servers.

[tigrannajaryan]

One potential problem when using (only) the logger name as scope name could be that there might be name clashes.

What would be the effect of the clash? What's the problem? Isn't this exactly the same situation when e.g. a Java application obtains log4j loggers from different parts of the code but using the same logger name?

[Oberon00]

I was actually not thinking about different classloaders but different logging frameworks which might have different OTel instrumentations receiving calls from the same logger abstraction (one name). It may not be a problem. It just means that we must not use any scope attributes (e.g. actual instrumentation library name / instrumented framework name would be nice as a scope attribute, but might be dangerous then)

[tigrannajaryan]

@Oberon00 I understand. You are referring to the fact that our spec says:

It is a user error to create Loggers with different attributes but the same identity.

If different bridges try to create loggers with the same name AND also populate different attributes we end up with undefined behavior.