Moving from azure_monitor_logs to azure_logs_ingestion

Source of truth: vectorflow/docs/azure-monitor-logs-migration.md (synced at build time — edit the original, not this copy). Vector 0.58 removed the azure_monitor_logs sink (upgrade guide). VectorFlow ships Vector 0.58, so a pipeline that still has this sink can’t be validated or deployed. The editor still loads the node so you can replace it. Validate and deploy fail with a message that names azure_logs_ingestion and links here. A YAML import keeps the node and shows the same message as a warning.

A pipeline deployed with this sink before the upgrade keeps running on agents still on Vector 0.54. An agent on Vector 0.58 can’t load it: Vector stops the pipeline with a configuration error, which shows in the pipeline’s logs. Replace the sink before you upgrade those agents.

The old sink sent events to Azure’s HTTP Data Collector API with a workspace ID and a shared key. Microsoft ended support for that API on September 14, 2026 (Microsoft’s migration guide). azure_logs_ingestion uses the Logs Ingestion API. That API needs other Azure resources and another kind of credential, so VectorFlow can’t convert the old settings. Set up the Azure side first, then swap the node.

Set up Azure

Microsoft’s Logs Ingestion API overview and portal tutorial cover each step.

1. A table in the Log Analytics workspace. It has to exist before data arrives. Custom table names end in _CL. You can migrate the table the Data Collector API wrote to, or create a new one.
2. A data collection rule (DCR). Its stream declaration lists the columns of your events, and its data flow sends that stream to the table. If your events don’t match the table’s columns, add a transformation to the DCR. Creating a custom table in the Azure portal creates the DCR for you. Note the DCR’s immutable ID (it starts with dcr-) and the stream name. Custom streams are named Custom-<name>.
3. An ingestion endpoint. A DCR created for direct ingestion has its own logs ingestion endpoint, shown in the DCR’s JSON view. Older DCRs, and workspaces behind a private link, need a data collection endpoint (DCE) linked to the DCR instead.
4. A credential with the Monitoring Metrics Publisher role on the DCR. For a Microsoft Entra app registration, that’s its tenant ID, client ID and a client secret. A managed identity or Azure CLI login on the agent host also works.

Fill in the new sink

Field	What to enter
endpoint	The DCR’s logs ingestion endpoint or the DCE URI, for example https://my-dce.eastus-1.ingest.monitor.azure.com.
dcr_immutable_id	The DCR’s immutable ID.
stream_name	The DCR stream, for example Custom-MyTable.
auth.azure_credential_kind	client_secret_credential, managed_identity or azure_cli.
auth.azure_tenant_id, auth.azure_client_id, auth.azure_client_secret	The app registration’s values, for client_secret_credential. Keep the secret in a VectorFlow secret.
timestamp_field	The column that gets the event’s timestamp. Defaults to TimeGenerated.
token_scope	Defaults to https://monitor.azure.com/.default. Sovereign clouds use their own scope, such as https://monitor.azure.us/.default.

Vector 0.55 and later need auth.azure_credential_kind set (0.55 upgrade guide). A new node starts with client_secret_credential. If a saved node’s auth block has no kind, VectorFlow sends client_secret_credential, which is what Vector assumed before 0.55. Vector 0.54 refuses that value, so an agent still on Vector 0.54 gets the same login without the kind.

Old settings with no direct match

• customer_id and shared_key have no counterpart. The new sink signs in with the credential above.
• log_type named the table, as <log_type>_CL. Point the DCR at that table or at a new one.
• host picked the Data Collector host for a sovereign cloud. Use that cloud’s endpoint and token_scope instead.
• time_generated_key picked the event field Azure used as TimeGenerated. The new sink always takes Vector’s event timestamp and writes it to the column in timestamp_field. To use another event field, copy it into the timestamp with a remap transform before the sink.
• azure_resource_id has no option on the new sink.

Swap the node

1. Open the pipeline. The azure_monitor_logs node is still on the canvas, with its connections. It shows no settings.
2. Select it and choose Azure Logs Ingestion under Component type. The node keeps its name and connections, and its old settings are cleared. You can also delete it and add a new Azure Logs Ingestion node.
3. Fill in the fields above, run Validate, then deploy.