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 90.32258% with 9 lines in your changes missing coverage. Please review.

Project coverage is 91.32%. Comparing base (fb06c99) to head (95a3234).

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

❌ Your patch check has failed because the patch coverage (90.32%) 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.32%   -0.03%     
==========================================
  Files         467      467              
  Lines       25761    25780      +19     
==========================================
+ Hits        23533    23543      +10     
- Misses       1810     1819       +9     
  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

[bogdandrutu]

With this people lose other settings (options of the logger). You need to use logger.WithOptions(zap.WrapCore(...){})

[djaglowski]

I've reworked logger creation to use WithOptions

[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.

[djaglowski]

This is defined both here and internally in component in order to avoid exposing it.