19 May 2024 05:25 PM - last edited on 20 May 2024 09:34 AM by MaciejNeumann
Based on my understanding, Dynatrace includes an X-Dynatrace Header in the format: FW4;-1042266361;6;1575832510;12;2;736415270;584;9420;2h01;3h5ded4bbe;4h0c;5h01;6h806a927b7e92492a0a04e33eb6a2e21e;7hba498fecda79dd3f in an HTTP Request. An API call in my service includes the X-Dynatrace header as part of the request headers (added by Dynatrace) and subsequently sends a Kafka event to a topic, which is then consumed by a consumer. The consumer further processes it and sends a response to a listener. Throughout this entire flow, the headers remain intact. However, I've encountered difficulty in mapping the X-Dynatrace header to a string on the consumer side, resulting in an unreadable format. Additionally, discussions in the thread on the Dynatrace Community suggest that there is no way to decode this X-Dynatrace header and the header may get lost, leading to breaks in the trace chain. Given this situation, is there any means to access logs pertaining to Kafka-based communication?
24 Sep 2024 04:21 PM
Hi.
I’m experiencing the same issue with Kafka + Gravitee.
Dynatrace adds a header to the messages that arrive in Kafka (via our Gravitee gateway).
The header is as follows: X-dynaTrace.
The problem is that the header seems to be encoded, and the Gravitee gateway (when consuming the message in webhook mode) is unable to interpret the content of this header, causing the process to fail.
Does anyone have a solution?
Regards,
26 Nov 2024 05:52 PM
Curious if you found anything here. We are running into a similar issue using Confluent Kafka. X-dynaTrace with an encoded value, that is causing the messages to fail and not be consumed.
27 Nov 2024 11:02 AM
You can refer the attached URL to the Firewall or F5 team to configure rules to ensure the highlighted headers aren't included in the traces :
Hoping it adds value.
BR,
Peter