New Relic's integrations include an integration for reporting your Microsoft Azure Data Explorer metrics and other data to New Relic. This document explains how to activate the integration and describes the data reported.
Features
New Relic gathers metrics data from Azure Monitor for the Azure Data Explorer service. The Azure Data Explorer toolbox gives you an end-to-end solution for data ingestion, query, visualization and management. You can use Azure Data Explorer to collect, store and analyze diverse data to improve products, enhance customer experiences, monitor devices and boost operations.
Using New Relic, you can:
- View Azure Data Explorer data in pre-built dashboards.
- Run custom queries and visualize the data.
- Create alert conditions to notify you of changes in data.
Activate integration
Follow standard Azure Monitor integration procedure to activate your Azure service in New Relic infrastructure monitoring.
Configuration and polling
You can change the polling frequency and filter data using configuration options.
New Relic queries your Azure Data Explorer services through the Azure Monitor integration according to a default polling interval.
Find and use data
To explore your integration data, go to one.newrelic.com/infra > Azure > (select an integration).
Metric data
This integration collects the following metric data:
Azure Data Explorer metrics
Metric | Description |
|---|---|
| Number of data sources in an aggregated batch for ingestion. |
| The duration of the aggregation phase in the ingestion flow. |
| Number of batches aggregated for ingestion. Batching Type: whether the batch reached batching time, data size or number of files limit set by batching policy. |
| Uncompressed expected data size in an aggregated batch for ingestion. |
| Number of BLOBs permanently rejected by a component. |
| Number of BLOBs processed by a component. |
| Number of BLOBs received from input stream by a component. |
| Percentage of utilized disk space dedicated for hot cache in the cluster. 100% means that the disk space assigned to hot data is optimally utilized. No action is needed in terms of the cache size. More than 100% means that the cluster's disk space is not large enough to accommodate the hot data, as defined by your caching policies. To ensure that sufficient space is available for all the hot data, the amount of hot data needs to be reduced or the cluster needs to be scaled out. Enabling auto scale is recommended. |
| The lateness (in minutes) reported by the continuous export jobs in the cluster. |
| Number of records exported, fired for every storage artifact written during the export operation. |
| The number of pending continuous export jobs ready for execution. |
| Indicates whether Continuous Export succeeded or failed. |
| CPU utilization level. |
| Reported by data connections (if exist). Time in seconds from when a message is enqueued or event is created until it is discovered by data connection. This time is not included in the Azure Data Explorer total ingestion duration. |
| Number of events dropped permanently by data connection. An Ingestion result metric with a failure reason will be sent. |
| Number of events processed by the cluster. |
| Number of events processed by the cluster when ingesting from Event/IoT Hub. |
| Number of events received by data connection. |
| Export utilization. |
| The follower databases synchronize changes in the leader databases. Because of the synchronization, there's a data lag of a few seconds to a few minutes in data availability.This metric measures the length of the time lag. The time lag depends on the overall size of the leader database metadata.This is a cluster level metrics: the followers catch metadata of all databases that are followed. This metric represents the latency of the process. |
| Latency of data ingested, from the time the data was received in the cluster until it's ready for query. The ingestion latency period depends on the ingestion scenario. |
| Total number of sources that either failed or succeeded to be ingested. Splitting the metric by status, you can get detailed information about the status of the ingestion operations. |
| Ratio of used ingestion slots in the cluster. |
| Overall volume of ingested data to the cluster. |
| Total instance count. |
| Sanity check indicates the cluster responds to queries. |
| The materialized view age in minutes. |
| The materialized view age in seconds. |
| Indicates potential data loss in materialized view. |
| Number of extents rebuild. |
| The health of the materialized view (1 for healthy, 0 for non-healthy). |
| The number of records in the non-materialized part of the view. |
| The result of the materialization process. |
| Queries duration in seconds. |
| Total number of queries. |
| Number of pending messages in a component's queue. |
| Time in seconds from when the oldest message in queue was inserted. |
| Size of data received by data connection. This is the size of the data stream, or of raw data size if provided. |
| Cumulative time from when a message is discovered until it is received by the reporting component for processing (discovery time is set when message is enqueued for ingestion queue, or when discovered by data connection). |
| Streaming ingest data rate. |
| Streaming ingest duration in milliseconds. |
| Streaming ingest result. |
| Total number of concurrent queries. |
| Total number of data extents. |
| Total number of throttled commands. |
| Total number of throttled queries. |
| The max latency between the previous metadata sync and the next one (in DB/node scope). |