Renovate/GitHub.com cloudfy azuremonitor 38432

[cloudfy]

Description

This PR attempts to address a potential solution for issue #38432 by handling the state of logRecord when compared to the semantic model. Its my first PR to this project, please comments for feedback.

Link to tracking issue

Fixes: #38432

Testing

make

Documentation

Azure Monitor Exporter documentation is updated to reflect and include the description of exceptions handling.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: cloudfy / name: CloudFy (4aafed3, 31e91eb, b28514b, c3561b8, 39fb50d, 7612d0c, 98825b5, fd5bcf5, aa16f31)

[atoulme]

CI will fail - see the cues in the build to address immediate issues. Thanks for the PR!

[cloudfy]

Reviewed the code review comments and addressed new review.

[hgaol]

Thank you for your contributions! Since this change will affect current behaviour, my general feeling is to align with azure-sdk. + @pcwiese to take a look.

[cloudfy]

@pcwiese - would live your view on this, and must admit @hgaol is right, behaviour will change as exception traces will be moved into exceptions table.

If a limiting factor is important, might solve the breaking change by using a configuration parameter?

Love you feedback, @hgaol thanks for highlight.

[hgaol]

Hi @cloudfy , here's the implementation in Azure Monitor OpenTelemetry Exporter .NET SDK for your reference. I think we'd better to align about handling log exception.

https://github.com/Azure/azure-sdk-for-net/blob/a708aadd8428d8cdf37a6d206683ac7599c00de1/sdk/monitor/Azure.Monitor.OpenTelemetry.Exporter/src/Internals/LogsHelper.cs#L65

[cloudfy]

@hgaol exactly - we've used the Azure SDK for logging before, but have to move to collector due to load. The collector however does not handle exceptions as the Azure SDK, which is why the PR (to align). I'll leave the team up to decide, but it does introduce a breaking change by handling exceptions into the right table.