Azure Resources¶
You built an amazing cloud system within the Azure perimeter, so you absolutely need to gather information from there to power your favorite monitoring tool. This Azure application tries to be the simplest as possible to cover all the Microsoft Azure resource types in the same way: you only need to configure the name of the resource for which you want to get metrics. As you know, you will first need to configure an application in your Azure tenant to open the collect of metrics. Options
- Name*: Just a simple label to find it easier in the SenHub's interface
- Description: Description for your own usage only.
- Vault*: Choose in the list box the appropriate vault for this resource.
- Group: optional — assign this instance to a group to organise it within SenHub.
- Azure resource name*: The name of your resource you want to collect metrics from as it is set in your Microsoft Azure environment.
- Specific: for some resource types, an extra option lets you dig more precisely into the metrics to avoid collecting too much information. For example:
- Service Bus — collect information on a specific queue or topic.
How a value is picked¶
Azure Monitor stores one data point per time grain, and for most resources that grain is one minute. Whether a given minute holds a data point depends on the metric.
Metrics that count transactions, such as Requests, Http 2xx or Data In, get a data point every minute even when nothing happens, because the provider writes a zero. Metrics that measure a transaction, such as Response Time or a backend latency, only get one when a transaction actually occurred. An average over zero requests does not exist, so Azure records no value for that minute. Microsoft calls this activity based collection and documents it in Azure Monitor metrics aggregation and display explained.
The connector reads the last hour, falls back to the last day when the hour holds nothing, and
publishes the most recent data point available. Each channel carries the exact timestamp of the
measurement in azure_timestamp, so you can always tell how fresh a value is.
A data point is published only if it is recent enough to still describe the resource. The limit is three times the metric's own time grain, and never less than 15 minutes. A metric sampled every minute is therefore dropped once its last point is older than 15 minutes, while a metric that Azure only samples every six hours is allowed a proportionally older point.
Why a channel shows no data¶
When a resource sits idle, its transaction based metrics stop producing data points. Once the last one ages past the limit above, the channel is left out of the payload and your monitoring tool shows it as no data. The channel comes back on its own as soon as the resource is used again.
This is deliberate. The alternative would be to keep republishing an old measurement as if it were current, which turns a one off event into a permanent alarm. A typical case is an App Service or a Function App that scales to zero overnight: the first request after an idle period pays for the cold start and can be measured at twenty seconds or more. That value is real, but it describes an instant that has passed, and repeating it for hours would show a healthy resource as degraded.
For the same reason, setting a tight error threshold on the response time of a rarely used App Service or Function App is fragile. Cold starts are inherent to that hosting model. Triggering on a counter channel such as Http Server Errors or Function Execution Count gives a far more stable signal.
Example output
The channels returned are dynamic: they depend on the Azure resource you point at. In the general case the connector emits a State channel plus one channel per Azure Monitor metric exposed by that resource (the channel name is the metric's localized display name):
{
"metrics": [
{ "channel": "State", "value": "Succeeded" },
{ "channel": "Account Created", "value": 2, "unit": "Count", "aggregation": "Count", "description": "Account Created", "azure_timestamp": "2025-09-10T14:00:00.000Z" },
{ "channel": "Metadata Requests", "value": 187, "unit": "Count", "aggregation": "Count", "description": "Count of metadata requests", "azure_timestamp": "2025-09-10T14:00:00.000Z" },
{ "channel": "Data Usage", "value": 10485760, "unit": "Bytes", "aggregation": "Total", "description": "Total data usage", "azure_timestamp": "2025-09-10T14:00:00.000Z" }
],
"message": "Metrics successfully retrieved.",
"status": "OK",
"date": 1725981405127
}
For a Service Bus namespace scoped to a specific queue (via the Specific option), the connector returns that queue's status and message counters, each channel prefixed with the queue name:
{
"metrics": [
{ "channel": "State", "value": "Succeeded" },
{ "channel": "(orders-queue) Status", "value": "Active" },
{ "channel": "(orders-queue) Size", "value": 4096 },
{ "channel": "(orders-queue) Message Count", "value": 12 },
{ "channel": "(orders-queue) Active Message Count", "value": 10 },
{ "channel": "(orders-queue) DeadLetter Message Count", "value": 2 },
{ "channel": "(orders-queue) Scheduled Message Count", "value": 0 },
{ "channel": "(orders-queue) Transfer Message Count", "value": 0 },
{ "channel": "(orders-queue) Transfer DeadLetter Message Count", "value": 0 }
],
"message": "Metrics successfully retrieved.",
"status": "OK",
"date": 1725981405127
}
For a Compute virtual machine (with the Azure Monitor agent installed), the connector adds one size and one free-space channel per mounted disk, in GB: