The OpenTelemetry Protocol (OTLP) is the principal network protocol for the exchange of telemetry data between OpenTelemetry-backed services and applications.
Dynatrace provides native OTLP endpoints with the following services:
Additionally, you can deploy the Collector as intermediary service application, to batch requests and improve network performance or transform requests before forwarding them to Dynatrace (for example, mask sensitive data).
The ingest paths used by Dynatrace for the individual signal types follow the standard OpenTelemetry paths.
| Signal Type | Path |
|---|---|
| Traces | /v1/traces |
| Metrics | /v1/metrics |
| Logs | /v1/logs |
Depending on the configuration, you may need to append these paths individually to the base URLs of the following service endpoints when specifying the export URLs. This can happen either in-code, when using manual instrumentation, or using the standard environment variables.
The following addresses provide the base URLs for your OTLP ingest configuration. Use the URL applicable to your type of environment and replace the relevant part with your environment ID.
| API Type | Base URL |
|---|---|
| Dynatrace SaaS | https://{your-environment-id}.live.dynatrace.com/api/v2/otlp |
| Environment ActiveGate1 | https://{your-activegate-domain}:9999/e/{your-environment-id}/api/v2/otlp |
| Containerized Environment ActiveGate2 | https://{your-activegate-domain}/e/{your-environment-id}/api/v2/otlp |
Environment ActiveGates listen by default on port 9999. If you changed that port, adjust the port in the URL accordingly.
A PVC is required for this setup.
The following example URLs illustrate combinations of base URLs and paths for signal types.
| API Type | Signal type | URL |
|---|---|---|
SaaS | Traces |
|
Metrics |
| |
Logs |
| |
Environment ActiveGate | Traces |
|
Metrics |
| |
Logs |
|
Vanilla OTLP exports to ActiveGate require manual enrichment of Dynatrace host information to have the proper topology information.
To do so, make sure your traces have the correct mapping resource attributes set. The list of applicable attributes can be found in (or imported from) the enrichment files.
Calls to these API endpoints need to adhere to the following protocol details:
Authentication is handled using an API access token and the Authorization HTTP header.
Authorization: Api-Token dt.....
To obtain an access token, in Dynatrace, go to Access Tokens. Use the following access scopes for the signals you are exporting.
| Signal Type | Access Scope |
|---|---|
| Traces | openTelemetryTrace.ingest |
| Metrics | metrics.ingest |
| Logs | logs.ingest |
Of course, you can also combine scopes. For more information on access tokens, see Dynatrace API - Tokens and authentication.
Verify that the following are true:
TCP port is not blocked
Because OTLP communication with ActiveGate takes place over the ports 443 (for SaaS and Managed) or 9999 (for Environment ActiveGates), make sure that the TCP port in question is not blocked by a firewall or any other network management solution you might be using.
Your system's certificate trust store is up to date
To avoid possible SSL certificate issues with expired or missing default root certificates, make sure that your system's certificate trust store is up to date.
Using the Collector as an intermediate gateway allows you to streamline and optimize your telemetry data and requests centrally. See Collector use cases for more information and sample configurations for popular Collector use cases.
See Dynatrace Collector for more details on how to configure a Collector instance.
As Dynatrace currently requires OTLP exports with HTTP, you can use the Collector to convert gRPC exports to HTTP.
See Transform OTLP gRPC for more details.
Whether you need to use TLS and authenticate your requests against the Collector depends on your particular Collector setup/configuration. By default, the OTLP receiver is configured for plain-text HTTP and does not require authentication.
The eventual outbound connection from the Collector to Dynatrace always requires authentication and TLS.
Verify that the following are true:
Network ports not blocked
Make sure the network ports required by the configured receiver instances are not blocked by a firewall or any other network management solution used as part of your infrastructure.