[pkg/otlp] Make debug section aligned with logging exporter

[mx-psi]

What does this PR do?

Make the otlp_config.debug section aligned with the logging exporter by supporting (slightly) the same settings.

Motivation

The logging exporter added the verbosity option on v0.63.0 to deprecate loglevel. In order to be aligned with upstream, we are adding support for it.

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

Test the Agent with the following setups:

• Set loglevel to disabled; check that there is no log mentioning the logging exporter and/or that no logs come up when sending metrics/traces. Example config for this:

otlp_config:
  receiver:
    protocols:
      grpc:
  debug:
    loglevel: disabled

• Do not set any debug section. Check that the logging exporter does show up on logs and that the logs come up in metrics/traces. Example config:

otlp_config:
  receiver:
    protocols:
      grpc:

• Set verbosity to detailed and send some metrics/traces. Check that verbose logs (including all details from payload) show up in the Agent logs.

otlp_config:
  receiver:
    protocols:
      grpc:
  debug:
    verbosity: detailed

Reviewer's Checklist

• If known, an appropriate milestone has been selected; otherwise the Triage milestone is set.
• Use the major_change label if your change either has a major impact on the code base, is impacting multiple teams or is changing important well-established internals of the Agent. This label will be use during QA to make sure each team pay extra attention to the changed behavior. For any customer facing change use a releasenote.
• A release note has been added or the changelog/no-changelog label has been applied.
• Changed code has automated tests for its functionality.
• Adequate QA/testing plan information is provided if the qa/skip-qa label is not applied.
• At least one team/.. label has been applied, indicating the team(s) that should QA this change.
• If applicable, docs team has been notified or an issue has been opened on the documentation repo.
• If applicable, the need-change/operator and need-change/helm labels have been applied.
• If applicable, the k8s/<min-version> label, indicating the lowest Kubernetes version compatible with this feature.
• If applicable, the config template has been updated.

[Kaderinho]

LGTM for ASC files 👍

[gbbr]

This is so weird and confusing given that the API for logging still contains the logging level analogous methods (or did that change too?) logger.Info, logger.Error, etc...

Is basic then warn level, normal info level, and detailed error level?

[mx-psi]

The levels are defined here: https://pkg.go.dev/go.opentelemetry.io/[email protected]/config/configtelemetry#Level

[gbbr]

LGTM, just a question to clarify. If you can link to an upstream issue in the PR description which shows how the verbosity config setting works (to better understand the transition), that would be helpful for posterity.

[mx-psi]

The issue where this change was proposed is open-telemetry/opentelemetry-collector/issues/5878, I just realized the examples upstream are not updated, I will open a PR for that. This issue was opened after open-telemetry/opentelemetry-collector/pull/5678, which was necessary to fix open-telemetry/opentelemetry-collector/issues/5652.

The TL;DR: because of limitations on the library used for logging we changed all messages to be at info level, so it now doesn't make a lot of sense to talk about loglevel.