Handling Complex Objects in OpenTelemetry Logs #4943
Replies: 1 comment
-
|
This is better reported/discussed in the OTel .NET repo. Also see if https://github.com/open-telemetry/opentelemetry-dotnet/tree/main/docs/logs/complex-objects helps. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Hello Team,
We are currently evaluating a migration from our traditional logging approach to OpenTelemetry logging in our .NET applications.
In our existing logging implementation, we frequently log complex objects (for example request/response models or domain objects). The logging framework serializes these objects so that the full structure can be inspected when analyzing logs.
While experimenting with OpenTelemetry logs, we attempted to add complex objects as attributes in log records. Our expectation was that OpenTelemetry would serialize or otherwise expose these objects so that the full structure could be viewed in exporters.
However, during testing we noticed the following behavior:
When adding a complex object as a log attribute, it does not appear clearly in the console exporter output.
Only primitive values seem to be visible in the console exporter.
It is unclear whether complex objects are expected to be serialized automatically, flattened into attributes, or handled differently.
Our questions are:
What is the recommended approach in OpenTelemetry .NET for logging complex objects?
Does OpenTelemetry expect developers to manually serialize objects (for example to JSON) before adding them as log attributes?
Is the console exporter limited in terms of displaying complex structured data?
Are there best practices for preserving structured data from complex objects so they can be properly consumed by observability backends (e.g., OTLP collectors, log storage systems)?
Example scenario (simplified):
logger.LogInformation("Processing request {@request}", requestObject);
Where requestObject is a complex model containing nested properties.
Any guidance or best practices for handling this scenario would be greatly appreciated.
Thanks in advance for your help.
Beta Was this translation helpful? Give feedback.
All reactions