Azure Monitor
Synopsis
Creates an Azure Monitor collector that gathers alerts, logs, and metrics from Azure. Director polls the source system's API at configured intervals to retrieve log and telemetry data rather than receiving pushed events. Each collection type maintains its own checkpoint for incremental updates.
The collector is available as four device types that run the same module:
| Type | Collects |
|---|---|
azmon | Alerts, Log Analytics tables and metrics, concurrently. Collection types that are not configured are skipped automatically |
azlogs | Log Analytics tables only |
azalerts | Alerts only |
azmetrics | Metrics only |
azlogs, azalerts and azmetrics each run their one collection type alone, so the properties of the other two are not read.
In the web interface, the azlogs, azalerts and azmetrics devices. azmon has no card, so it is configured in a Director configuration file. The last step of each of the three forms ends with the
Schema
- id: <numeric>
name: <string>
description: <string>
type: <string>
tags: <string[]>
pipelines: <pipeline[]>
status: <boolean>
properties:
tenant_id: <string>
client_id: <string>
client_secret: <string>
workspace_id: <string>
stream: <string[]>
subscription_id: <string>
alert_rule: <string>
alert_state: <string>
monitor_condition: <string>
monitor_service: <string>
severity: <string>
smart_group_id: <string>
target_resource: <string>
target_resource_group: <string>
target_resource_type: <string>
resource_uri: <string>
namespace: <string>
metrics: <string[]>
aggregation: <string[]>
interval: <string>
order_by: <string>
filter: <string>
result_type: <string>
batch_size: <numeric>
event_frequency: <numeric>
Configuration
The following fields are used to define the device.
Device
| Field | Required | Default | Description |
|---|---|---|---|
id | Y | Unique identifier | |
name | Y | Device name | |
description | N | - | Optional description |
type | Y | azmon, azlogs, azalerts or azmetrics | |
tags | N | - | Optional tags |
pipelines | N | - | Optional pre-processor pipelines |
status | N | true | Enable/disable the device |
Authentication
All collection types share a single set of credentials. With all three fields set, the device signs in as that service principal. With any of them left empty, it uses the default credential chain (DefaultAzureCredential) instead, tried in order: environment variables, workload identity, managed identity, then developer sign-ins such as the Azure CLI; a tenant_id that is set is still passed to the chain.
| Field | Required | Default | Description |
|---|---|---|---|
tenant_id | N | - | Azure tenant ID. Required for a service principal |
client_id | N | - | Client ID of the service principal. Required for a service principal |
client_secret | N | - | Client secret of the service principal. Required for a service principal |
Collection
| Field | Required | Default | Description |
|---|---|---|---|
batch_size | N | Per type | Logs: rows read from each table per round (10000). Alerts: alerts per page (250). Metrics: time series one query returns (10000) |
event_frequency | N | - | Seconds between two collection rounds, 1 or more. When it is unset, not a number or below 1, the device keeps the cadence described under Collection Architecture |
In the web interface, event_frequency is 300. A cleared field is not sent, so the device falls back to the cadence described under Collection Architecture. The field is on these steps:
| Card | Step | Where |
|---|---|---|
| Beside | ||
| Under the | ||
| On its own row, the last field of the step |
Logs
Read by azmon and azlogs.
| Field | Required | Default | Description |
|---|---|---|---|
workspace_id | Y | Log Analytics workspace ID | |
stream | Y | Workspace tables to read, such as SecurityEvent or Syslog |
Alerts
Read by azmon and azalerts. The filters are optional; an empty one is not sent.
| Field | Required | Default | Description |
|---|---|---|---|
subscription_id | Y | Azure subscription ID whose alerts are read | |
alert_rule | N | - | Only alerts of this alert rule |
alert_state | N | - | New, Acknowledged or Closed |
monitor_condition | N | - | Fired or Resolved |
monitor_service | N | - | The service that raised the alert, such as Platform, Log Analytics, Application Insights or ActivityLog Administrative |
severity | N | - | Sev0 to Sev4 |
smart_group_id | N | - | Only alerts of this smart group |
target_resource | N | - | Only alerts on this resource |
target_resource_group | N | - | Only alerts on resources in this resource group |
target_resource_type | N | - | Only alerts on resources of this type |
The first round reads the alerts of the last 30 days. Every later round reads from the checkpoint onward, oldest first.
Metrics
Read by azmon and azmetrics. Metrics are read from resource_uri alone, so subscription_id is not used here.
| Field | Required | Default | Description |
|---|---|---|---|
resource_uri | Y | Resource ID of the Azure resource whose metrics are read | |
namespace | N | - | Metric namespace |
metrics | N | - | Metric names, as a list or a comma-separated string. See Microsoft's metrics index for the names each resource type has |
aggregation | N | - | Average, Count, Maximum, Minimum, None or Total, as one value or a list |
interval | N | PT1M | Time grain of the series, as an ISO 8601 duration |
order_by | N | TimeStamp asc | Sort order of the results |
filter | N | - | OData filter on the metric dimensions |
result_type | N | - | Data or Metadata. When unset, Azure returns Data. With Data, the device sends one record per data point. Metadata collects nothing: a Metadata query returns no data points, so the device sends no records. In the web interface, a new Data under Metadata keeps it |
Details
Collection Architecture
azmon runs alerts, logs, and metrics collection concurrently via separate goroutines within a single collection round. azlogs, azalerts and azmetrics run their one type in the same way. Each collection type maintains its own checkpoint keyed by device ID and type, so a failure in one type does not affect the others' progress.
After each round the device waits event_frequency seconds before the next one. Without event_frequency, the cadence is set service-wide through the FrequencySettings Definition on the platform (the event collector frequency), or 5 seconds when that sets none.
Every round reads the device as it is configured at that moment, so an edit to the tables, the filters, batch_size or event_frequency applies from the next round without a restart. A change to tenant_id, client_id, client_secret, subscription_id or workspace_id restarts the device.
On azmon, subscription_id is required to query alerts, resource_uri to query metrics, and workspace_id with stream to query Log Analytics tables. Any combination can be provided; collection types with missing configuration are skipped.
Replay
The azlogsreplay device type re-reads Log Analytics workspace tables over a bounded historical window. The window, chunking and run controls are described in Replay Devices.
The replay covers logs only. Alerts and metrics have no replay: this device type reads workspace tables, so a replay device selects the tables it reads rather than collecting all three types the way the azmon device does.
Each selected table is queried once per chunk, bounded on TimeGenerated, and the rows are paged by batch_size. The checkpoints of the azmon and azlogs devices are never touched.
| Field | Required | Default | Description |
|---|---|---|---|
workspace_id | Y | - | Log Analytics workspace to read from |
stream | Y | - | Workspace tables to replay, such as SecurityEvent or Syslog |
batch_size | N | 10000 | Rows per page within a chunk |
start_date | Y | - | Lower bound of the replay window |
end_date | N | - | Upper bound, exclusive. Unset means an open window that follows the present |
timezone | N | UTC | Zone used to read an offset-less bound |
window_chunk | N | 3600 | Seconds of the window covered by one query. Minimum 60 |
interval | N | 60 | Seconds between runs while the window still has work |
cron | N | - | Cron expression for the run, taking precedence over interval |
A Microsoft Sentinel workspace is a Log Analytics workspace, so azlogsreplay covers Sentinel table history as well.
Examples
Basic
Collecting all three data types with one | |
Logs Only
Reading two Log Analytics tables every five minutes... | |
Alerts Only
Reading the fired alerts of severity 0 in one subscription... | |
Metrics Only
Reading the average CPU of one virtual machine per minute... | |