Skip to article
Monitoring and Observability Azure Monitor data collection

Data collection endpoint

An Azure Monitor resource that provides regional endpoints used by agents and data collection rules for configuration access and telemetry ingestion.

Source: Microsoft Learn - Data collection endpoints in Azure Monitor Reviewed 2026-05-13

Exam trap
Treating Data collection endpoint as a generic concept instead of checking the exact resource, owner, identity, and dependency path.
Production check
Verify the active tenant, subscription, resource group, and resource name before interpreting any result.
Practice this topic Microsoft Learn
Article details and learning context
Aliases
DCE, Azure Monitor DCE, monitor data collection endpoint
Difficulty
Intermediate
CLI mappings
4
Last verified
2026-05-13
Review level
top250-field-manual-complete
Article depth
field-manual-complete
Learning paths Graph Monitoring and Observability concept cluster Data collection endpoint
Compare related concepts Search related resources Browse the glossary

Understand the concept

In plain English

Data collection endpoint is an Azure Monitor resource that provides regional endpoints used by agents and data collection rules for configuration access and telemetry. It helps operations and platform teams route monitoring traffic through known regional endpoints with controlled network paths make telemetry collection governable when private networking, regional placement, or agent configuration boundaries matter. In practice, teams use it to answer which sources depend on the endpoint and whether agents can reach it safely during failures or. Operators should tie the term to one subscription, resource owner, environment, evidence source, and rollback path before changing production. That keeps glossary.

Why it matters

Data collection endpoint matters because agent onboarding, telemetry routing, private observability design, ingestion reliability, support ownership, and compliance evidence become real production responsibilities, not abstract design notes. If teams misunderstand it, they may approve the wrong access, miss a dependency, collect weak evidence, or create avoidable outages. It influences security controls, reliability planning, support ownership, cost review, and change approval. For regulated or high-visibility workloads, agents may stop receiving configuration or sending telemetry even though the monitored workload itself is still running. A strong definition gives architects, operators, auditors, and application owners a shared operating language that can be tested against live Azure configuration, logs, and business objectives.

Official wording and source

An Azure Monitor resource that provides regional endpoints used by agents and data collection rules for configuration access and telemetry ingestion. Microsoft Learn places it in Data collection endpoints in Azure Monitor; operators confirm scope, configuration, dependencies, and production impact.

Open Microsoft Learn

Technical context

Technically, Data collection endpoint sits in Azure Monitor data collection, Data Collection Rules, Azure Monitor Agent, ingestion endpoints, configuration endpoints, and private. It is configured through DCE resources, regional placement, network access settings, private endpoints, DCR references, and monitored resource associations and validated by checking endpoint properties, DCR references, agent health, failed ingestion, Activity Log changes, and Log Analytics arrival delays. It connects to Azure Monitor Agent, Data Collection Rules, Log Analytics workspaces, private endpoints, VMs, Arc servers, and. For production reviews, compare portal state, CLI output, deployment JSON, logs, and runbook notes. Treat it as live configuration that affects.

Exam context

Compare with

Data collection rule Log Analytics workspace Private Endpoint

Where it is used

Where you see it

  1. In the Azure portal, Data collection endpoint appears around Azure Monitor Data Collection Endpoints, DCR association pages, private endpoint approvals, agent status views, and Log Analytics workspace settings. Operators use this signal to confirm scope.
  2. In infrastructure or source control, Data collection endpoint shows up in Bicep, Terraform, ARM templates, DCR JSON, monitored resource association definitions, private DNS records, and endpoint resource IDs. Reviewers compare those files with deployed resources.
  3. In monitoring and support evidence, Data collection endpoint appears through agent heartbeat gaps, ingestion failures, DCR deployment errors, Activity Log endpoint changes, private DNS issues, and delayed log arrival. These signals help teams diagnose failures.
  4. During incident review, Data collection endpoint is visible when teams trace a failed run, blocked dependency, changed identity, or unexpected configuration back to a named owner.

Common situations

  • Design a production workload where Data collection endpoint must be configured, reviewed, and monitored before customer traffic or regulated data is involved.
  • Create audit evidence that shows the owner, resource scope, access path, and live Azure state for Data collection endpoint.
  • Troubleshoot incidents where Data collection endpoint may affect access, dependency behavior, latency, cost, data freshness, or policy compliance.
  • Compare portal, CLI, infrastructure-as-code, and monitoring evidence so teams do not approve changes from stale assumptions.

Illustrative Azure scenarios

These examples show how the concept can affect design and operations. They are illustrative scenarios, not customer claims.

Scenario 01 Building private monitoring endpoints for substations Scenario, objectives, solution, measured impact, and takeaway.
Scenario

Contoso Energy monitored servers in regional substations that could not send management traffic over unrestricted public paths. Azure Monitor Agent needed a predictable configuration and ingestion endpoint, but earlier firewall exceptions were broad, hard to audit, and different in every region. When telemetry arrived late, network and operations teams disagreed about whether private DNS, endpoint approval, or the agent configuration was responsible.

Goals
  • Keep monitoring traffic inside approved private network paths.
  • Create regional endpoint ownership that network and operations teams could share.
  • Shorten diagnosis when agents stopped sending heartbeat or event data.
Approach using Data collection endpoint

The architecture used a data collection endpoint per operating region, linked to private endpoints, private DNS zones, and the data collection rules that governed each server group. Infrastructure templates deployed the DCE, recorded its immutable resource ID, and connected monitored machines through documented associations. The runbook required engineers to verify DNS resolution, private endpoint approval, DCR destination mapping, and agent connectivity before blaming the workspace or application team.

Potential outcomes
  • Firewall exception requests were reduced because teams referenced approved DCE endpoints.
  • Heartbeat outages were triaged through DNS and endpoint checks in minutes instead of hours.
  • Regional ownership became visible in diagrams, templates, and incident records.
What to learn

A data collection endpoint gives private observability designs a concrete network boundary that teams can inspect and operate.

Scenario 02 Onboarding distributed Arc servers through known endpoints Scenario, objectives, solution, measured impact, and takeaway.
Scenario

Northwind Logistics managed thousands of warehouse and routing servers through Azure Arc. Onboarding scripts installed agents correctly, but telemetry quality varied because some hosts pointed at old endpoints while others used new regional monitoring resources. The fleet team needed a repeatable endpoint reference that could be embedded in deployment templates and checked during onboarding without asking every warehouse network administrator to interpret portal screens.

Goals
  • Standardize endpoint configuration for Arc-enabled servers across warehouses.
  • Catch regional endpoint or DNS mistakes before hosts entered production support.
  • Give central operations a reliable inventory of monitoring endpoint usage.
Approach using Data collection endpoint

Engineers created a data collection endpoint catalog by region and environment, then updated Arc onboarding automation to select the correct DCE resource ID based on location tags. Data collection rules referenced the approved endpoints, and post-onboarding checks queried agent heartbeat plus association metadata. When a warehouse failed validation, the runbook compared the assigned endpoint, private DNS response, DCR association, and workspace destination instead of reinstalling the agent repeatedly.

Potential outcomes
  • First-pass telemetry validation improved by 46 percent during warehouse onboarding.
  • Endpoint drift was found through configuration inventory rather than emergency tickets.
  • Operations could prove which regional DCE each server used before accepting support ownership.
What to learn

Data collection endpoints help large fleets avoid monitoring drift by making endpoint selection part of automated onboarding.

Scenario 03 Recovering telemetry after a firewall change Scenario, objectives, solution, measured impact, and takeaway.
Scenario

Fourth Coffee Online lost VM performance and application logs after a firewall rule cleanup in its production hub network. Application teams saw empty Log Analytics tables and suspected a workspace outage, while the network team saw no obvious deny rule. The missing evidence affected checkout troubleshooting during a promotion, so the incident lead needed a fast way to prove whether agents could still reach their Azure Monitor data collection endpoint.

Goals
  • Restore production telemetry before the next promotion traffic peak.
  • Identify whether DNS, private endpoint routing, or DCR configuration caused the break.
  • Add monitoring checks that would catch endpoint reachability problems earlier.
Approach using Data collection endpoint

The response team traced each affected VM from its DCR association to the expected data collection endpoint. They tested private DNS resolution, inspected private endpoint connection state, reviewed Activity Log changes, and compared agent heartbeat timestamps across subnets. A rollback reopened the required path to the DCE, and the permanent fix added an automated check that validates endpoint reachability after every network policy deployment.

Potential outcomes
  • Telemetry returned within forty minutes after the DCE path was isolated.
  • The incident report separated endpoint reachability from workspace and agent health.
  • Network release checks now include DCE DNS and private endpoint validation.
What to learn

During monitoring incidents, the data collection endpoint is often the fastest clue that the problem is network reachability rather than the workspace.

Azure CLI

Use Azure CLI for Data collection endpoint when you need repeatable evidence from live Azure resources instead of a one-off portal screenshot. Start with read-only checks, compare output with source-controlled intent, and attach the result to the change, incident, or audit record.

Useful for

  • Confirm the active subscription, resource group, owner, and current configuration before approving a change involving Data collection endpoint.
  • Export read-only evidence for audits, incidents, migrations, or architecture reviews where Data collection endpoint affects production behavior.
  • Compare CLI output with infrastructure templates and monitoring dashboards to find drift, missing dependencies, or unsafe assumptions.

Before you run a command

  • Confirm the tenant, subscription, resource group, region, and exact resource names before trusting command output.
  • Prefer read-only commands first; require change approval before commands that create, update, start, stop, rerun, or delete resources.
  • Check RBAC, extension requirements, production freeze windows, and whether output may expose identifiers, endpoints, secrets, or sensitive metadata.

What the output tells you

  • It shows whether Data collection endpoint exists in the expected scope and whether live Azure state matches the documented design.
  • It exposes identities, endpoints, component names, run history, policy settings, dependency references, or output values not obvious from application code.
  • It gives reviewers evidence they can attach to tickets, dashboards, audit notes, deployment records, and post-incident timelines.

Mapped commands

Data collection endpoint operational checks

direct 
az monitor data-collection endpoint list --resource-group <resource-group>
az monitor data-collection endpointdiscoverMonitoring and Observability
read-only Microsoft Learn 
az monitor data-collection endpoint show --resource-group <resource-group> --name <endpoint-name>
az monitor data-collection endpointdiscoverMonitoring and Observability
read-only Microsoft Learn 
az monitor data-collection rule list --resource-group <resource-group>
az monitor data-collection rulediscoverMonitoring and Observability
read-only Microsoft Learn 
az network private-endpoint-connection list --id <resource-id>
az network private-endpoint-connectiondiscoverMonitoring and Observability
read-only Microsoft Learn

Architecture context

Architecture reviews for Data collection endpoint should connect the term to resource scope, identity, networking, monitoring, cost ownership, and rollback evidence.

Security
Security for Data collection endpoint starts with knowing who can configure it, who can read its evidence, and which identities, secrets, network paths, or data stores it depends on. Focus on private endpoint placement, network access rules, RBAC, agent identity, diagnostic logging, and exposure of endpoint identifiers. Use least privilege, managed identities where appropriate, private or approved network paths, and diagnostic logging that is reviewed regularly. Document the owner, approval path, and exception process before production use. During incidents, prove whether access, policy, data, or network controls changed recently instead of relying on stale assumptions. Record the current owner, logging path, approval, and emergency exception process.
Cost
Cost for Data collection endpoint is not only the direct service charge. Watch private endpoints, duplicated regional endpoints, ingestion retries, monitoring storage, diagnostic logs, and engineering time spent resolving blocked telemetry. Small configuration choices can multiply across environments, schedules, regions, or repeated runs. Use budgets, tags, owner reports, and run history to separate valuable usage from avoidable waste. Before expanding scope, estimate volume, retention, test activity, and support effort. After rollout, compare expected cost with actual usage and capture remediation tasks for unused resources, noisy settings, or oversized paths. Review cleanup tasks and expected usage before approving wider rollout. Review cleanup tasks and expected usage before approving wider rollout.
Reliability
Reliability for Data collection endpoint means the workload still behaves predictably when dependencies fail, schemas change, policies update, or traffic spikes. Plan around regional placement, agent reachability, DCR dependencies, private DNS, endpoint health, and fallback procedures for blocked ingestion. Monitor both the Azure resource and the user-visible symptom, because the first warning may appear in logs, metrics, latency, missing data, or failed background work. Keep rollback steps and dependency owners visible in the runbook. Test permission loss, stale configuration, regional events, and partial deployment failures before production reliance. Record tested fallback steps and the first alert responders should trust. Record tested fallback steps and the first alert responders should trust.
Performance
Performance for Data collection endpoint depends on how quickly the related workflow produces trustworthy results without overloading sources, agents, networks, or downstream services. Pay attention to agent configuration latency, ingestion delay, DNS resolution, private link routing, high-volume telemetry bursts, and workspace query freshness. Measure the user-visible or operator-visible outcome, not just whether the resource exists. For production changes, compare baseline and post-change latency, throughput, error rate, and queue behavior. Tune in small steps, because aggressive parallelism, broad filters, or oversized test data can create throttling and hide the real bottleneck. Retest after network, source, sink, or dependency changes are released.
Operations
Operations for Data collection endpoint should be repeatable and easy for a second engineer to verify. The runbook should cover endpoint inventory, DCR mapping, agent rollout waves, CLI evidence, support runbooks, and ownership of private endpoint approvals. Keep naming, tags, dashboards, tickets, and infrastructure definitions aligned so support teams do not rely on memory. Use read-only CLI commands for routine evidence, and require review before mutating commands. After rollout, compare live state with approved design, check first signals, and record owner follow-up before closing the change. Keep before-and-after evidence linked to the ticket, dashboard, and owning team. Keep before-and-after evidence linked to the ticket, dashboard, and owning team.

Common mistakes

  • Treating Data collection endpoint as a generic concept instead of checking the exact resource, owner, identity, and dependency path.
  • Running a mutating command in the wrong subscription or resource group because the active CLI context was not verified.
  • Assuming the portal, IaC template, CLI output, and monitoring dashboard all represent the same current state without comparing them.