Inject component-identifying scope attributes

[jade-guiton-dd]

Description

Fork of #12384 to showcase how component attributes can be injected into scope attributes instead of log/metric/span attributes. See that PR for more context.

To see the diff from the previous PR, filter changes starting from the "Prototype using scope attributes" commit.

Link to tracking issue

Resolves #12217
Also incidentally resolves #12213 and resolves #12117

Testing

I updated the existing tests to check for scope attributes, and did some manual testing with a debug exporter to check that the scope attributes are added/removed properly.

[codecov]

Codecov Report

Attention: Patch coverage is 91.51515% with 14 lines in your changes missing coverage. Please review.

Project coverage is 91.54%. Comparing base (41a9ea7) to head (cf8fe64).
Report is 3 commits behind head on main.

Files with missing lines	Patch %	Lines
...nternal/telemetry/componentattribute/logger_zap.go	78.43%	10 Missing and 1 partial ⚠️
...al/telemetry/componentattribute/logger_provider.go	81.25%	2 Missing and 1 partial ⚠️

❌ Your patch check has failed because the patch coverage (91.51%) 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   #12617      +/-   ##
==========================================
- Coverage   91.66%   91.54%   -0.13%     
==========================================
  Files         479      484       +5     
  Lines       26355    26497     +142     
==========================================
+ Hits        24159    24256      +97     
- Misses       1733     1777      +44     
- Partials      463      464       +1     

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

🚀 New features to boost your workflow:

• ❄ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[mx-psi]

Does it make sense to add a log about this?

[jade-guiton-dd]

I don't think so. This is not an error condition, as logs are only exported with OTel if some processors are set in the config. When that isn't the case, we get a pure Zap-based console logger, and there is no Logger to set attributes on.

[jade-guiton-dd]

As discussed in the Collector stability meeting, I'm working on adding the attributes to the console logger output as well, which I think will require a core wrapper in all cases. I'll try to add a warn-level log if the wrapper isn't found.

[jade-guiton-dd]

In the end it was a bit tricky so I didn't do it, but I'm thinking relying on our tests might be enough? Since we have tests in componentattribute checking that attributes are set properly after multiple calls to ZapLoggerWithAttributes, and a test in service/telemetry checking that the instantiated logger is the expected type

[mx-psi]

I don't understand the 'console' in the name of this function. what does it refer to?

[jade-guiton-dd]

This is the Core used for writing to stdout (ie. "the console"), with the component attributes inserted as standard Zap attributes. This is by opposition with the "OTel Tee" core, which tees a console core with an OTel output core, which uses scope attributes. I can rename it if you think the terminology is unclear.

[mx-psi]

It seems to me that the function is agnostic to where the core is actually writing and console is just one of the use cases. I would have understood it better if console was not in the name and we clarified the intended use cases for each constructor in godoc comments instead

[jade-guiton-dd]

That makes sense. I'm not sure what to call it if not based on the use case though... Any ideas? zapCoreWithAttributes? attributesAsFieldsWrapper vs. attributesInScopeWrapper? (although the latter also has the Tee feature, so that might be confusing)

[jade-guiton-dd]

I added some comments to the different core wrappers to clarify what they do and the intended use, hopefully that should alleviate the questionable naming.