Azure Monitor
Synopsis
Creates an Azure Monitor collector that simultaneously 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. A single device runs all three collection types concurrently, each maintaining its own checkpoint for incremental updates. Collection types that are not configured are skipped automatically.
Schema
- id: <numeric>
name: <string>
description: <string>
type: azmon
tags: <string[]>
pipelines: <pipeline[]>
status: <boolean>
properties:
tenant_id: <string>
client_id: <string>
client_secret: <string>
subscription_id: <string>
workspace_id: <string>
batch_size: <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 | Must be azmon | |
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.
| Field | Required | Default | Description |
|---|---|---|---|
tenant_id | Y | Azure tenant ID | |
client_id | Y | Azure client ID | |
client_secret | Y | Azure client secret |
Collection
| Field | Required | Default | Description |
|---|---|---|---|
subscription_id | N | Azure subscription ID (required for alerts and metrics collection) | |
workspace_id | N | Log Analytics workspace ID (required for logs collection) | |
batch_size | N | 10000 | Number of records to fetch per collection cycle |
Details
Collection Architecture
Each device instance runs alerts, logs, and metrics collection concurrently via separate goroutines within a single collection cycle. Collection cadence is set service-wide through the FrequencySettings Definition on the platform (the event collector frequency), not as a per-device YAML property. 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.
The subscription_id is required to query Azure Monitor alerts and metrics. The workspace_id is required to query Log Analytics logs. Either or both 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 streaming device does.
Each selected table is queried once per chunk, bounded on TimeGenerated, and the rows are paged by batch_size. The streaming device's checkpoints 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 from a single Azure subscription... | |