Microsoft Sentinel with Cribl Stream

The SIEM endpoint, auth, and event mapping, configured per the destination page.

What it is for

The Microsoft Sentinel Destination page documents a Cribl Stream destination that encrypts and sends log and metric events over the HTTPS protocol to the Microsoft Sentinel SIEM. Behind the scenes it uses the Azure Monitor Logs Ingestion API, writing events into the Sentinel tables your data collection rules (DCRs) expect. Its header names the destination Type: Streaming with PQ (persistent queue) Support: Yes. Supported environments include Azure Public Cloud, Azure US Government Cloud, and Microsoft Azure operated by 21Vianet.

The opening warning: field names in your data must match the schema the DCR defines for Microsoft Sentinel, or events may be dropped.

Configuring the destination

Before configuring, the destination page points to the Microsoft Sentinel SIEM Integration guide for preparing the Azure workspace, creating the data collection rules (DCRs), and obtaining the ingestion URL. Multiple event types or tables need a separate Destination per event type, three documented ways: separate Destinations with their own URLs, directed by Routes; Destinations split by an Output Router; or one Destination whose URL a Pipeline overwrites per event via the __url internal field.

Select Products, then Cribl Stream, pick a Worker Group, and add the Destination via QuickConnect (Routing > QuickConnect > Add Destination) or via Routes (Data > Destinations). General Settings in the modal offers Output ID (a unique name; cloning appends -CLONE), Description (optional), and Endpoint configuration (URL or ID). Optional Settings add Backpressure behavior (block, drop, or queue when all receivers exert backpressure) and Tags (filter and group Destinations; not added to processed events). Finish with Save, then Commit & Deploy.

Endpoint configuration options. For Syslog, Cribl recommends the Syslog DCR template in the Cribl-Microsoft GitHub repository, which defines a Custom-Syslog stream that routes data into the Sentinel Syslog table. That template under the DataCollectionRules path is for the DCR kind:direct approach; DCE-based deployments should use the DCE-based template from the same repository. URL mode exposes a single URL field; ID mode exposes three fields, and Data collection endpoint takes the LogsIngestion URL in the format shown on the destination page:

https://<endpoint-name>.<identifier>.<region>.ingest.monitor.azure.com

Data collection rule ID is the immutable ID for the DCR. Stream name is the Sentinel table where events land; for DCR-based ingestion it must exactly match the DCR template's stream/table name, not the friendly name in the Sentinel UI (Custom-Syslog for the Syslog template), or data may fail to land in the expected Sentinel table.

Authentication. The Login URL is the OAuth API call endpoint; per-cloud formats from the destination page:

Azure Public Cloud: https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/token
Azure US Government Cloud: https://login.microsoftonline.us/<tenant-id>/oauth2/v2.0/token
Microsoft Azure operated by 21Vianet: https://login.chinacloudapi.cn/<tenant-id>/oauth2/v2.0/token

The OAuth secret source is Inline (the default) or Secret (a stored text secret, or Create text secret). Client ID is a JavaScript expression computing the application client ID, and can be a constant. Scope must match your Azure environment: https://monitor.azure.com/.default (Azure Public Cloud, default), https://monitor.azure.us/.default (Azure US Government Cloud), or https://monitor.azure.cn/.default (21Vianet Azure).

Persistent Queue Settings appear when Backpressure behavior is Persistent Queue. Mode selects when the queue engages: Error queues when the Destination is unavailable or erroring, Backpressure while backpressure is detected, Always On immediately queues all events, even without backpressure; a node starting with an invalid Mode automatically switches to Error, which can happen on versions older than 4.9.0 or with a nonexistent YAML value. Defaults: File size limit 10 MB (on save, at least the Buffer size limit (bytes)), Queue size limit 5 GB (up to 1 TB unless a different Worker Process PQ size limit is set), Buffer size limit (bytes) 1MB within 64KB to 10MB (replacing the deprecated event-based limit as of 4.18.0), and Backpressure duration limit 30 seconds (shown only when Mode is Backpressure). Queue-full behavior: Block or Drop new data. Strict ordering is on by default for FIFO forwarding, the queue flushing every 10 seconds; off, it shows Drain rate limit (EPS), where 0 disables throttling.

Processing. Post-Processing offers Pipeline (a Pipeline or Pack run before this output sends data) and System fields, which adds fields to events using this output; cribl_pipe is included by default, wildcards are supported, and available fields include cribl_host, cribl_input, cribl_output, cribl_route, cribl_wp, cribl_group, and cribl_mode.

Retries. With Honor Retry-After header on, Stream honors a Retry-After header capped at 180 seconds, which then takes precedence over the other Retries options. Default per-status-code behavior, from the destination page:

| Status Code | Action |
| --- | --- |
| Any in the `1xx`, `3xx` series| Drop the request |
| `408`, `429` errors| Retry in memory or persistent queue if enabled, and initiate backpressure after limit is reached |
| Any other `4xx` series| Drop the request |
| Any `5xx` series| Retry in memory or persistent queue if enabled, and initiate backpressure after limit is reached |

By default, a 429 (Too Many Requests) response not listed in Settings for failed HTTP requests is a non-retryable 4xx error and is dropped; list 429 there to retry it. Listed codes take a Pre-backoff interval (ms) (default 1000), a Backoff multiplier (default 2: retries after 2 seconds, then 4, then 8), and a Backoff limit (ms) with default and minimum 10,000 and maximum 180,000; Retry timed-out HTTP requests reuses the same three settings.

Advanced. Defaults: Validate server certs on (off accepts untrusted certificates); Compress on; Keep alive on, up to 120 seconds; Request timeout 30; Request concurrency 5 (minimum 1, maximum 32); Body size limit (KB) 1000, the maximum allowed size of the API call; Buffer memory limit (KB) blank means 5 times the max body size, 0 no limit; Events-per-request limit 0 (unlimited); Flush period (sec) 1. Extra HTTP headers adds name-value pairs to all events; Failed request logging mode is None (default), Payload, or Payload + Headers (redacting all headers except Safe headers); Environment restricts the GitOps configuration to one Git branch, empty enabling it everywhere.

Using it

The destination page documents three internal fields for this Destination:

__criblMetrics
__url
__headers

An event containing __criblMetrics is sent as a metric event; otherwise it is sent as a log event. __url overrides the General Settings URL value, so an Eval Function in a Pipeline can vary the endpoint from a global variable or an event property. __headers holds per-event JSON header pairs and takes precedence over Extra HTTP headers: if both set api-key, only the __headers value is sent.

On HTTP-based outputs, Stream reuses connections through keepalives, throwing a connection away two minutes after first use to avoid sticking to one destination in a constant event flow. It picks the first resolved IP unless Round-robin DNS is enabled. The modal's Live Data (Start Capture), Logs, and Test (Run Test) tabs plus the Monitoring page cover troubleshooting.

What the docs flag

Field names must match the DCR schema or events can be dropped, and the Destination sends individual top-level fields, not a combined _raw (or similar) field; in ID mode the Stream name must exactly match the DCR template's stream/table name, not the friendly Sentinel UI name, or data may not land in the expected table.

The Syslog template under the DataCollectionRules path is for the DCR kind:direct approach, so DCE-based deployments should use the DCE-based template instead; and 429 responses absent from Settings for failed HTTP requests are dropped as non-retryable 4xx errors rather than retried.

On Cribl-managed Cloud Workers with an Enterprise plan, the persistent queue tab exposes only Mode, Backpressure duration limit, and the destructive Clear Persistent Queue button, with a 1 GB per PQ-enabled Destination, per Worker Process disk limit on outbound uncompressed data that is not configurable; Stream blocks outbound data when the queue fills. A high Body size limit can raise per-Worker-Node memory use, especially with a dynamic __url targeting multiple URLs, because the Destination adds bytes when writing to the receiver; Cribl recommends experimenting with the value until receivers accept all events. Clearing the queue permanently deletes queued data without delivering it.

Frequently asked questions

How does Cribl Stream send data to Microsoft Sentinel?

The destination encrypts log and metric events over the HTTPS protocol and sends them to the Microsoft Sentinel SIEM, using the Azure Monitor Logs Ingestion API behind the scenes. Events land in the Sentinel tables your DCRs expect, as individual top-level fields rather than a combined _raw field.

What are the endpoint configuration options on the Cribl Stream Microsoft Sentinel Destination?

Endpoint configuration offers URL, which exposes a single URL field, and ID, which exposes three fields. ID mode takes the data collection endpoint, the data collection rule ID, and the stream name, which must exactly match the DCR template's stream/table name.

What values do the Login URL and Scope settings take for each Azure environment?

The Login URL is the OAuth2 token endpoint for each cloud, for example https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/token for Azure Public Cloud. Scope matches the environment, for example https://monitor.azure.com/.default for Azure Public Cloud, with the .us and .cn variants for the government and 21Vianet clouds.

Which internal fields does the Microsoft Sentinel Destination support, and what do they do?

It supports the internal fields __criblMetrics, __url, and __headers. The first marks a metric event, __url overrides the endpoint URL per event, and __headers adds per-event header pairs that take precedence over Extra HTTP headers.

Source

Verified against Cribl Stream 4.20 documentation on October 14, 2026.