opentelemetry-collector-contrib
opentelemetry-collector-contrib copied to clipboard
open-telemetry
[exporter/datadogexporter] Add logs support
Description: Add logs support for datadog exporter Link to tracking Issue: [issue] (https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/2651)
Testing: <Describe what testing was performed and which tests were added.>
Documentation: Will add examples in the follow up PR
Discussed with Dinesh via Zoom, here are the takeaways:
-
The vision is to intentionally drop the body of the log record, and instead just always send the log message as an attribute. The backend will automatically use the message attribute as the log message, even though the body was empty. The goal is to force customers to parse their logs before they reach the exporter. This is necessary because span/trace ID conversion won't work unless the logs are already parsed. For next steps he will improve the documentation and explanation of this, and collect feedback from customers during the alpha.
-
For the Severity issue, we are agreed to go back to prioritizing the SeverityText over the SeverityNumber.
I am OOO for the next few days so I won't be able to review this PR during that time.
I will leave the decision as to whether it makes sense to force customers to use a parser (otherwise the body will be discarded) to the OTel folks, as long as the message is ultimately sent with a body OR message attribute it should work from the logs backend perspective.
@djaglowski if you have a moment, would you mind sharing your opinion on https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/13987#issuecomment-1246998001 ? (picking you as the OTLP logs expert here 😄)
whether it makes sense to force customers to use a parser (otherwise the body will be discarded)
The data model suggests that the body should be a string. It is meant to represent the typical "message" that most logs have, so I would recommend handling this case.
If I'm understanding the alternative correctly, the parser you are referring to is only available within stanza-based components. Many users will ingest logs from other receivers (including OTLP, for example), so requiring customers to use a stanza-based parser will likely not be a good strategy.
@mx-psi @nhinsch i have added configuration whether to include body or not. I have also expanded the test cases. @djaglowski Thanks for the feedback .