Introduce component logger with appropriate attributes

[djaglowski]

Implements the logger described in #12217

Alternative to #12057

Resolves #11814

component/componentattribute:

• Initializes new module
• Defines constants for component telemetry attribute keys
• Defines a zapcore.Core which can remove attributes from the root logger

service:

• Rebases component instantiation on attribute sets
• Internal constructors for attribute sets for each component type
• Constructs loggers from componentattribute

otlpreceiver:

• Uses componentattribute to remove otelcol.signal attribute from logger

memorylimiter:

• Uses componentattribute to remove otelcol.signal, otelcol.pipeline.id and otelcol.component.id attributes from logger

[codecov]

Codecov Report

Attention: Patch coverage is 86.90476% with 11 lines in your changes missing coverage. Please review.

Project coverage is 91.31%. Comparing base (fb06c99) to head (662c1db).
Report is 12 commits behind head on main.

Files with missing lines	Patch %	Lines
component/telemetry.go	0.00%	11 Missing ⚠️

❌ Your patch status has failed because the patch coverage (86.90%) is below the target coverage (95.00%). You can increase the patch coverage or adjust the target coverage.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #12259      +/-   ##
==========================================
- Coverage   91.35%   91.31%   -0.04%     
==========================================
  Files         467      467              
  Lines       25761    25811      +50     
==========================================
+ Hits        23533    23570      +37     
- Misses       1810     1823      +13     
  Partials      418      418              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[bogdandrutu]

Looking at usages (outside the service) the only think needed is Without(keys ...string) *zap.Logger

Can we do some golang magic, and actually public expose only an interface (rest of the implementation is in otelcol/service)?

The ideal scenario may be something that extend Logger, not sure if that works because Logger is a struct.

[bogdandrutu]

Here is where I got #12289

I don't have to expose public any interface. We will still need to expose the fields keys not sure where though.

[djaglowski]

I don't have to expose public any interface

I'm trying to incorporate your solution to simplify mine, but one consideration overlooked is that in practice we pass different kinds of loggers into tests, so we must make a type assertion to check for the Without method. If we're doing this, I think we need to at least give a name the interface so that components do not need to assert against an anonymous interface. The alternative would be to enforce somehow that tests use the same logger, but this is impractical IMO.

[djaglowski]

Similarly, for tests that do want to validate the functionality of the shared logger, they need to be able to instantiate a logger, so at least then you need to expose a testing logger which is very similar to the actual logger.

[djaglowski]

I was able to reduce the surface area of componentattribute but still think we need a constructor for the logger

[djaglowski]

I'm not sure how to avoid exposing this. It's used in component tests, and also in the graph when instantiating the loggers for components.

[bogdandrutu]

I would not couple this change with breaking the keys.

	zapKindKey            = "kind"
	zapNameKey            = "name"
	zapDataTypeKey        = "data_type"
	zapStabilityKey       = "stability"
	zapPipelineKey        = "pipeline"
	zapExporterInPipeline = "exporter_in_pipeline"
	zapReceiverInPipeline = "receiver_in_pipeline"

[djaglowski]

I'm not sure what you're suggesting

[bogdandrutu]

LGTM, few comments:

1. Need good comments when to use LoggerWithout, no comments at all now.
2. I think the attributes keys should be "semconv", maybe someone can start that effort before we change them. Also, I would not change them in this PR.
3. I think we can have the "NewLogger" in otelcol as private, for testing we can use a mock/fake core.

[djaglowski]

I think the attributes keys should be "semconv", maybe someone can start that effort before we change them. Also, I would not change them in this PR.

We went through a months long RFC process just to decide on these keys. Why wouldn't we switch to them immediately? That's the entire point of this PR. I can see the value of moving them to a xsemconv package instead but beyond that needs an explanation why your feeling about it overrides the RFC.

I think we can have the "NewLogger" in otelcol as private, for testing we can use a mock/fake core.

If it's going to be private and not available in tests, I think it can be in service/internal.

For testing, we should make it easy to validate certain things happen expected number of times. e.g. Logger is created once instead of once-per-signal, or log is logged once with correct attributes. Setting aside that a fake/mock core would implement mostly the same functionality as the actual, which package would expose this functionality so that each component does not need to write their own? componenttest?

[mx-psi]

2. I think the attributes keys should be "semconv", maybe someone can start that effort before we change them. Also, I would not change them in this PR.

This was discussed during the RFC #11406 (comment) resulting in open-telemetry/semantic-conventions/issues/1555. Quoting from the thread, this is the plan we are following:

Decide which prefix you want to use: "otelcol." or "otel.collector." appear to be your top choices.
Submit a request to get this added to semconv. We should be able to convince semconv group to accept it and I do not anticipate difficulties here.
You don't need to be blocked or wait until acceptance by semconv group, there is a ton of work that needs to happen anyway and replacing metric names should be trivial anytime before you declare them stable.

Therefore, I agree with @djaglowski that we should change them here and not wait for any semconv work.

[bogdandrutu]

Therefore, I agree with @djaglowski that we should change them here and not wait for any semconv work.

Sorry, maybe I was not clear. I am not suggesting to wait for that. Just that I was hoping to have a simple PR after this that only does the breaking changes/bug fixes: rename and use of the new API in otelreceiver and memorylimiter.

The main reason for that is to have clean changelog for that, and a simple enough change so that user can go to that PR and easily see what changed.

Happy to move forward with this way as well.

[bogdandrutu]

This is breaking change.

[bogdandrutu]

Since my feedback is mostly esthetic will let @mx-psi merge when he feels comfortable with this.

I can play later with componenattribute structure if you folks want to move faster with this PR.

[mx-psi]

Since componentattributes is a separate, experimental module, and the only addition to component is the LoggerWithout method, I think we can go ahead with merging this yes, and iterate on it.