New Relic's integrations include an integration for reporting your Microsoft Azure Synapse Analytics metrics and other data to New Relic. This document explains how to activate the integration and describes the data reported.
Azure Synapse Analytics is an enterprise analytics service that accelerates time to insight across data warehouses and big data systems. It brings together the best of SQL technologies used in enterprise data warehousing, Apache Spark technologies for big data, and Azure Data Explorer for log and time series analytics.
Using New Relic, you can:
- View Azure Synapse Analytics data in pre-built dashboards.
- Run custom queries and visualize the data.
- Create alert conditions to notify you of changes in data.
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 Synapse Analytics services through the Azure Monitor integration according to a default polling interval.
Find and use data
This integration collects the following metric data:
Azure Synapse Analytics metrics
Amount of data processed by queries.
Count of login attempts that succeded or failed.
Count of Requests that succeeded, failed, or were cancelled.
Count of integration activities that succeeded, failed, or were cancelled.
Number of Synapse Link connection events including start, stop and failure.
Changed row count processed by Synapse Link.
Data volume in bytes processed by Synapse Link.
Synapse Link data processing latency in seconds.
Number of Synapse Link table events including snapshot, removal and failure.
Count of integration pipeline runs that succeeded, failed, or were cancelled.
Count of integration triggers that succeeded, failed, or were cancelled.
Number of input events sources backlogged.
Number of output events that could not be converted to the expected output schema. Error policy can be changed to 'Drop' to drop events that encounter this scenario.
Number of input events that could not be deserialized.
Number of input events which application time is considered early compared to arrival time, according to early arrival policy.
Amount of data received by the streaming job in bytes. This can be used to validate that events are being sent to the input source.
Number of input events.
Number of input events sources per second.
Number of input events which application time is considered late compared to arrival time, according to late arrival policy.
Number of Event Hub Events (serialized messages) received by the Event Hub Input Adapter, received out of order that were either dropped or given an adjusted timestamp, based on the Event Ordering Policy.
Number of output events.
Output watermark delay in seconds.
Resource utilization expressed as a percentage. High utilization indicates that the job is using close to the maximum allocated resources.
Total number of errors related to query processing (excluding errors found while ingesting events or outputting results).