Standardize the name of logging/stdout exporter

[tigrannajaryan]

Different SDK and Collector use different names for the exporter which writes to stdout:

• Go: stdout
• Java: logging
• .Net: console
• Collector: logging
• Python: does not exist?
• JS: does not exist?

The spec says:

Standard output (or logging) to use for debugging and testing as well as an input for the various log proxy tools.

I think it is important to standardize on a name since it came up as an issue in the Collector.

Unless someone knows good reasons to choose a particular name I suggest that we vote for a name and stick to it.

[jkwatson]

Just FYI, Java has 2 "logging" exporters. One that is purely for lightweight debugging (and doesn't contain full span data) and one that logs full OTLP json.

[yurishkuro]

@tigrannajaryan to me there is a difference between stdout/console and "logging", as the latter is an abstraction layer with stdout being one of the possible implementations. E.g. in Jaeger SDKs we have "logging reporter" in all languages, but those are not even true "exporters" because all they do is log some readable string about spans (name, id), not the complete span data.

Standard output (or logging) to use for debugging and testing as well as an input for the various log proxy tools.

This is clearly underspecified because if interpreted as "export data to stdout in plain text" we still need to define the format of that plain text (e.g. JSON).

[pellared]

What about text exporter? Then it can be configurable to use different streams e.g. stdout, stderr or file. By default, it could be configured to write to stdout.

[yurishkuro]

@pellared I think my questions are:

• is is a true lossless exporter or a debugging facility like Jagger's Logging Reporter ?
• if it's a lossless exporter, what format of "text" does it print? If it prints "JSON" then why not call it "JSON exporter"?

[pellared]

@pellared I think my questions are:

• is is a true lossless exporter or a debugging facility like Jagger's Logging Reporter ?
• if it's a lossless exporter, what format of "text" does it print? If it prints "JSON" then why not call it "JSON exporter"?

• AFAIK it is "a true lossless exporter" everywhere.
• How about making the formatting/serialization configurable? By default, it could be JSON. But it could be simply json exporter to not overcomplicate.

[jkwatson]

What about text exporter? Then it can be configurable to use different streams e.g. stdout, stderr or file. By default, it could be configured to write to stdout.

In java, we would definitely want to use the standard java.util.logging APIs to implement this (as we are), and it has it's own configuration mechanisms for formatting and output which I wouldn't want to have to reinvent.

[tigrannajaryan]

• AFAIK it is "a true lossless exporter" everywhere.

logging exporter is not lossless in Collector. However, Collector also has a file exporter which is lossless and exports OTP/JSON.

So, it seems like we want to clearly differentiate 2 exporters:

• For debugging purposes. Output is designed to be human readable. No requirement to be lossless and machine parseable. Possible name candidates: logging, debug, console perhaps?
• For storage, transmission, etc. Output must be lossless and machine parsable. Possible name candidates: text, file perhaps?

[tigrannajaryan]

Just FYI, Java has 2 "logging" exporters. One that is purely for lightweight debugging (and doesn't contain full span data) and one that logs full OTLP json.

Same in Collector. logging exporter is human-readable, level of details is configurable and no guarantees that the data is represented in lossless format. file exporter is strictly OTLP/JSON text.

[tigrannajaryan]

This is clearly underspecified because if interpreted as "export data to stdout in plain text" we still need to define the format of that plain text (e.g. JSON).

I think this open issue should resolve that: #1443

[mtwo]

From the maintainers call: general agreement that this name should not be standardized across languages, as the names that developers expect are different across languages (C++ devs will expect 'cout', while .Net devs will expect "system.console").

However, we should also be careful that we distinguish between logs for debugging purposes (writing traces, metrics, etc. as logs to disk), and the actual first-class collection of application and infrastructure logs as a signal in OpenTelemetry.

[tigrannajaryan]

Based on Maintainer's SIG call I am closing this as "won't do". Feel free to reopen if you have additional arguments.