Azure Monitor Logs

The Azure Monitor Logs sink delivers log events from worker into Azure Monitor Logs (Log Analytics workspaces). Events are sent to Azure using the Data Collector API and appear as custom log tables inside the target workspace.

This sink is typically used when you want to centralize application, infrastructure, or platform logs in Azure for querying with KQL, building dashboards, setting alerts, or integrating with other Azure-native observability and security services.

This sink supports log events.

Before using this sink, you need:

An Azure Log Analytics workspace The workspace customer ID (Workspace ID) A shared key (primary or secondary) associated with the workspace A valid custom log type name that follows Azure naming rules

Optionally, you may also associate ingested logs with a specific Azure resource.

Customer ID (required) The unique identifier of the Log Analytics workspace where logs are ingested. This value determines the destination workspace inside Azure Monitor.

Shared Key (required) The authentication key used to sign requests to Azure Monitor Logs. Either the primary or secondary workspace key can be used.

Log Type (required) Defines the name of the custom log table in Azure Monitor. Azure appends _CL to this value when creating the table.

The value may only contain letters, numbers, and underscores, and must not exceed 100 characters.

Azure Resource ID (optional) Associates ingested logs with a specific Azure resource. When set, logs appear as being emitted by that resource, which improves correlation and resource-centric views inside Azure.

Host (optional) Overrides the default Azure Monitor ingestion endpoint. This is mainly used for sovereign or dedicated Azure regions.

Encoding (optional) Controls which fields are included or excluded before sending events to Azure Monitor. This allows you to reduce payload size, avoid unnecessary fields, or prevent schema conflicts in Azure.

Timestamp formatting can also be adjusted to ensure Azure interprets event times correctly.

Time Generated Key (optional) Specifies which log field should be used as TimeGenerated in Azure Monitor.

By default, the standard event timestamp field is used. This option is useful when logs contain a domain-specific timestamp that should be reflected as the primary event time in Azure.

Batch (optional) Controls how log events are grouped before being sent to Azure Monitor.

Batching affects throughput, latency, and API efficiency. Larger batches improve throughput and reduce request overhead, while smaller batches reduce latency and limit retry impact.

Buffer (optional) Defines how events are buffered before delivery.

Memory buffering offers higher performance but does not survive restarts. Disk buffering provides durability across restarts and temporary connectivity issues.

When buffers become full, you can choose whether worker should apply backpressure to upstream components or drop newer events, depending on whether data loss or pipeline stability is preferred.

Proxy (optional) Allows routing outbound traffic to Azure Monitor through HTTP or HTTPS proxies.

This is commonly required in enterprise environments with controlled egress, firewalls, or outbound inspection policies. Proxy bypass rules can be configured to exclude specific hosts or IP ranges.

Request Settings (optional) Controls concurrency, rate limiting, timeouts, and retry behavior for outbound requests.

Adaptive concurrency can automatically tune request parallelism based on observed latency, helping stabilize throughput under varying network conditions.

Retry behavior follows a backoff strategy designed to reduce overload during transient Azure-side or network failures.

TLS (optional) Controls secure communication with Azure Monitor, including certificate verification, custom certificate authorities, and hostname validation.

TLS should be enabled for all production deployments to ensure data confidentiality and integrity when logs are transmitted to Azure.

Azure Monitor Logs is commonly used as a centralized log store for Azure-hosted workloads, hybrid environments, and cloud-native applications.

The sink is often paired with KQL-based dashboards, alerting rules, and security analytics in Microsoft Sentinel.

Associating logs with Azure resource IDs improves correlation with metrics, traces, and platform events, enabling a more unified observability experience.