The APM integration with Synthetic Monitoring allows you to go from a test run that potentially failed to the root cause of the issue by looking at the trace generated by that very test run.
Having network-related specifics (thanks to your test) as well as backend, infrastructure, and log information (thanks to your trace) allows you to access a new level of details about the way your application is behaving, as experienced by your user.
Statements on this page apply to both API and browser tests for APM except where noted.
Create a test that hits your traced HTTP server, and Datadog automatically links the trace generated by your server to the corresponding test result.
To link browser test results, allow the URLs you want the APM integration headers added to. Use * for wildcards:
https://*.datadoghq.com/*
The following Datadog tracing libraries are supported:
| Library | Minimum Version |
|---|---|
| Python | 0.22.0 |
| Go | 1.10.0 |
| Java | 0.24.1 |
| Ruby | 0.20.0 |
| JavaScript | 0.10.0 |
| PHP | 0.33.0 |
| .NET | 1.18.2 |
Datadog uses the distributed tracing protocol and sets up the following HTTP headers:
| Header | Description |
|---|---|
x-datadog-trace-id | Generated from the Synthetic Monitoring backend. Allows Datadog to link the trace with the test result. |
x-datadog-parent-id: 0 | To have Synthetic tests be the root span of the generated trace. |
x-datadog-origin: synthetics | To make sure the generated traces from your API tests don’t affect your APM quotas. |
x-datadog-origin: synthetics-browser | To make sure the generated traces from your Browser tests don’t affect your APM quotas. |
x-datadog-sampling-priority: 1 | To make sure that the Agent keeps the trace. |
The x-datadog-origin: synthetics header specifies to the APM backend that the traces are synthetically generated. The generated traces consequently do not impact your classical APM quotas.
These traces are retained just like your classical APM traces.
Additional helpful documentation, links, and articles:
On this Page
