13 Feb 2023 06:23 AM - last edited on 13 Feb 2023 11:19 PM by MaciejNeumann
I'm surprised I'm not seeing the x-dynatrace header name in the "Supported semantic attribute keys" on the "Log Monitoring API - POST, ingest logs" documentation page.
Is it because Dynatrace relies only on the trace_id attribute to link a trace to ingested log lines?
I have logs from a backend service that I cannot monitor with OneAgent, this service receives requests with the x-Dynatrace header generated by an instrumented Android app. We asked the team in charge of maintaining this service that for each request received with the x-dynatrace header they write it in all the log lines that are generated by the treatment of that request.
Is there a way for us to enrich the logs with useful data from the x-dynatrace header in order to link the log lines to the trace originating from the first request (the one from the Android app) ?
@AymericM were you able to get any additional information on this that you could share with us?
@AymericM Dynatrace uses Trace ID and Span ID for correlating logs entries with distributed traces.
This means, that for displaying log lines in the traces you need either service (process) to be monitored by OneAgent or ingest OpenTelemetry traces from the application.
As your calling side is Mobile Appp, there is likely no Trace Context in the requests, only the X-Dynatrace header, which cannot be used for correlating to traces.
Trace ID will be generated on the first OneAgent monitored service in the service flow, so if you have some sort of reverse proxy or ingress that is monitored by OneAgent, you can have already the trace id generated and OneAgent can enrich the logs with trace context information. Can you provide a more detailed description of your architecture and situation?