> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/continuous-delivery/use-continuous-delivery/verify-deployments/configure-cv/health-sources/dynatrace/dynatrace-health-source.md). # Dynatrace ### Before you begin This page assumes you have followed the rest of the steps to set up CV. To learn more, go to [Configure CV](/continuous-delivery/use-continuous-delivery/verify-deployments/configure-cv/verify-deployments.md) ### Add Dynatrace as a health source This option is available only if you have configured the service and environment as fixed values. A Health Source is basically a mapping of a Harness Monitored Service to the Service in a deployment environment monitored by an APM or logging tool. #### Define Health Source In **Health Sources**, click **Add**. The **Add New Health Source** settings appear. ![](/files/ecSKIYtVczoXVuBhVau1) 1. In **Select health source type**, select **Dynatrace**. 2. In **Health Source Name**, enter a name for the Health Source. For example Quickstart. 3. Under **Connect Health Source**, click **Select Connector**. 4. In **Connector** settings, you can choose an existing connector or click **New Connector** to create a new **Connector.** ![](/files/rctkjSi96FmmhFukbW0Y)

NOTE

When creating a new Dynatrace connector:

For more information on configuring Dynatrace connectors, go to Add Dynatrace connector.

5. After selecting the connector, click **Apply Selected**. The Connector is added to the Health Source. 6. In **Select Feature**, choose one of the following options. Your choice determines which configuration options appear next.

NOTE

#### Configuration Depending on your feature choice, do the following configuration steps. {% tabs %} {% tab title="Full Stack Observability: APM" %} 7\. Click **Next**. The **Configuration** settings appear. ![](/files/UVOeo5wOjnQLUtJuQTYB) 8. Next, you will have the choice between using **Metric Packs** or **Custom Metrics**. ``` Choose **Metric Packs** if you want to use one of the predefined **Infrastructure** or **Performance** packs. Choose **Custom Metrics** to make your own metrics against your data. You may choose both options. ``` {% tabs %} {% tab title="Metric Packs" %} 8\. In **Find a Dynatrace service**, enter the name of the desired Dynatrace service. This Dynatrace service must be marked as a [key request](https://docs.dynatrace.com/docs/observe/applications-and-microservices/services/analysis/monitor-key-requests) in order to appear in this dropdown menu. 9\. In **Select Metric Packs to be monitored**, you can select **Infrastructure**, **Performance**, or both. {% endtab %} {% tab title="Custom Metrics" %} 8\. Click **Add Metric** if you want to add any specific metric to be monitored (optional) or simply click **Submit.** 9\. If you click Add Metric, click **Map Metric(s) to Harness Services**. 10\. In **Metric Name**, enter the name of the metric. 11\. In **Group Name**, enter the group name of the metric. 12\. Click **Query Specifications and mapping**. To build your query, do the following: ``` 1. In **Metric**, choose the desired metric from the list. 2. In **Select Metric Filter**, choose the desired entity from the list. This will filter your metrics using [entitySelectors](https://docs.dynatrace.com/docs/discover-dynatrace/references/dynatrace-api/environment-api/entity-v2/entity-selector).

Selecting metric filters is behind the feature flag CDS_CV_DYNATRACE_CANARY_ENABLED. Contact Harness Support to enable this feature.

3. Click **Fetch Records** to retrieve data for the provided query. ``` 13\. In **Assign**, choose the services for which you want to apply the metric. ``` If you select **Continuous Verification** or **Service Health**, you will need to configure a risk profile. Expand the following block to learn more. ```
Risk Profile settings **Risk Profile** {% hint style="info" %} The **Risk Profile** section is only visible if you have selected **Continuous Verification (Applied to the pipelines in the Continuous Deployment**) or **Service Health** in the **Assign** section. {% endhint %} 1. Under **Risk Category**, select one of the following options: * **Errors** * **Infrastructure** * **Performance/Throughput** * **Performance/Other** * **Performance/Response Time** 2. Under **Deviation Compared To Baseline**, select the following settings to measure your service's behavior and calculate deviations from the health source: * **Higher counts = higher risk** * **Lower counts = higher risk** Note that you can select multiple options. **Map service instance identifier** {% hint style="info" %} The **Map service instance identifier** (SII) section is only visible if you have selected **Continuous Verification (Applied to the pipelines in the Continuous Deployment**) in the **Assign** section. {% endhint %} In **Service Instance Identifier (only needed for CV)**, specify the service instance identifier, which represents a dynamically created service that you deploy using Harness. The default value is `_sourceHost`. This field allows CV to identify the name of the host which has emitted the metric/log. Picking the right service instance identifier is important, and depends on the kind of metric that you want to monitor. As an example, for Kubernetes deployments, the best selection will typically be `pod`, ``, or ``. When creating a monitored service template, you can decide to choose the service instance identifier at runtime. When doing canary deployments, ensure that the SII can be used to identify the canary instance of the service, or CV will not work properly. For Dynatrace, the only possible values of the SII are your entity selectors. {% hint style="info" %} The ability to set a SII is behind the feature flag `CDS_CV_DYNATRACE_CANARY_ENABLED`. Contact [Harness Support](mailto:support@harness.io) to enable this feature. {% endhint %}
{% endtab %} {% endtabs %} Finally, Click **Submit**. The Health Source is displayed in the AI Verify (v1) step. You can add one or more Health Sources for each APM or logging provider. {% endtab %} {% tab title="Dynatrace Grail Logs" %} {% hint style="info" %} This feature is behind the feature flag `CDS_CV_DYNATRACE_GRAIL_LOGS_ENABLED`. This feature requires a minimum delegate version of `869xx`. Contact [Harness Support](mailto:support@harness.io) to enable the feature flag. {% endhint %} 7. Click **Next**. The **Configuration** settings will appear. You should see one button, **+ Add Query**. 8. Click **+ Add Query**. 9. Choose a **Query name** and click **Submit**. 10. Under **Define Query**, enter your [query](https://docs.dynatrace.com/docs/discover-dynatrace/references/dynatrace-query-language). This query can also be a runtime input or expression. 11. After writing your fixed input query, click **Validate** to ensure your query is valid. 12. Then click **Run Query**. The query must be validated first from the previous step. ![](/files/pzDmiw6AkG5WrcfBi4qK) 13. Next, complete the field mapping for the **Timestamp Identifier**, **Service Instance Identifier**, and **Message Identifier**. To do so, hit the `+` button icon and select the relevant field from the log that appears. ![](/files/tSVHC1QRHm1HZU1IArUC) 14. Click **Submit**. The health source is displayed in the AI Verify (v1) step! {% endtab %} {% tab title="Dynatrace Grail Metrics" %} {% hint style="info" %} This feature is behind the feature flag `CDS_CV_DYNATRACE_GRAIL_METRICS_ENABLED` and requires a minimum delegate version of `88900`. Contact [Harness Support](mailto:support@harness.io) to enable the feature flag. {% endhint %} Dynatrace Grail Metrics uses [Dynatrace Query Language (DQL)](https://docs.dynatrace.com/docs/discover-dynatrace/references/dynatrace-query-language) to query timeseries metric data from the Dynatrace Grail data lakehouse. You write a `timeseries` DQL query, validate it, fetch sample records, and then map the metric value column and service instance dimension to Harness for continuous verification and live monitoring. ![Define Health Source — Dynatrace Grail Metrics selected](/files/7aA1TzGyIQc20IsNipqT) **Map metric to Harness services** 7. Click **Next**. The **Configuration** tab opens. Click **+ Add Metric**. 8. In **Metric Name**, enter a name for the metric. 9. In **Group Name**, select an existing group or type a new one to create it. ![Map Metric(s) to Harness Services](/files/BPEa8u1qpmZj5aShnQIA) **Write and validate the query** 10. Expand **Query Specifications and mapping** and enter your DQL `timeseries` query in the **DQL Query** field. The query must start with the `timeseries` command. ```dql timeseries avg(custom.app.response.time), filter: {deployment == "canary" and health=="unhealthy"}, by: {host} ```

The by: clause splits results per dimension (for example, by: {host}). Include it when you need per-instance data for continuous verification. You can omit it for aggregate SLI queries, but note that a Service Instance Identifier is required when Continuous Verification is enabled.

11. Click **Validate**. When the query is syntactically correct, a **Validation Passed** confirmation appears below the query field. 12. Click **Fetch Records**. Harness runs the query against your Dynatrace environment and shows the raw JSON response inline. ![DQL query, validation, and fetch records](/files/04eD2bKj2cYYvDxvp5DC) **Configure metric values and charts** 13. Expand **Metric values and charts**. Harness auto-populates the fields based on the sample response. Review and confirm the following: * **Metric Value JSON Path** — the JSONPath to the metric values array in the response (for example, `['avg(custom.app.response.time)'].[0]`). * **Service Instance Identifier** — the JSONPath to the dimension that identifies each service instance (for example, `['host']`). Required when **Continuous Verification** is enabled. 14. Click **Build Chart** to preview the timeseries chart from your live data. Verify the chart renders correctly before proceeding. ![Metric values and charts with Build Chart](/files/RjtRv8rAuLPDr8kCo3RK)

DQL timeseries responses return metric values as arrays where each element corresponds to one time slot. Harness reconstructs per-point timestamps using timeframe.start and interval from the response. Because interval is in nanoseconds, Harness converts it before applying the formula:

timestamp[i] = timeframe.start + (i × (interval / 1,000,000))

**Assign and configure risk profile** 15. Expand **Assign** and select which services this metric applies to: * **SLI** — uses the metric to track SLO compliance. * **Service Health** — monitors the metric continuously outside of deployments. * **Continuous Verification** — gates deployments based on this metric. If you select **Continuous Verification** or **Service Health**, configure the **Risk Category** and **Deviation Compared to Baseline**: * **Risk Category** — select one of **Errors**, **Infrastructure**, **Performance/Throughput**, **Performance/Other**, or **Performance/Response Time**. * **Deviation Compared to Baseline** — select **Higher value is higher risk**, **Lower value is higher risk**, or both, depending on what the metric measures. ![Assign section with risk category and deviation settings](/files/DQfO2ckFYG0D4B1Po9v4) **Configure advanced thresholds (optional)** 16. Expand **Advanced (Optional)** to configure metric thresholds. There are two threshold types: * **Ignore Thresholds** — metrics matching these rules are excluded from anomaly flagging during continuous verification. * **Fail-Fast Thresholds** — metrics matching these rules immediately fail the verification step. Click **+ Add Threshold** to define rules by metric type, metric name, and criteria. 17. Click **Submit**. The health source is displayed in the AI Verify (v1) step.
Sample DQL timeseries queries The following queries illustrate common patterns for use with the Dynatrace Grail Metrics health source. **CPU usage grouped by host:** ```dql timeseries usage=avg(dt.host.cpu.usage), by:{dt.entity.host} ``` **Service response time at the 90th percentile:** ```dql timeseries p90=percentile(dt.service.request.response_time, 90), filter:{startsWith(endpoint.name, "/api/accounts")} ``` **Failure rate per second:** ```dql timeseries sum(dt.service.request.failure_count, rate:1s), filter:{startsWith(endpoint.name, "/api/accounts")} ``` **Multiple disk metrics in one query:** ```dql timeseries { bytes_read=sum(dt.host.disk.bytes_read), bytes_written=sum(dt.host.disk.bytes_written) }, by:{dt.entity.host} ``` **Week-over-week availability comparison:** ```dql timeseries avail=avg(dt.host.disk.avail), by:{dt.entity.host}, from:-24h | append [ timeseries avail_7d=avg(dt.host.disk.avail), by:{dt.entity.host}, shift:-7d ] ``` For the full DQL `timeseries` reference, see the [Dynatrace DQL timeseries documentation](https://docs.dynatrace.com/docs/discover-dynatrace/references/dynatrace-query-language/commands/data-retrieval/timeseries).
{% endtab %} {% endtabs %} *** #### Sample Dynatrace queries **Latency** * Latency trend over time: `timeseries(avg(response.time))` * Latency distribution: `histogram(response.time)` * Latency by application version: `avg(response.time) by application.version` * Latency by geographical region: `avg(response.time) by geoip.country_name` * Latency spike detection: `spike(response.time)` * Latency comparison between environments: `avg(response.time) by environment` * Latency by HTTP method: `avg(response.time) by http.method` * Latency by service: `avg(response.time) by service.name` * Latency anomaly detection: `anomaly(response.time)` * Latency percentiles: `percentile(response.time, 50)`, `percentile(response.time, 90)`, `percentile(response.time, 99)` **Traffic** * Requests per minute trend: `timeseries(count(request) / 60)` * Requests by HTTP status code: `count(request) by http.status_code` * Requests by user agent: `count(request) by useragent.name` * Requests by endpoint and HTTP method: `count(request) by endpoint, http.method` * Requests by response time range: `histogram(response.time)` * Requests by geo-location: `count(request) by geoip.country_name` * Slow endpoint detection: `top(avg(response.time), 10, endpoint)` * Requests by hostname: `count(request) by hostname` * Requests by service: `count(request) by service.name` * Requests by HTTP version: `count(request) by http.version` **Errors** * Error rate trend over time: `timeseries(count(error) / count(request) * 100)` * Top error types: `count(error) by errorType` * Error rate by geographical region: `count(error) by geoip.country_name` * Error rate by application version: `count(error) by application.version` * Error rate by HTTP status code: `count(error) by http.status_code` * Error rate by service: `count(error) by service.name` * Error rate by user agent: `count(error) by useragent.name` * Error spike detection: `spike(count(error))` * Error anomaly detection: `anomaly(count(error))` **Saturation** * CPU utilization across hosts: `avg(cpu.usage) by host` * Memory utilization across hosts: `avg(memory.usage) by host` * Disk utilization across hosts: `avg(disk.usage) by host` * Network utilization across hosts: `avg(network.usage) by host` * CPU utilization by geographical region: `avg(cpu.usage) by geoip.country_name` * Memory utilization by geographical region: `avg(memory.usage) by geoip.country_name` * Disk utilization by geographical region: `avg(disk.usage) by geoip.country_name` * Network utilization by geographical region: `avg(network.usage) by geoip.country_name`