RUM timeline are not align with chrome network waterfall; And RUM not work with Distributed tracing

The same request, but observe different metric in elastic APM RUM and chrome develop tools


total duration is: 1861ms
and duration for exahgne.json, symbol.json, data.json are the same, 197ms

picture 1:

Chrome Dev Tools

total durating is 4.77s
the most cost request is fetching symbol.json, which cause 3.34s

Not work with Distributed tracing

I have three service

but from picture 1 above, there one service in the transaction. They are not share the same parent trace id


Thanks for using Elastic APM.
Do you use polyfills in your application, for example for fetch or promises?
Also, would you please provide your configuration for the RUM agent?

Generally speaking we add a special, elastic-apm-traceparent, header to http requests to communicate the trace ID. However, it seems that these requests do not have this header. Can you please, check if this header is present in the dev tools network panel.
Also, Please make sure that the origin for these requests are added to distributedTracingOrigins config option, since we only add the header to http requests made to the these origins. This is only required if the request origin is different compared to the page origin.


1 Like

Thanks for answer, the problem is cause by distributedTracingOrigins, I didn't set this config options

By the way, If I have several service in backend behind a F5 device, how should I input the distributedTracingOrigins? put the F5 IP?


And I don't see the elastic-apm-traceparent header you mention above:

You should see the elastic-apm-traceparent header on the outgoing request to your own services (e.g. the request to GET /symbol.json), the request that is selected in your screenshot is to the APM server. I should have made that clear in my initial comment.

The important thing with configuring distributedTracingOrigins is to set the origin that is used to create the http request. On the RUM agent before each http request is send we check whether the origin of that request exists on the distributedTracingOrigins list, if so we will add the elastic-apm-traceparent header. In your case it seems that the requests are made to the F5 IP, therefore that should be added to distributedTracingOrigins. You can find more details on our distributed tracing guide


It is clear now, Thank you for the patient :grinning:

This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.