-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Azure Data Explorer Exporter - Missing Exception Fields from OTelLogs and OTelTraces #26496
Comments
Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself. |
Hello @akakarikos, Thanks for reporting. Will have a look and provide details about the missing attributes. |
If you are missing Exception, then its likely due to not being exported in the OTLP Exporter itself: You can verify that by using "OTel Collector Console" output, which would also be missing the Exception from Logs. |
Thanks a lot for the info @cijothomas that makes sense! You are right, the However, the Also there is the issue with the traces missing the Apologies in advance if I am missing something. |
The ConsoleExporter still exports Exception, but OTLP Exporter stopped doing it for the 1.6 stable. (Hopefully it'll be back in the 1.7.*) |
That looks like a bug in the ADX exporter, it does not seem to do anything with StatusMessage. Will let the owners triage that. |
Hello @akakarikos , Here is an update We're in the process of adding Status Code and Status Message attributes. The PR is here, will perform some tests track this for closure |
@ag-ramachandran Thanks. The span's statusmessage is a single string message, not attributes. |
Hello @cijothomas, You're right. Unfortunately we already had SpanStatus (which housed the StatusCode). Ideally this field should house the Code and Message as a KV or a JSON (in Kusto we could have a dynamic field, like the one we have for Link or Event attributes) We could say, we can add a field called SpanStatusMessage and alter that as a string in the table. The only thought we had has, in case there is some new attribute added the table could go wider again, where as if was a KV/JSON we could just add an attribute in While some of it is Kusto/ADX specific, this was really the rationale. What are your thoughts :) cc: @akakarikos , @asaharn thoughts BR,Ram |
I'd recommend this option. OpenTelemetry Span hasn't added new top-level fields to Span in years, so this should not be a concern. OR you can chose to make a breaking change and fix it. Agree it'll break users, but I am not sure if this component is declared Stable, so it's generally okay to make breaking changes. |
…es (#26682) **Description:** <Describe what has changed.> <!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> Added an optional column in the exported trace data to store the status code and message as a dynamic field. **Link to tracking Issue:** <Issue number if applicable> [#26496](#26496) **Testing:** <Describe what testing was performed and which tests were added.> Performed E2E ingestion tests and added Test Cases for new fields. **Documentation:** <Describe the documentation added.> --------- Co-authored-by: Ramachandran A G <ramacg@microsoft.com> Co-authored-by: Ramachandran A G <106139410+ag-ramachandran@users.noreply.github.com>
Hello @akakarikos , Is this something you can test and close |
Hello @ag-ramachandran and thanks for all the remediate actions! Looks good for now, If anything comes up, I will reopen the case. |
…es (open-telemetry#26682) **Description:** <Describe what has changed.> <!--Ex. Fixing a bug - Describe the bug and how this fixes the issue. Ex. Adding a feature - Explain what this achieves.--> Added an optional column in the exported trace data to store the status code and message as a dynamic field. **Link to tracking Issue:** <Issue number if applicable> [open-telemetry#26496](open-telemetry#26496) **Testing:** <Describe what testing was performed and which tests were added.> Performed E2E ingestion tests and added Test Cases for new fields. **Documentation:** <Describe the documentation added.> --------- Co-authored-by: Ramachandran A G <ramacg@microsoft.com> Co-authored-by: Ramachandran A G <106139410+ag-ramachandran@users.noreply.github.com>
Component(s)
exporter/azuredataexplorer
What happened?
Description
When there is an unhandled exception in the application and captured by an instrumentation library, the exception details such as exception message and exception stack trace do not populate in the Azure Data Explorer tables logs and traces.
To give you an example:
OTel Collector Console
ADX Traces Table
Application Console
ADX Logs Table
Steps to Reproduce
Force an application to throw an unhandled exception that will be caught by the OTel collector and exported to the Azure Data Explorer.
Expected Result
The exception details such as exception message, exception stack trace, and exception source are successfully exported in the OTelLogs and OTelTraces ADX tables.
Actual Result
The exception details such as exception message, stack trace, and source are not included in the OTelLogs and OTelTraces ADX table records.
Collector version
0.83.0
Environment information
Environment
Docker image deployed in AKS.
OS: linux amd64
OpenTelemetry Collector configuration
Log output
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: