Extend metric observability
You can extend the data collected out of the box with data provided by the following frameworks and standards:
Send OpenTelemetry metrics to Dynatrace
Collect Micrometer metrics from JVM applications
Send Prometheus metrics to Dynatrace
Send StatsD metrics to Dynatrace
Send Telegraf metrics to Dynatrace
Extend your application observability into data acquired directly from your Oracle Database layer.
Learn how to monitor your network devices using SNMP.
Learn how to monitor your devices exposing Windows Management Instrumentation using WMI.
Extend observability of your Java applications with JMX metrics.
Extend metric observability via Dynatrace' scripting integration.
Metric ingestion API
Extend metric observability via Dynatrace's open Metric APIs.
Access ingested metrics
You can access your ingested metrics via the Metric API v2 and in the Data explorer for custom charting.
Use the GET metric data points call of the Metrics API v2 to retrieve ingested data points.
Select Create custom chart and then select Try it out in the top banner. For more information, see Data explorer.
You can search the metric keys of all available metrics, select the metrics you want to chart, define how you’d like to analyze and chart them, and then pin your charts to a dashboard.
The custom metric ingest channel allows for ingestion of all types of metric measurements, regardless of the number of entities they relate to. The way an event is raised depends on whether there's no entity, a single entity, or multiple entities assigned to a custom metric. For more information, see Topology awareness.
You can also create custom alerts based on the ingested metrics. From the navigation menu, select Settings > Anomaly detection > Custom events for alerting and select Create custom event for alerting. In the Create custom event for alerting page, search for a metric using its key and define your alert. For more information, see Metric events for alerting.
Custom metric ingestion affects your DDU consumption
Only limited custom metric ingestion and analysis is included in out-of-the-box Dynatrace technology support. Custom metrics typically consume Davis data units, but custom metrics from OneAgent-monitored hosts are first deducted from your quota of included metrics per host unit, so they won't necessarily consume DDUs. This applies to metrics that are assigned to a host either automatically or by adding the
For details, see DDUs for custom metrics.
Each ingested metric that is subject to DDU consumption (in other words, not assigned to a host) generates one or more metric data points. These data points consume DDUs with a weight of 0.001. Therefore, a simple metric reported once each minute for a full year will consume 526 DDUs (
525,600 minutes * 0.001 ≈ 526 DDUs).
To check the DDU consumption of an environment, go to Settings > Accounting > Davis data units overview.
Metric dimensions also affect DDU Consumption
There are two additional factors to consider in determining which ingested metrics will consume DDUs and when:
- Tuples: Unique combinations of metric-dimension pairs (see examples below). Each environment can support a maximum of 20,000,000 unique tuples monthly.
- Timeframe: When the same metric is ingested with unique dimension tuples within a 1-minute timeframe, each additional tuple results in the consumption of another metric data point.
For the following examples, assume that all metrics are ingested once per minute.
- In this first example, the same distinct dimension tuple is reported twice within a one-minute interval. Therefore, only one (aggregated) data point is consumed (
1 data point x 0.001 DDUs).ini
cpu.temp,cpu=cpu1,cpu_type="INTEL" 55 cpu.temp,cpu=cpu1,cpu_type="INTEL" 75
- Here two distinct dimension pairs are reported within a 1-minute interval. Therefore two data points are consumed (
2 x 0.001 DDUs). From a consumption perspective, this is effectively two different metrics. A two-dimension tuple like this consumes
526 * 2 = 1,052DDUs per year.ini
cpu.temp,cpu=cpu1,cpu_type="INTEL" 55 cpu.temp,cpu=cpu2,cpu_type="INTEL" 75
- Here, four distinct dimension pairs are reported within a 1-minute interval. Therefore, four data points are consumed (
4 x 0.001 DDUs). From a consumption perspective, this is effectively four different metrics. A four-dimension tuple like this consumes
526 * 4 = 2,104DDUs per year.ini
cpu.temp,cpu=cpu1,cpu_type="INTEL" 55 cpu.temp,cpu=cpu2,cpu_type="INTEL" 75 cpu.temp,cpu=cpu3,cpu_type="INTEL" 55 cpu.temp,cpu=cpu4,cpu_type="INTEL" 75
Each dimensional value (in this example, each network card) generates an individual time series within the chart. Therefore, for purposes of calculating custom-metric consumption, each dimensional value is counted as a separate custom metric.
The following limits apply to metric ingestion using a common ingestion channel. For API ingested metrics, if any limit is exceeded, the API call returns the 400 response code, with details in the response body.
|Metric key length, characters||250||The total length of the metric key, including the prefix.|
|Dimension key length, characters||100||The total length of the dimension key.|
|Dimension value length, characters||250||The total length of the dimension value.|
|Number of dimensions per line||50||The number of dimensions in a single line of the payload.|
|Total number of possible metric keys per environment||20,000||The maximum number of metric keys that can be registered in Dynatrace.|
|Number of tuples per month per metric||1,000,000||The maximum number of tuples (unique metric-dimension key-dimension value-payload type combinations) for each metric key for the last 30 days.|
|Number of tuples per month for all custom metrics||50,000,000||The maximum number of tuples (unique metric-dimension key-dimension value-payload type combinations) for all custom metrics for the last 30 days.|
|Length of line, characters||2,000||The maximum length of a single line of the payload.|
There's also a limit to the number of metrics that Dynatrace can ingest.