Should the logging exporter be renamed?

[codeboten]

Please vote in the comment below #7769 (comment)

[bogdandrutu]

Please call it "debug" :)

[atoulme]

Let's rename it before we mark the component away from development - See #7768

[atoulme]

If we rename, let's keep the existing name for at least 3 releases and offer a deprecation warning, this is used everywhere.

[codeboten]

Fwiw, we moved away from from loglevel back in october and users are still running into issues w/ this due to documentation floating around that uses the incorrect config. 3 releases may not be enough for this change

[atoulme]

Agree, let's use a year time then.

[andrzej-stencel]

I agree logging is not a good name for this exporter. This issue has been raised before, last time in Collector SIG meeting on December 21, 2022. Here are two related issues:

• Rename logging exporter to 'stdout' or 'debug' exporter in Collector #3524 from June 2021
• Standardize the name of logging/stdout exporter opentelemetry-specification#1931 from September 2021

If we do decide to rename, does it mean that rather than strictly renaming, we would need to create a new exporter under a different name that would be a copy of the current logging exporter, and deprecate the logging exporter? Possibly keeping the deprecated one "forever", or at least for a year.

[codeboten]

@astencel-sumo we could add a method to the logging exporter to make it instantiable under a different configuration option, something like #7773

[mx-psi]

This seems like another use case for #7631.

One question that comes to mind is how are ocb custom build users going to be notified of the change. Here are some possible approaches:

1. Deprecate the go.opentelemetry.io/collector/exporter/loggingexporter module and add some mechanism in ocb to notify users about deprecated modules
2. Handle this as a special case in the ocb code and add the debug exporter to builds if the logging exporter is present.
3. Handle this as a special case in the core Collector code instead and add the debug exporter to the list of exporters if the logging exporter is present.

I ordered them from the one I like the most to the one I like the least.

[DewaldDeJager]

1. Deprecate the go.opentelemetry.io/collector/exporter/loggingexporter module and add some mechanism in ocb to notify users about deprecated modules

I agree with this approach. I'm not sure I agree with wrapping one exporter from the other (as per discussions in the SIG meeting). The deprecated component should have no further development and users should be nudged to switch to the new component. The downside of this is that the code will be duplicated initially.

I also agree that it's a good idea for ocb to log warnings when trying to include any deprecated modules so that the distribution maintainers can look at replacing it. We should consider logging a warning about any deprecated components when the Collector starts if we don't have that already. This will help the distribution maintainers as their end-users will be nudged to move over to the new component.

[codeboten]

@open-telemetry/collector-approvers @open-telemetry/collector-contrib-approvers is debug the name we want to go with?

Looking through various otel repos, there's a few different names already for this type of exporter: stdout (https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/sdk_exporters/stdout.md) & console (https://github.com/open-telemetry/opentelemetry-dotnet/blob/main/src/OpenTelemetry.Exporter.Console/README.md) come to mind.

[TylerHelmuth]

@codeboten what problem does renaming the exporter solve? Are users getting confused thinking that the exporter write to a log? The issues @astencel-sumo linked are valid, but were not raised by end users. I am curious if we are proposing this because we don't like the name or if it is hurting users.

[codeboten]

This issue was raised as a result of the discussion in the SIG call 3 weeks ago to decide whether or not to rename the exporter. Based on the history in #3524, I would say we should not to this, specifically the comment here: #3609 (review)

My vague memory from the discussion in the call was whether we need to rename it before changing its status. If we agree that logging is good enough, then we can avoid doing the work here.

[jpkrohling]

Logging is confusing as, in the context of the collector, we have a logs pipeline and a logging exporter. I've seen users confused by that. During the SIG call, I remember folks also wanting to get compatibility rules for the output being generated by the logging exporter, meaning that they intend to rely on that, and they really shouldn't.

Renaming it to debug will make it clear what the exporter really is about.

That said, stdout is used in SDKs, so, perhaps that's a better name.

[mx-psi]

If we are going to rename it, I would go with debug. But to be frank, I don't see a future where we can get rid of the logging name with the tools we have today, the experience with #6334 shows that our users take a significant amount of time to update and adapt to deprecations. I think realistically the question is: are we willing to have to maintain compatibility with both names forever to do this change?

Personally, while I appreciate the arguments being made, I am starting to think that it's better if we keep things as is and don't do the renaming: it seems like the price to pay is too high.

[andrzej-stencel]

If we are going to rename it, I would go with debug.

I second that. If I saw a stdout exporter, I would think "oh, so like file exporter, but to stdout". If we make this change, we want to emphasize that this is a debugging tool, not a tool to export logs to a console or to stdout in a format anyone might want to rely on.

I agree this is a change that's easy to dismiss as it is not a "feature" and it carries a lot of cost.

At the same time, I believe that good names make a lot of difference. They make products more user friendly, especially to new users. Confusing names (can we agree that logging is a confusing name?) make onboarding harder and add to the cognitive load, making the learning curve steeper. The more quirks like this, the less pleasant it is to use the product also in the long run.

My recommendation is to mark the logging exporter as deprecated and leave it there for a year, maybe two years. I would copy its code and create a separate debug exporter that can then be independently developed, without making any changes to the deprecated code.

This will take a lot of time, but in two years, everyone will be hopefully using the debug exporter and the world will be a tiny bit less awful better. 😉

[codeboten]

Maybe voting on this is the best way to move forward? It feels like we could be stuck in this discussion for a long time without anything actionable resulting from it :) I would like to call out that at least one other language (java) calls the debug/stdout exporter a logging exporter as per the issue in the spec here.

What should we do with this exporter?

🚀 nothing, leave the loggingexporter as is and close this issue as a reference of the decision
❤️ rename to debugexporter and mark the logging exporter as deprecated for 1 year
👀 improve the loggingexporter to support additional functionality like allowing users to decide on the output format

[jmacd]

E.g., of additional functionality in the contrib fileexporter open-telemetry/opentelemetry-collector-contrib#22079