Avoid logging possible sensitive data at info or higher level (debug is ok)

[bogdandrutu]

Component(s)

all

What happened?

Describe the bug

In lots places we record some "useful" debugging informations, for example we enhance errors with information about what failed, see: https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/abaea0b69c2266c4c9d5e8fd1e6b95e9bf90da55/processor/metricstransformprocessor/metrics_transform_processor_otlp.go#L322 or https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/abaea0b69c2266c4c9d5e8fd1e6b95e9bf90da55/processor/metricsgenerationprocessor/utils.go#L251 and multiple other examples. These errors endup in logs, search for zap.Error usage and usually at Error level.

What did you expect to see?

I would like to make sure:

1. We have some rules about this.
2. We stop adding sensitive data to errors.
3. We stop logging (directly) any sensitive data at level equal or higher with Info which is our default logging level. For debug level we can record it.

What did you see instead?

No rules applied.

Collector version

all

[TylerHelmuth]

In this situation are the metric names sensitive?

[Arunodoy18]

Yeah , In this Situation i would introduce a Solution which might pass the Tests .I would like to Solve the Issue.
Cheers

[Arunodoy18]

Thanks for raising this — agreed this is important from a logging/security perspective.

I’d like to approach it incrementally:

1. Propose and document rules for handling potentially sensitive telemetry data in errors and logs (especially around zap.Error at Info/Error levels).
2. Update a few representative cases where errors currently embed metric/attribute values, and move those details to Debug logs instead.
3. Use these changes as a pattern that can be applied gradually across components.

If this approach sounds good, I’ll start with the examples already referenced in the issue and a small accompanying documentation update.