Azure Observability Blog articles

Azure Monitor Health Model (Preview): What's New!

shijain13 — Fri, 05 Jun 2026 01:30:56 GMT

Azure Monitor Health Model is a modern observability capability that brings together telemetry, architecture, and business context of your workloads to generate health insights. It continuously aggregates signals across dependencies, producing a single, actionable health state which reduces alert noise and shifts team toward proactive operations with cohesive system view, clearer insights, and faster troubleshooting.

It addresses the common operation question 'Is my system/service/app healthy?' and 'Which underlying unit / component is impacting health?'

This refresh introduces flexible, workload-centric discovery (use application insights topology, Azure resource graph queries in addition to designing user and system flows) and smarter, faster health signal creation (use recommended signals, import existing alert rules, set dynamic thresholds).

Expanded Discovery Scope

As customers began modeling increasingly complex applications, we identified an opportunity to make discovery more flexible and intuitive. Teams naturally reason about their systems differently; some at the application level, others through infrastructure fleets or telemetry views. By expanding discovery options, we enable customers to build health models using the constructs they already use, making it easier to evolve health models as applications and architectures change.

Azure Monitor health models now support multiple discovery mechanisms:

Application Insights–based discovery for application-centric modelling
Azure Resource Graph (ARG) discovery for scalable, query-based resource selection
Continued support for Service Groups, now including nested Service Groups, as part of a broader set of discovery options

This evolution reflects a shift toward loosely coupled modelling, enabling customers to define health based on application architecture rather than infrastructure-centric grouping. Learn more about Discovery

Discovery Rule

Extended Health Signals

Our goal has been to help customers achieve meaningful health insights faster with less manual effort. By introducing platform defaults and surfacing recommended signals, we make it easier to align health models with proven Azure best practices from day one. At the same time, we preserve support for existing alerting strategies and investments, ensuring customers can extend rather than replace what they already have. These enhancements balance simplicity, guidance, and flexibility as environments scale.

Health Models now supports the following health signal capabilities:

Resource Health as a default signal, ensuring every model starts with a reliable platform-provided baseline
Recommended signals, automatically surfaced based on Azure service best practices and enhanced through Azure Monitor Baseline Alerts (AMBA) integration
Reuse of existing signals, enabled by importing Azure Monitor alert rules as health signals

Learn more about Signals

Signals - Recommended and Import from Alert Rules for Azure Resources

Introducing Health Aggregation Rules

Modern cloud applications are built for resiliency, redundancy, and tolerance of partial failure. Health Models are designed to reflect this reality by enabling customers to define what “healthy” means for their architecture. Flexible aggregation rules allow teams to model intent rather than individual component states, producing health views that better align with operational priorities and business impact.

Health Models now supports advanced aggregation logic, enabling the following types of scenarios:

Regional resiliency aggregation using numeric thresholds (e.g., 2 out of 4 regions must remain healthy)
Cluster and fleet health aggregation using percentage thresholds (e.g., 60% of VMs in a cluster must be healthy)

This enables modelling resiliency patterns, partial failures, and graceful degradation, providing a more accurate view of real business impact.

Import Custom Signal

Health is most valuable when it reflects both system behavior and application context. By enabling custom health inputs, customers can incorporate signals that are closest to their business logic and application state. Contextual annotations further enrich analysis, making health timelines easier to interpret and correlate with change events.

To support this, Health Models now provides for:

Custom health report ingestion for external application and system health signals
Data annotations to overlay deployments, incidents, and configuration changes on health state

Alert Experience

To proactively learn about health state change, health models allow creating Alert rules and associated action group trigger automated responses sich as notifying user. It is now possible to view all the alerts on a Health Model and start troubleshooting.

Alerts in Health Model Note: To avail these new capabilities, upgrade your health models to the new API version using built-in migration wizard in Azure portal for a simple, guided experience.

Alerts in Health Model

Note: To avail these new capabilities, upgrade your health models to the new API version using built-in migration wizard in Azure portal for a simple, guided experience.

Is 94% of your syslog just noise? Now you can filter it out before ingestion.

Ivan_Varnitski — Wed, 03 Jun 2026 17:19:40 GMT

At Microsoft Build 2026, we are announcing the public preview of multi-stage transformations for Azure Monitor Data Collection Rules (DCRs). Multi-stage transformations let you filter, aggregate, parse, and map your logs at the point of collection, before data is ingested into your workspace. Processing happens in a defined sequence of steps called processors, and you can chain them together to build precise data pipelines that reduce ingestion volume, improve data quality, and lower monitoring costs.

Processors in orange run on the agent (client-side). The KQL transform in green runs in the ingestion pipeline. Data volume shrinks at each stage.

What are multi-stage transformations?

A Data Collection Rule defines how Azure Monitor collects, transforms, and routes telemetry data. Until now, DCRs supported a single KQL transformation step on the ingestion side. Multi-stage transformations extend this model by introducing a processor pipeline: an ordered sequence of processing steps that run on the agent (client-side) or at the ingestion endpoint (ingestion-side), or both.

Each processor performs one operation: filtering records, parsing structured fields from raw text, renaming or dropping columns, aggregating metrics, or running a KQL expression. Processors execute in order, and the output of one becomes the input to the next. This composable design replaces what previously required complex, monolithic KQL queries or external pre-processing scripts.

Client-side processors run on the Azure Monitor Agent before data leaves the source machine. This means filtered and aggregated data never crosses the network, reducing both egress and ingestion costs. Ingestion-side processors run in the Log Analytics ingestion pipeline and support KQL-based transformations for more complex logic.

Key applications

The most immediate use case is cost reduction. When you can filter records on the agent before they leave the machine, you stop paying for data you never query. Syslog is the classic example: in many environments, informational and debug messages make up the vast majority of volume, and none of it gets looked at unless something breaks. A single filter processor can cut that stream by 90% or more.

Aggregation is equally powerful for high-frequency telemetry. Performance counters sampled every 15 seconds produce millions of records per hour across a large fleet, but most dashboards and alert rules only need 5-minute granularity. Rolling up those samples on the agent, before they cross the network, dramatically reduces ingestion without losing the operational signal your team actually relies on.

Beyond cost, multi-stage transformations improve the quality of the data that does reach your workspace. Parsing structured fields out of raw text (JSON payloads, XML event data, CEF security logs) at collection time means downstream queries are simpler and faster. And because each processor handles one step in a readable sequence, maintaining the pipeline is far easier than debugging a single monolithic KQL expression that tries to do everything at once.

To make this concrete, let’s walk through the two highest-impact patterns we see with preview customers: filtering noisy syslog data and aggregating performance counters.

Filter data before ingestion

The filter processor evaluates each record against conditions you define and drops anything that does not match. Because filtering runs on the agent, dropped records are never serialized, transmitted, or ingested. This makes it the highest-impact processor for cost reduction.

You configure filters using simple field-level conditions: specify a column name, an operator (equals, not equals, greater than, contains, etc.), and a value. Conditions can be combined with AND/OR logic for precise control.

Scenario: Keep only warning-and-above syslog messages

A typical syslog stream generates thousands of informational and debug messages for every actionable warning or error. With a filter processor, you set a severity threshold, and the agent drops everything below it before transmission.

In this example, the filter keeps records where SeverityNumber >= 4 (Warning). The 57,000 debug and informational records per hour are dropped on the machine. Only the 3,250 actionable records are transmitted and ingested, a 94% reduction in syslog volume.

Filters also support compound conditions. For example, you can keep auth-facility errors OR any critical message regardless of facility, all in a single processor step. This kind of targeted filtering is especially useful for security teams that need specific event categories without paying for the full syslog firehose.

Aggregate logs before ingestion

The aggregate processor rolls up high-frequency records into time-windowed summaries on the agent. This is especially valuable for performance counters, heartbeat signals, and any telemetry where per-second granularity is not needed for operational decisions.

You configure the processor with a time window (for example, 5 minutes), the aggregation operators to apply (average, sum, min, max, count), and the dimension columns to group by (such as host name and counter name). The agent collects records within each window, computes the aggregates, and emits one summary record per group.

Scenario: Roll up performance counters into 5-minute summaries

A fleet of 500 VMs, each reporting 10 performance counters every 15 seconds, generates roughly 2 million raw records per hour. Most operational dashboards and alert rules use 5-minute granularity, making the per-sample detail redundant.

With the aggregate processor, each agent rolls up its local counter stream into 5-minute windows, grouped by counter name. Each summary record contains the average, maximum, and sample count for that window.

	Raw data	After aggregation (5-min windows)
Records per VM per hour	2,400 (10 counters x 4/min x 60 min)	120 (10 counters x 12 windows)
Records across 500 VMs per hour	1,200,000	60,000
Volume reduction		95%
Operational fidelity	Per-sample (15s)	Avg, max, and count per 5 min

Because the aggregation runs on the agent, the reduced data set is what gets transmitted and ingested. Dashboards and alerts that rely on 5-minute granularity work identically, but ingestion costs drop by 95%. Route the output to a custom table with columns that match the aggregate output (average, max, count, and your dimension columns).

Chain processors for complete pipelines

Processors are composable. A common pattern chains a header processor (to convert raw data into tabular format), a filter (to drop irrelevant records), a parse step (to extract fields from structured payloads), and a column drop (to remove fields not needed downstream).

Scenario: Parse, filter, and slim down Windows Event logs

Consider a security team that needs logon success and failure events (Event IDs 4624 and 4625) from the Windows Security log. The raw event stream contains hundreds of event types, each carrying a large XML payload. A four-step pipeline handles this:

Header processor converts the raw event stream into tabular rows
Parse processor extracts EventID and TargetUser from the XML payload into typed columns
Filter processor keeps only logon success (4624) and failure (4625) events, dropping everything else
Drop processor removes the bulky RawXml and RenderingInfo columns that are no longer needed

The result is a lean, security-focused data set containing only the events and fields the team actually queries. Each step is independent and can be modified without affecting the others.

Authoring multi-stage DCRs

Multi-stage transformations are available through the Azure portal and through the REST API (version 2025-05-11). The portal provides a visual editor for building processor pipelines, previewing the schema at each stage, and validating the configuration before deployment.

The Transform tab in the DCR data source configuration lets you add processors at each stage and preview the resulting schema.

For infrastructure-as-code workflows, the full DCR JSON can be authored and deployed via ARM templates, Bicep, or direct REST API calls.

To get started:

Open Azure Monitor in the Azure portal and navigate to Data Collection Rules
Create a new DCR or edit an existing one
In the data source configuration, select Edit transformation
Author your transformation logic across client and ingestion stages using the set of available processors
Preview the schema output at each stage to verify the pipeline produces the expected result
Save and associate the DCR with your target resources

Preview notes:

Multi-stage transformations are available in public preview starting June 3, 2026
Client-side processors require Azure Monitor Agent version 1.35 or later
Aggregation output must be routed to custom tables (standard table schemas do not match aggregate output)
Data collection, workspace ingestion, and alert rules may incur costs based on the settings you enable. Preview pricing may differ from general availability pricing. See Azure Monitor pricing for current rates

To learn more, see:

Data Collection Rules overview

Looking ahead

Multi-stage transformations are part of our continued investment in giving teams control over their data before it reaches the workspace. During the preview period, we plan to expand processor coverage, add support for additional data source types, and incorporate user feedback into the authoring and validation experience.

We are also exploring how multi-stage transformations can serve as the foundation for advanced scenarios such as data scrubbing, inline enrichment from external reference data, and AI-assisted pipeline authoring. These capabilities will build on the same processor model, so pipelines you create today will extend naturally as new processors become available.

We welcome your feedback as you try multi-stage transformations. Use the feedback options in the Azure portal, or reach out through your Microsoft account team.

This feature is currently in preview. Previews are provided "as-is," "with all faults," and "as available," and are excluded from the service level agreements and limited warranty. For more information, see Supplemental Terms of Use for Microsoft Azure Previews].

Statements in this post about future plans and capabilities represent our current intentions and are subject to change. They should not be relied upon when making purchasing decisions.

When Telemetry Volume Gets Real: Azure Monitor pipeline’s Performance Story!

susaraswat4 — Wed, 03 Jun 2026 17:19:17 GMT

What is Azure Monitor pipeline?

Azure Monitor pipeline provides centralized governance and a single point of control that runs close to your data sources, so you can filter, transform, aggregate, and route telemetry before it's sent to Azure Monitor. This approach helps you reduce ingestion volume, improve reliability in disconnected environments, and apply consistent data processing across hybrid and multi-cloud deployments. Built on OpenTelemetry technology, the pipeline supports standard ingestion protocols including Syslog and OTLP, enabling it to receive telemetry from a wide range of clients and environments. Read more about Azure Monitor pipeline here - Azure Monitor pipeline GA: Centralized, Secure Telemetry Ingestion

Azure Monitor pipeline Performance

A single replica on a stock 8-core node sustains ~200,000 Syslog messages per second end-to-end into Log Analytics — roughly 17 billion events or ~20 TB per day — using only ~2.8 GB of working-set memory.

That's ~2.5 TB/day of throughput per vCPU, on commodity hardware, with no special tuning. (Measured on pipeline v1.1.1, May 2026.) Find more detailed performance information in the table below -

vCPUs	Example node	Syslog Basic*	Syslog Fully Formed*	CEF Fully Formed*
2	Standard_D2as_v6	~50,000/sec	~35,000/sec	~17,000/sec
4	Standard_D4as_v6	~100,000/sec	~70,000/sec	~35,000/sec
8	Standard_D8as_v6	~200,000/sec	~150,000/sec	~65,000/sec
16	Standard_D16as_v6	~400,000/sec	~300,000/sec	~130,000/sec

Syslog Basic* – Azure Monitor pipeline ingesting raw syslog data into Azure Monitor custom table

Syslog Fully Formed* – Azure Monitor pipeline ingesting syslog data in Azure Monitor standard syslog table

CEF Fully Formed* – Azure Monitor pipeline ingesting CEF data in Azure Monitor standard CEF table

Further, adding replicas scales throughput linearly. Linear scaling is what makes the rest of the performance story credible in practice: if one 4-core node handles about 100,000 Syslog logs per second, eight replicas scale that to roughly 800,000 logs per second without changing the architecture. In other words, you do not hit an arbitrary throughput wall as volume grows—you add cores or replicas and get predictable capacity growth. We are continuously improving these numbers, and the latest guidance is documented here -- Azure Monitor pipeline performance and sizing - Azure Monitor | Microsoft Learn

Why this Performance Story Matters?

Zero-config core usage. The pipeline automatically uses every available CPU core. Move to a bigger node and it just goes faster — no tuning, no config.
Backpressure, not data loss. When you exceed capacity, the pipeline applies TCP backpressure to senders instead of dropping messages. Rising send latency is your scale-up signal.
Predictable sizing math. Pick your per-vCPU rate, divide your peak logs/sec, add 30% headroom, round up. Done.
Efficient memory usage. ~2.8 GB working-set to push 200,000 logs/sec means you're paying for throughput, not overhead.

One sizing tip worth knowing: make sure senders open at least as many concurrent TCP connections as there are cores on the pipeline node. The pipeline distributes traffic across cores by source connection, so too few connections leave cores idle.

How this Stacks Up?

Telemetry pipelines are usually sized per CPU core, making per-core throughput a practical way to reason about capacity and scaling.

Against that backdrop, ~2.5 TB/day per vCPU for Syslog Basic — and ~65,000–150,000 logs/sec, on 8 cores for fully formed records — highlights the per-core efficiency of Azure Monitor pipeline for edge log collection. Exact numbers will vary based on event size and processing applied, but the key point is consistency: you get substantial throughput per core, and it scales linearly as you add capacity.

Less hardware to move the same volume, efficient memory usage, backpressure instead of loss, and linear growth — that's the performance case for Azure Monitor pipeline.

Get started

Spin up a pipeline group on your Arc-enabled cluster, point your Syslog/CEF senders at it, and watch the throughput numbers above hold up in your own environment! Read more about getting started here -- What is Azure Monitor pipeline? - Azure Monitor | Microsoft Learn

New Capabilities to Observe Agents in Azure Monitor

MattMc — Fri, 05 Jun 2026 22:09:44 GMT

Over the last six months, we have been listening to you and building new capabilities to help you observe your agents. You’ve been sharing with us that quality issues are tricky and evaluation is critical, that agent reasoning needs to be understood, that humans must be in the loop to review select agent interactions, and that security and privacy are essential.

To address these concerns, we’re announcing several new capabilities that make agents a first-class artifact in Azure Monitor, so you can debug them in the context of your broader distributed application alongside non-agentic components. Microsoft Foundry remains the surface for building and evaluating agents within the context of your project, while Azure Monitor provides the full-stack observability platform and underlying data foundation that powers those experiences.

Today, we’re announcing new capabilities in Azure Monitor across ingestion, performance, evaluation workflows, agent debugging, and instrumentation updates to help teams get telemetry faster, inspect agent behavior more deeply, and standardize observability across hosting environments and frameworks.

What’s new

Reducing pipeline latency from more than 60 seconds to 7.5 seconds at P90. This makes telemetry available faster for teams troubleshooting agents at scale.
Emitting events up to 1MB and up to 256kB per attribute. Prompts and responses can get large, and this helps avoid data truncation.
Introducing a new view that shows a list of all agents being monitored. Whether you use Microsoft Agent Framework, LangChain, Microsoft Copilot Studio, Foundry Hosting, AKS Hosting, or something else, they all show up here.

Image 1. Fleet View

Improving drill-in from Evaluations to underlying prompts/responses. Evaluations in Azure Monitor are powered by Foundry, and we continue to improve visuals.

Image 2. Evaluation Summary

Showing conversation context in end-to-end transaction view. In chat agents, conversations have become critical glue that connects traces and eases debugging.
Searching by text and showing prompt previews in end-to-end transaction view. Prompts and responses are essential to understanding agent logic, and now you can search based on keyword text in Search and End-to-end transaction details views.
Show evaluation scores in end-to-end transaction details and sort by evaluation score in Search. Evaluation is emerging as a “4^th pillar” of telemetry, and you’ll see it surface more prominently across Azure Monitor Application Insights.
Access the entire JSON blob of prompt/response text. This makes it easier to get to your underlying data and copy out of Azure Monitor for custom analysis/evaluation.

Image 3. Reference image for items No 5-8.Image 4. Correlates with item No 8. Raw JSON.

Adding a “trace tree” to enhance traversing the agent’s reasoning logic. This new addition to end-to-end transaction view makes traversing long-traces much easier.

Image 5. Trace Tree Graph View.

Enabling builders to annotate (i.e., manual evaluations) from transaction details. Get rid of spreadsheets on the side and annotate from within Azure Monitor.

Image 6. Human-in-the-loop Manual Evaluation

Enabling capture of end-user feedback (i.e., thumbs up/down). Brings end-user feedback alongside other telemetry for more powerful troubleshooting.
Extending AI-powered troubleshooting to agents. Observability agent offers full-stack, AI-powered troubleshooting and surfaces up findings in an issue. Learn More.

Image 7. Azure Copilot Observability Agent (in Azure Monitor)

Observability of Coding Agents. Get end-to-end visibility into agent and model usage, performance, and cost with Azure Monitor Application Insights, and built-in Grafana dashboards. Learn More.
A unified “Microsoft OpenTelemetry Distro” to observe agents hosted anywhere. A unified Microsoft OpenTelemetry Distro for observing agents hosted anywhere gives teams a single starting point across Foundry, Azure Monitor, and A365, reducing fragmentation and simplifying onboarding (GH Repos: Python, .NET, JavaScript).
Skills-based enablement. Getting started is easier. Just point your agent to a skill for AI-assisted instrumentation. We also plan to upgrade tools for instrumentation in Azure MCP.

What’s next

We’re continuing to invest in this area, with upcoming work focused on stronger security controls for prompts and responses, better cost transparency for agents, and clearer ways to measure ROI across your agent fleet.

These updates make it possible to observe agents without adopting a separate toolchain. Explore the new capabilities, and if you see gaps, let us know so we can continue shaping the roadmap based on your feedback. Learn More.

Is Your Monitoring Actually Working? What's New in Monitoring Coverage

Nathan_Mangum — Tue, 02 Jun 2026 22:40:52 GMT

Monitoring is only useful when the right signals are collected, the right alerts are in place, and the data is actually flowing when teams need it. In large Azure environments, confirming all three across every VM and AKS cluster can still take too much manual work.

At Microsoft Ignite, we introduced Monitoring Coverage in Azure Monitor, a centralized preview experience for finding coverage gaps and enabling recommended VM and container monitoring at scale. At Microsoft Build, we are expanding that experience with two new capabilities that make monitoring easier to operationalize: data flow status and at-scale recommended alert enablement for virtual machines and Azure Kubernetes Service (AKS).

With these updates, teams can move beyond asking whether monitoring was configured. They can see whether recommended monitoring is enabled, whether important alert coverage is missing, and whether configuration issues may prevent monitoring data from reaching its destination.

Monitoring Coverage overview with recommendations and data flow status.

What is Monitoring Coverage?

Monitoring Coverage in Azure Monitor gives you a single place to review recommended monitoring across supported Azure resources. The Overview page summarizes coverage across your selected scope, shows Azure Advisor observability recommendations, and provides quick actions to enable recommended monitoring settings.

Coverage is grouped into basic, partial, and enhanced monitoring so you can quickly understand whether a resource is using only default monitoring or has the Microsoft-recommended configuration enabled. From there, you can drill into the Monitoring Details tab to review individual resources and take action.

New: data flow status

The most important question after enabling monitoring is simple: is the data flowing? Data flow status helps answer that question directly from Monitoring Coverage.

The new data flow status summary shows how many resources need attention, passed initial checks, or are not configured for validation. It also highlights top resources that need attention so operators can start with the most important issues first.

When you open data flow status for a resource, Azure Monitor shows validation checks across areas such as:

Resource configuration
Data collection rule associations
Network connectivity
Data flows to the configured destination

Detected issues are prioritized at the top of the details pane, and each validation check includes a recommended action. After making a fix, you can run validation again to confirm that data flow issues are resolved.

Data flow status details with validation checks and recommended actions.

Alternatively, you can visualize your data flows and identify problems from there.

New: enable recommended alerts at scale

Monitoring Coverage now also helps close alerting gaps. From the Overview page, you can see recommendations such as Enable VM Recommended Alerts and Enable AKS Recommended Alerts, then select Apply to configure recommended alert rules from a centralized flow.

For virtual machines, you can enable alerts across an entire subscription or choose selected resources. Subscription scope is useful when you want recommended alerts to apply broadly, including to future VMs in the selected subscription. Selected resource scope gives you more granular control when you want to enable alert rules for a specific set of VMs.

The enablement flow lets you review recommended alert rules, adjust thresholds, and configure notification options such as email, Azure Resource Manager role notifications, Azure mobile app notifications, or an existing action group. Some VMs may already have alerts configured, and new rules are designed not to duplicate existing alerts.

For AKS, Monitoring Coverage can surface recommended alert gaps and start the same guided pattern: review impacted resources, configure recommended alert settings, and use Review + Enable to create the alert rules.

VM recommended alert enablement

A resource-centric view for follow-up

The Monitoring Details tab brings coverage and data flow into the same resource list. Two columns are especially useful for triage: Monitoring coverage and Data flow status. Select either value to open resource-level details.

Monitoring coverage details show what is configured for the resource, including VM Insights, recommended alerts, data collection rules, data sources, destinations, and agent version when available. Data flow details show validation results and recommended remediation steps. This makes it easier to move from a high-level gap to the specific resource and configuration that needs attention.

Getting started

Monitoring Coverage is available in preview from the Azure portal. Open Monitor, select Monitoring Coverage (preview), and choose the subscriptions and resources you want to review.

From the Overview page, you can:

Review coverage across VMs and AKS resources.
Apply recommendations to enable VM Insights, container monitoring, and recommended alerts.
Use data flow status to find resources whose monitoring data needs attention.
Open Monitoring Details for resource-level coverage and validation results.

A few preview notes: enablement operations include up to 100 resources at a time, and enabling monitoring or alert rules may create data collection rules, deploy Azure Monitor Agent, configure destinations, or create alert rules. Data collection, workspace ingestion, and alert rules may incur costs based on the settings you enable.

To learn more, see Monitoring coverage in Azure Monitor (preview).

Looking ahead

Monitoring Coverage is part of our continued work to make Azure Monitor easier to operationalize at scale. We want teams to spend less time hunting for monitoring gaps and more time acting on reliable, validated signals.

We would love your feedback as you try these new Build updates and we look to expand support beyond this set of resource types. Use the Azure portal feedback options or share feedback through your Microsoft account team.

What’s new in Observability at Build 2026

Priyanka Nanda — Wed, 03 Jun 2026 19:02:31 GMT

Observability for AI and Agent Workloads

AI agents are moving from prototype to production. To help teams ship and operate agents with the same rigor as the rest of their stack, Azure Monitor & Azure Copilot Observability agent brings end-to-end agent observability — grounded in OpenTelemetry so signals are portable across the toolchain.

Agent Observability in Azure Monitor

Agents are now a first-class artifact in Azure Monitor. With new views showing agent fleet, automated evaluations, cost breakdown, trace tree, and human-in-loop evals, you have the tools you need to gain observability in your agent. Microsoft Foundry is where you build your agents and set up evals, and Azure Monitor is your full-stack observability solution across all layers and components of your distributed service. Now, it’s easier to get started with a streamlined Microsoft OpenTelemetry Distro that powers all observability + governance surfaces including Foundry, Azure Monitor, and Agent 365.

Learn more: aka.ms/agent-obs-blog | Trace agents with the Agent Framework

Azure Copilot Observability agent – what’s new

The Observability agent, enables engineers to investigate issues and explore system behavior using natural language over telemetry data. At Build 2026, new updates expand its capabilities across both chat and investigation workflows. These enhancements include broader investigation entry points (such as AKS and Application Insights), deeper cross-resource analysis, and integration with Microsoft Foundry AI agents. Together, they provide end-to-end visibility into AI-driven systems, help teams move faster from detection to root cause, and enable sharing of investigation results for collaboration and follow-up.

Learn more: Azure Copilot Observability agent (preview) - Azure Monitor | Microsoft Learn |

https://aka.ms/ObsAgentBlogBuild26

ROI of agents in Foundry

A new ROI view in Microsoft Foundry quantifies the business value of deployed agents — correlating cost, usage, and outcomes — so teams can see which agents are paying off and where to invest next.

Smarter, simpler monitoring with Azure Monitor

As cloud environments grow, monitoring gets harder. There is a need for reduced alert noise, less manual tuning, tighter security, and monitoring that is accessible so you can catch real issues faster and spend less time managing the tool.

Resource-scoped querying of Azure Monitor Workspace metrics (GA)

Azure Monitor workspaces now offer users the ability to scope their PromQL queries to one or more Azure resources (e.g., Virtual Machine, AKS, Application Insights, etc.) without requiring the user to have direct access to the AMW(s) where metrics are stored, to streamline the user experience and offer parity with how resource-scoped queries work on Log Analytics Workspaces today.

Learn more: Resource-scoped queries for Azure Monitor workspace - Azure Monitor | Microsoft Learn

Dynamic thresholds for log search alerts (GA)

Log search alerts now support dynamic thresholds at GA, using machine learning to learn each rule’s normal behavior from historical query results and automatically account for hourly, daily, and weekly seasonality. Thresholds are calculated per dimension combination, so multi-dimensional scenarios like AKS pod-restart spikes or resource-inventory drift get tailored baselines out of the box — with no manual tuning and no extra charge beyond the standard log search alert rate.

Learn more: Alert rules with dynamic thresholds overview

Simple log alerts in Azure Monitor (GA)

Simple log alerts are a type of log search alert that evaluates each row individually instead of aggregating over a time window, delivering low-latency detection for scenarios like failed automation jobs or critical Windows events. They also support Basic Logs, so customers can keep the cost savings of Basic-plan telemetry — including Application Insights traces — without giving up the ability to alert on it. Flexible trigger recurrence lets teams tune sensitivity and reduce noise without sacrificing responsiveness.

Learn more: Create a simple log search alert in Azure Monitor

Expanded OpenTelemetry Support

Modern environments span many clouds, languages, and platforms, and customers have increasingly standardized on OpenTelemetry (Otel) to instrument them consistently. The challenge is turning all that telemetry into real insight. Azure Monitor brings OpenTelemetry metrics, logs, and traces into one place where teams can troubleshoot quickly, visualize what’s happening, and act on it. From VMs and servers to applications and AI coding agents, get faster triage, troubleshooting, and ready-made dashboards all from one centralized experience in Azure.

OpenTelemetry App Troubleshooting via OTLP Ingestion (GA)

Azure Monitor now offers flexible, enterprise-ready OpenTelemetry ingestion and data storage to power application performance monitoring experiences. Use standard OpenTelemetry instrumentation and OTLP export to send metrics, logs, and traces to Azure Monitor data collection endpoints. Then monitor, triage, and troubleshoot application and platform performance using Application Insights and pre-built Grafana dashboards entirely based on OpenTelemetry data.

Learn more: https://aka.ms/AzureMonitorOTLPDirectGAblog | Ingest OpenTelemetry data into Azure Monitor.

Monitor AI coding agents with OpenTelemetry (GA)

With Azure Monitor’s OpenTelemetry support, you can collect OpenTelemetry Protocol (OTLP) signals from AI coding agents such as GitHub Copilot and Claude Code, and route them into Azure Monitor for end-to-end visibility. Ingested OTLP data is stored with OpenTelemetry semantics for logs and traces. Application Insights provides curated agent views for troubleshooting, detailed trace visualizations, end-to-end transaction views, and dedicated Grafana dashboards for coding agent monitoring.

Once OpenTelemetry metrics are ingested in Azure Monitor, they can be used to create SLIs.

Learn more: https://aka.ms/AzureMonitorOTLPCodingAgentsblog | https://learn.microsoft.com/en-us/azure/azure-monitor/app/agents-view

OpenTelemetry Metrics, Visualizations, and Enhanced Monitoring for Azure VMs and Servers attached to Azure Arc(GA)

Azure Monitor now supports OpenTelemetry (OTel) metrics and visualizations for Azure Virtual Machines and Arc-enabled Servers, delivering an enhanced, unified monitoring experience. This release brings together key monitoring capabilities including recommended alerts, out-of-the-box Grafana dashboards, and at-scale configuration into a single experience. Customers can more easily monitor Guest OS health, accelerate troubleshooting, and optimize both performance and monitoring costs across their environments.

Learn more: https://aka.ms/vmiv2docs | Collect and customize OpenTelemetry metrics for Azure virtual machines - Azure Monitor

One Data Platform for any source and any destination, built on OpenTelemetry

OpenTelemetry brings consistency to telemetry collection, but production systems need control over how that data is processed and delivered. Learn how Azure Monitor enables centralized governance, multi-stage transformations, unprecedented scale (billions in EPS), and flexible routing for all your telemetry to turn OTel signals into actionable observability.

Learn more: https://aka.ms/datacollectionbuild2026

SLI and SLO (GA)

Azure Monitor now supports service-level indicators and objectives. These special metrics can now measure availability and latency from an end user’s critical journey. Define an SLI across the resources (Service Groups) that make up a service, set an SLO target on your Azure OTel and Prometheus metrics, and track error budget and burn rate from a single view. This lets engineering and SRE teams align day-to-day work to the customer experience, not just per-resource health.

Learn more: Create service level indicators in Azure Monitor.

Get started

We’re continuing Azure Monitor’s investment in efficient, end-to-end observability for developers, SREs, and IT pros. To learn more, connect with our experts at the Build Lightning Session- Broken, costly? Debug and operate AI agents with Azure Monitor on June 3^rd at 9:50 AM PT.

Azure Monitor Copilot Observability Agent: What’s new at Build

EfratNauerman — Tue, 02 Jun 2026 19:30:00 GMT

The Observability agent in Azure Copilot is an AI-powered assistant built into Azure Monitor that helps engineers investigate issues and explore their systems using natural language. By grounding its analysis in telemetry data such as metrics, logs, and traces, it supports both open-ended exploration and guided troubleshooting. For more details, see the documentation.

Since our initial public preview, the Observability agent in Azure Copilot has continued to evolve with new capabilities and expanded coverage (You can read more about the initial release in our previous blog)

At Build 2026, we’re introducing updates that expand the Observability agent’s capabilities and the range of scenarios it can support.
These updates provide deeper analysis and more detailed responses for both exploration and investigation.

Expanded Investigation Scenarios

The Observability agent now supports a broader set of scenarios across applications and infrastructure.

These can be accessed directly from relevant product experiences, without requiring a prior alert, allowing teams to explore data conversationally and initiate deeper investigations as signals emerge.

Integration with Microsoft Foundry AI Agent

The Observability agent integrates with Microsoft Foundry AI Agents, enabling correlation of signals across key generative AI and agent observability scenarios such as latency spikes, error patterns, and tool invocation failures.

Teams can interact with the Observability agent either from alerts - including alerts based on Foundry telemetry - or directly within Application Insights, where the Agents details experience serves as the primary entry point. From there, users can use the Observability agent to diagnose errors, analyze trends, and explore their data across one or multiple agents.

Application Insights integration

The Observability agent enables investigation of failure scenarios directly from Application Insights Failures blade, allowing teams to analyze application-level issues and move from symptom to root cause.

Azure Kubernetes Service (AKS) integration

The Observability agent enables deep investigation of issues in Azure Kubernetes Service (AKS) clusters.

AKS investigations correlate signals from Azure Monitor with Kubernetes logs and events, and (coming soon) Prometheus metrics stored in an Azure Monitor Workspace. Together, these signals enable full‑stack analysis of applications running on AKS.

The Observability agent helps teams determine whether an issue originates from the application or from the underlying Kubernetes platform, reducing time to diagnosis and resolution.

Activity Logs integration

Investigations can be initiated based on Azure Resource Health events surfaced in Activity Logs, enabling analysis of service-impacting signals related to the Azure platform.

Deeper Insights across systems

Multiple Application Insights - Coming soon!

The Observability agent supports investigations that can span multiple Application Insights resources, enabling scenarios that involve multiple services within distributed applications.
The agent can guide users to expand the investigation scope when cross-service issues are detected.

Integration with Azure Service Health

The Observability agent correlates investigation context with Azure Service Health events, helping teams understand potential platform impact as part of their investigation. This helps distinguish application-level issues from broader Azure platform conditions and prioritize active impacts.

Issue management Enhancements

Viewing issues

Issues can now be viewed in multiple places, depending on the required scope:

Azure Monitor: showing issues across all Azure Monitor Workspaces (AMWs) under the selected subscriptions
Azure Monitor Workspace: showing issues stored within a specific AMW

Issue actions & notifications

Issue actions trigger notifications when issues are created or updated, enabling integration with workflows such as email, webhooks, and automation.

Sharing and follow-up

You can now download investigation results as a PDF, including supported data, enabling teams to capture and share investigation context for incident reviews and reporting.

Coming Soon

Billing for the Observability agent starts on July 1, 2026. The agent uses a consumption-based pricing model, so customers pay only for the AI work the agent performs. Agent consumption is measured in Azure Agent Credit (AAC) units, which reflect how many LLM tokens the agent used. For more details, see the documentation.

Stay connected

Follow this blog for ongoing updates and deeper dives into new capabilities
Join our upcoming webinar for real-world scenarios, best practices, and a look at what’s coming next

👉 Register here

We’d love your feedback

The Observability Agent continues to evolve based on real-world usage and customer feedback.

Share feedback through the Give Feedback option in the product or contact us at: azureobsagent@microsoft.com

Want to learn more?

Read our previous blog posts -
Public Preview Update: Azure Copilot Observability Agent | Microsoft Community Hub

The Azure Copilot Observability Agent Chat - Stop Writing Queries, Start Asking Questions. | Microsoft Community Hub

Explore our documentation - Azure Copilot observability agent (preview) - Azure Monitor | Microsoft Learn

Any source. Any destination. Ready for AI-era.

shayoni_seth — Wed, 03 Jun 2026 17:15:19 GMT

Telemetry is exploding, every new app, edge node, and AI agent is a new firehose, and AI has raised the bar on what that telemetry must be: governed, on open standards, observable at agent scale. Today, most teams answer that by stitching together a stack of disconnected tools, each catering to a set of data sources, another that offers transforms, different ones for routing to each destination, and wrappers on top for some essence of much-needed enterprise governance, all struggling to be held together by glue code and tribal knowledge. This is the gap we're closing at Build 2026, with every announcement lining up with what modern, AI-shaped workloads need most:

An AI-native standard, ready for enterprises: OpenTelemetry direct ingest, GA
Headroom for bursty AI-agent traffic: Azure Monitor pipeline scaling to billions of events per day
One governance plane for AI and Azure platform telemetry (via DCRs)
AI-noise controlled at the right point in the journey: Multi-stage transforms
Coverage AI can trust: Monitoring Coverage so AI can reason on complete signals instead of blind spots.

…..All organized around the journey your data takes:

1 · Discover

Most teams think they're monitoring everything, until an incident proves they aren't! Monitoring Coverage turns hope into evidence by answering 3 questions at fleet scale: is monitoring configured, are the right alerts in place, is telemetry actually flowing?

Go from “I think we’re covered” to “I know we are”: Is Your Monitoring Actually Working? What's New in Monitoring Coverage | Microsoft Community Hub

2 · Collect

Whatever your source, Azure-native or open standard, you shouldn't need a different platform, agent, or governance model to bring it in. At Build, two big shifts close that gap:

Govern Azure platform telemetry like the rest of your data: No more per-resource diagnostic settings or separate tooling for platform metrics and logs. They now ride the same policy-based control plane you already use for the rest of Azure Monitor with one model, one audit story, scoped at scale.
- Platform metrics support - GA
- Platform logs support - Public preview coming soon!
Bring OpenTelemetry straight in - GA: Send OTLP logs, metrics, and traces directly to Azure Monitor and land them in Application Insights, Log Analytics, Azure Monitor Workspace (Prometheus), and Grafana, no shim, no detour! Direct OpenTelemetry ingestion into Azure Monitor is now generally available

Have additional OTel collection needs? Tell us us more by filling out this quick survey!

3 · Shape

Observability and storage budgets are dying a death by a thousand low-value log lines. The question today is no longer whether to shape your telemetry, it's where. Multi-stage transformations (public preview) now lets you control telemetry where it matters: at the source, in-pipeline, or post-ingest before, all before data lands at its destination.

Drop noise early, enrich centrally, and optimize cost without losing signal: Is 94% of your syslog just noise? Now you can filter it out before ingestion. | Microsoft Community Hub

4 · Ingest at scale

When telemetry volume spikes, you need a pipeline that doesn't blink. 17 billion events, per day, per replica. That's what Azure Monitor pipeline now sustains, generally available since April ’26, as the living proof of ‘any source, any destination’. This is the high-scale, multi-cloud, edge-resilient engine already trusted in regulated banks, industrial OT networks, and globally distributed SOCs.

That's the kind of headroom you want when AI agents start emitting in bursts you didn't plan for: When Telemetry Volume Gets Real: Azure Monitor pipeline’s Performance Story! | Microsoft Community Hub

Get Started TODAY!

Explore the links above, try the new experiences in Azure Monitor, and tell us in comments below what to build next.

The next era of enterprise telemetry is here. We can't wait to see what you'll build on it.

— Your Azure Monitor team

Monitor AI coding agents with OpenTelemetry in Azure Monitor

KayodePrince — Tue, 02 Jun 2026 14:41:00 GMT

AI coding agents are quickly becoming part of the everyday developer workflow. As teams adopt tools such as GitHub Copilot, Claude Code, and Codex, they need a better way to understand usage, troubleshoot performance, and keep an eye on token consumption and cost.

With Azure Monitor’s OpenTelemetry support, you can collect OpenTelemetry Protocol (OTLP) signals from AI coding agents and route them into Azure Monitor for end-to-end visibility. Ingested OTLP data is stored with OpenTelemetry semantics for logs and traces, Application Insights provides curated agent views for troubleshooting, detailed trace visualizations and end-to-end transaction views.

Image: Application Insights end-to-end transaction view for agents.

Azure Monitor also includes ready-to-use Grafana dashboards that deliver streamlined, out-of-the-box visualizations with the flexibility to customize further. This gives platform teams, engineering leaders, and developers a consistent way to monitor using open-source standards.

The key takeaway is that these dedicated coding agent dashboards surface agent-specific details like feature usage, commit counts, code change acceptance rates, and user details if included in ingested telemetry. That creates immediate value for developer teams and organizations that want to understand adoption rates and the value being returned by coding agents.

Image: Azure Monitor dashboards with Grafana for GitHub Copilot

How it works

Coding agents or IDEs can be configured to export OTLP signals by using organization-wide environment variables, project settings, or shared repository configurations. Note: These settings determine whether content and conversation details are captured and exported. Ensure that your configuration matches your organization's privacy and data handling policies.
An OpenTelemetry Collector can receive OTLP and forward it to Azure Monitor OTLP ingestion endpoints. This OTLP ingestion pipeline uses Entra authenticated and stores logs and traces with OpenTelemetry semantics

Once the data is in Azure Monitor, teams can investigate usage and adoption patterns in Application Insights agent-specific views and visualize trends with pre-built coding agent dashboards in Azure Monitor dashboards with Grafana or Azure Managed Grafana.

Image: OTLP ingestion path from coding agent to Azure Monitor

Why it matters

This approach helps central IT and engineering management teams understand rollout, adoption, and cost across their organization, while giving developers a better view of agent interactions and productivity signals. With OpenTelemetry and Azure Monitor, teams can standardize once, reduce pipeline complexity, and access useful insights faster for these coding agents:

GitHub Copilot
Claude Code
Codex
OpenClaw
Gemini CLI
OpenCode

Get started

AI coding agents are accelerating software development, and observability needs to keep up. Azure Monitor brings together OpenTelemetry and Grafana so you can monitor agent usage and performance with a flexible, standards-based approach.

To learn more, explore:
OpenTelemetry export from Visual Studio Code

OTLP ingestion into Azure Monitor

Coding agent dashboards in Azure Managed Grafana

Monitor AI agents with Application Insights

Direct OpenTelemetry ingestion into Azure Monitor is now generally available

KayodePrince — Tue, 02 Jun 2026 14:39:33 GMT

OpenTelemetry is powering a new era of observability. Built on open standards, designed for portability, and made for developers who want flexibility without compromise. And now, you can send OpenTelemetry logs, metrics, and traces straight into Azure Monitor OTLP endpoints and data storage. This capability is generally available, production-ready, and built to scale from day one.

With direct OTLP ingestion, you can keep your existing OpenTelemetry instrumentation and OpenTelemetry collector pipelines while sending telemetry to Azure Monitor for investigation in Application Insights, analysis in Log Analytics, Prometheus metric storage and visualization in Grafana.

What’s now generally available

Direct OTLP ingestion into Azure Monitor for logs, metrics, and traces.

Production-ready onboarding for deploying data collection rules and endpoints.

Application Insights experiences for distributed tracing, performance investigation, and troubleshooting powered by OTLP data.

Grafana dashboards ready-to-use for visualizing OpenTelemetry signals.

Prometheus data storage and query language for metrics

OpenTelemetry semantic conventions for logs and traces, so data lands in a familiar standards-based schema.

How to send OTLP to Azure Monitor

Instrument your application with OpenTelemetry using the open-source SDKs and configure OTLP export to an OpenTelemetry Collector.

Configure Azure Monitor OTLP ingestion by using an Application Insights resource with OTLP support, which sets up the required Azure Monitor resources and investigation experiences or manually create the required resources.

Export traces, metrics, and logs directly to Azure Monitor from the OpenTelemetry Collector using the built-in OTLP over HTTP exporter.
Get started

Where your telemetry lands

Azure Monitor brings these signals together so your teams can triage and troubleshoot root cause faster without modifying code and instrumentation.

Metrics are stored in an Azure Monitor Workspace, a Prometheus metrics store.

Logs and traces are stored in a Log Analytics workspace using an OpenTelemetry semantic conventions–based schema.

Application Insights lights up distributed tracing and end-to-end performance investigations.

Pre-built Grafana dashboards for OpenTelemetry metrics are available directly in the Azure portal alongside Application Insights.

Why it matters

Standardize once: Instrument with OpenTelemetry and keep your instrumentation vendor neutral and keep your telemetry portable.

Reduce overhead: Fewer bespoke exporters and pipelines to maintain. Stick to OTLP for all cases.

Debug faster: Correlate metrics, logs, and traces to get from reported issues to root cause with less guesswork.

Observe with confidence: Use dashboards and tracing views that are ready on day one.

Next step: Try OTLP export from your environment to Azure Monitor, then validate end-to-end signal flow with Application Insights and Grafana dashboards.

Get started

The Azure Copilot Observability Agent Chat - Stop Writing Queries, Start Asking Questions.

Noa Kuperberg — Mon, 01 Jun 2026 11:04:05 GMT

Services and applications produce massive amounts of telemetry – and making sense of all this data takes effort. Data is often spread across different stores, which means the way to clear insights goes through careful querying, refinement and correlation.

The Azure Copilot Observability agent now has a chat experience that simplifies this dramatically – you just ask, in your own plain, natural language.

Ask questions. Get answers.

To start chatting with the Observability agent, select a resource in the Azure Portal, and choose Logs from the resource menu. Click the Observability agent button. Soon, additional Azure observability experiences will show this or similar buttons so you can chat with the agent throughout your observability process.

The Observability agent chat opens with a short intro message, and a few suggested prompts. Select one of the suggestions or type your question in natural language:

“What errors increased in the last 24 hours?”
“¿Existen anomalías de latencia?” (are there any anomalies)
“どの依存関係が失敗しているか” (which dependencies are failing)

The agent translates your prompt into queries across all relevant data sources, analyses your data, and returns clear, data-backed insights – so you don't need to write KQL queries, switch between logs and metrics experiences, or dive into the schemas of your data store.

Explore your data – interactively

The chat experience is designed for an interactive process of data exploration and troubleshooting. Through the chat you can explore trends in logs and metrics, identify anomalies and visualize results directly in the chat – all from one interface.

Note: The agent operates here as your personal observability assistant - and it can only query data in your behalf, and access resources that you can access.

The chat with the agent has a progressive exploration flow, instead of isolated queries. Still, in each step in the conversation the agent provides a clear chain of thought, and in it - the actual queries it used - so you can keep clear track of how it understood your prompt, and created the provided output.

Results are show clearly and explained. In the example shown here, we follow up and ask the agent to create a time chart of the failed operations impacted by the errors it reported earlier. The result is clear - GET Customers/Details was impacted significantly, reaching 100K failed requests over a long time:

From exploration to guided investigation

The chat is very useful for guided investigations that go as deep as you choose, just as you would with the classic analysis tools over logs or metrics. Following the example shown above, we ask the agent to show exceptions or traces correlated with the failed requests:

The agent found an association to NullReferenceException, and suggests going deeper and use the operation_Id field to clearly identify the request -> dependency -> exception sequence. We'll accept the recommendation and choose the first suggestion: Pull full transaction timeline.

And here it is - each step of the transaction timeline explained, and the culprit is found - a failed Azure Table dependency.

We didn't have to write queries, review metrics, join tables or even know which tables are there. We used standard terms to ask questions in natural language, and we were able to get as deep as we wanted, and can dive deeper still. For example, you can tell the agent to:

Map this call chain into a sequence-diagram style summary showing request, SQL dependency, table write, and exception.
Calculate the average request latency during the last 6 hours, split by client type, location and OS
Find anomalies in the exceptions logged over the last 4 hours
Create a time chart to show the top 3 anomalies
How many users were impacted by each of the top 3 anomalies found? Break down the exception counts by request operation

Launching a deep investigation

Through the chat with the observability agent, you can also trigger a full, deep investigation process.

A deep investigation doesn't handle just one question, but investigates an incident thoroughly - maps all related resources, identifies anomalies, performs correlations, analyzes root causes, and eventually provides a detailed report, including findings and recommendations. To start a deep investigation - select it from the suggestions provided during the conversation, or ask the agent explicitly, for example: run a deep investigation on the NullReferenceException anomaly.

Final thought

If observability used to start with queries – it now starts with a conversation. You can either guide the agent through the process you want to go through - or let it investigate on its own. Just ask.

Stay connected

Follow this blog for ongoing deep dives, updates on current capabilities, and a preview of what’s coming next.
Check out our recent public preview update of the Azure Copilot Observability agent.
Live webinar
A walkthrough of real Observability agent scenarios, best practices, and what’s available today - along with a look at what’s coming next, and live Q&A with the product team. 👉 Register here

We’d love your feedback

The Observability agent continues to evolve based on real‑world usage and operator feedback. Share your thoughts directly through the Give Feedback option in the experience, or reach us at: azureobsagent@microsoft.com

Public Preview Update: Azure Copilot Observability Agent

EfratNauerman — Thu, 14 May 2026 08:41:01 GMT

Modern cloud applications generate massive amounts of telemetry - metrics, logs, traces, alerts, and platform signals.

Yet whether you're asking questions about your observability data or responding when things go wrong, discovering insights and root causes requires a deep understanding of the application, the observability signals it emits, and the tools, while your business and customers are impacted.

The Observability agent is designed to be your monitoring companion across the full observability lifecycle, enabling you to interact via chat to better understand your observability data. Our aspiration is to support the full range of activities - from onboarding and detection through triage and root cause analysis - to significantly reduce human toil and customer downtime.

Today, the agent already covers key investigation and exploration scenarios, and we’re rapidly expanding its capabilities across more workflows and entry points.

Deep, agentic investigations

Deep investigations are designed for situations where something is already wrong and the goal is to understand what happened and what to do next

The Observability agent is optimized for real‑world, full‑stack investigations in distributed systems - including environments built on Azure Kubernetes Service (AKS) and Virtual Machines (VMs). To discover the root cause, the agent applies deep reasoning, using an innovative array of Machine Learning (ML) and Large Language Models (LLM) to discover and correlate anomalies across huge volume of signals across application, infrastructure, and Azure platform layers to converge on likely root‑cause candidates across scenarios such as:

Application issues, including deployment and performance regressions, request or dependency failures, resource exhaustion, and identity or configuration errors
Infrastructure issues, such as compute saturation, disk I/O throttling, misconfigured dependencies, or network connectivity failures in AKS clusters and VMs
Platform incidents, including Azure maintenance or outages and managed infrastructure issues like SNAT port exhaustion or upgrade blockers

The easiest way to start a deep investigation is directly from an Azure Monitor alert, whether in the Azure portal or from an alert notification. Investigations can also be initiated from other entry points – e.g. the agent chat, Logs, Activity logs with additional entry points being added over time

When a deep investigation runs, the agent produces an investigation report that captures the analysis, root cause, suggested next steps along with the key signals, and supporting data. The agent also surfaces a granular insight into its reasoning / chain-of-thought, including data accessed, queries run and more.

User does not need to stop there – they can continue interacting with the agent, in the context of investigation to explore deeper or guide agent into additional hypothesis:

What changed shortly before the incident started?
Are there any issues in VM <vm_id> and are they related? If yes, run a deep investigation including this VM
Which dependencies are most correlated with this failure spike?
Are there related alerts or configuration changes that explain this behavior?

Investigation results can be saved as an Azure Monitor Issue, preserving the full investigation context for collaboration and continuity.

Data exploration and analytics

The Observability agent supports data exploration and analytics for ad‑hoc understanding and hypothesis building, without starting from an alert or running a full investigation.

To get started, simply click on the “Observability Agent” button from the Logs blade (or other supported entry points). From there, you can explore observability data such as logs and metrics using natural language prompts like:

Show the top errors over the last hour
Is there a correlation between application errors and dependency errors?
Chart the trend of application errors and storage related errors
What operations in my app are impacted by the ongoing authentication issue?
Find latency spikes in my app over the last 3 days and where they are coming from (specific users or regions)

If you already had a query / query results in Logs blade – the agent will pick it up automatically, and you can ask it to explain the results, help you evolve the query or even optimize it.

Moreover, when exploration surfaces a broader or more complex problem, operators can choose to run a deep investigation directly from the exploration context and persist the results as an Issue.

Looking ahead

We’re continuing to expand the Observability agent to cover more of the observability lifecycle, moving from reactive investigation toward more proactive and continuous system understanding:

Deeper integration across Azure Monitor experiences
Expanding beyond alerts into additional entry points and workflows across the platform
Autonomous observability
When signals indicate emerging or ongoing incidents, the agent can proactively correlate alerts, run investigations, and create Azure Monitor Issues automatically - reducing the need for manual triage
Integration with external systems
Extending investigation context beyond Azure Monitor, so insights and conclusions can flow into existing engineering workflows

Stay connected

Follow this blog for ongoing deep dives, updates on current capabilities, and a preview of what’s coming next.
Live webinar
A walkthrough of real Observability agent scenarios, best practices, and what’s available today - along with a look at what’s coming next, and live Q&A with the product team. 👉 Register here

We’d love your feedback

Azure Monitor Service Level Indicators (SLI)

Sokuma — Wed, 29 Apr 2026 16:16:56 GMT

Announcing Public Preview of Azure Monitor SLIs

Today, we are excited to introduce Service Level Indicators (SLI) and Service Level Objectives (SLO) in Azure Monitor a step forward in helping teams measure how customers are experiencing their applications.

SLI: A quantitative measure of how well an application or service is performing from the customer’s point of view.

SLO: A defined target for an SLI that represents how good or bad the SLI is over a given time-period. This is also referred to as a baseline in Azure Monitor.

One of the biggest advantages of SLIs is that they quantify real customer impact. In many environments, multiple alerts may fire across infrastructure and services—but not all of them translate to user-visible issues. Metrics like CPU Percentage can measure what is happening in an environment, but not always indicate whether, or how, a spike in CPU impacted the user experience. SLIs provide a clear lens to evaluate whether those signals actually affect customers, helping teams cut through noise and focus on what truly matters. This also represents a shift from traditional thinking about reliability. An application can be “up” and still feel slow or unreliable to users due to latency, partial failures, or downstream dependencies. On the flip side, not every system issue results in a degraded user experience. SLIs bridge this gap by helping measure actual customer experience, not just uptime.

This release brings native SLI authoring, error budgets, as well as a baseline (SLO) and burn rate–based alerting directly into Azure Monitor. Instead of reacting to isolated metrics or alerts, teams can now answer, are we meeting our customer’s promise?

Overview: What is Azure Monitor SLI?

You can now measure both Availability and Latency SLIs using the Request or windows-based evaluation methods.

In Azure Monitor, SLIs are defined at the Service Group level, a logical representation of your application composed of multiple resources. This enables a shift from resource-level monitoring, fragmented alerts to Application-level health, customer-impact measurement and actionable signals. SLIs continuously evaluate your service using existing Azure Monitor metrics and store results in your Azure Monitor Workspace.

These SLIs then power downstream experiences such as baseline tracking, error budgets, burn rate visualization, and alerting—all within Azure Monitor. While Error budgets help teams determine how much degradation they can afford within a given time window and guide decisions such as whether to continue feature rollouts or prioritize reliability improvements. Burn rates indicate how quickly the error budget is being consumed, enabling teams to detect excessive degradation early and take corrective action before user experience is significantly impacted.

Getting Started

To create Application SLIs, you’ll need:

A Service Group.
You must be emitting metrics about your application to an AMW (via Managed Prometheus or Open Telemetry)

Learn more here.

Summary

Azure Monitor SLI brings service health management directly into the Azure platform. By focusing on user experience, tracking error budgets, and alerting on burn rates, teams can understand their workload health alongside platform signals, move from reactive monitoring to proactive reliability engineering and prioritize issues based on real user impact.

We’re excited to see how you use Azure Monitor SLIs to build more reliable applications on Azure.

Ingest at Scale, Securely — Azure Monitor pipeline Is Now Generally Available

XemaPathak — Tue, 21 Apr 2026 20:51:13 GMT

Today, we're thrilled to announce the general availability of Azure Monitor pipeline — a telemetry pipeline built for secure, high-scale ingestion across any environment. But the best way to understand what makes it powerful isn't to start with features. It's to start with the problems that kept showing up, over and over, in our conversations with customers. So, let's dig in...

Chances are, this sounds a lot like your environment

Imagine a large enterprise rolling out Microsoft Sentinel as their SIEM.

They have sites across regions, a mix of on‑premises and cloud environments, and security telemetry streaming in from firewalls, network devices, and Linux servers—100,000 to 1 million events per second in some locations. Traditional forwarders buckle under the load, drop events during network blips, and ship everything – signal and noise – straight into Sentinel. The result: skyrocketing ingestion costs, degraded detections, and a brittle forwarding infrastructure that demands constant babysitting.

If you're managing environments like these, these questions are probably top of mind:

How do I securely ingest telemetry—without opening hundreds of risky endpoints?
How do I reduce ingestion costs when telemetry spikes across thousands of sources simultaneously?
How do I centrally standardize logs across sites and device types before they ever reach Azure?
What happens to telemetry from an entire location when connectivity drops?
And how do I do all of this consistently, at massive scale, and centrally across environments instead of configuring each host individually?

These aren't edge cases. For many teams, getting data into the system itself is the hardest part of observability —and by the time telemetry reaches Azure Monitor or Sentinel, it's already too late to fix these problems.

Customers need control before the data hits the cloud.

What is Azure Monitor pipeline (and why it’s different)?

Azure Monitor pipeline provides a centralized control point for telemetry ingestion and transformation, designed specifically for secure, high‑throughput, enterprise‑scale scenarios. It's built on open-source technologies from the OpenTelemetry ecosystem and includes the components needed to receive telemetry from local clients, process that telemetry, and forward it to Azure Monitor.

It’s not another agent. And NO, you do not need to install it on all the resources…

Agents such as Azure Monitor agent are great for collecting telemetry from individual machines and services. Azure Monitor pipeline solves a different problem:

“How do I ingest telemetry from across my environment through a centralized pipeline – instead of configuring each host – while maintaining control over reliability, security, and ingestion cost?”

With Azure Monitor pipeline control, you can:

Ensure logs land directly in Azure‑native schemas – automatic schematization into tables such as Syslog and CommonSecurityLog
Prevent data loss during intermittent connectivity across sites – local buffering in persistent storage with automated backfill
Reduce ingestion costs before data reaches the cloud – centralized filtering, aggregation, and transformation
Ingest telemetry at sustained high volumes in the range of hundreds and thousands of events per second – horizontally scalable pipeline architecture
Secure telemetry ingestion without managing certificates on each host individually – centralized TLS/mTLS with automated certificate provisioning and zero‑downtime rotation
Maintain visibility into ingestion infrastructure health – pipeline performance and health monitoring
Plan deployments confidently at large scale – infrastructure sizing guidance for expected telemetry volume

And all of this is fully supported and production‑ready in GA. Learn more.

So, let's talk a little bit about these in detail!

Tired of broken detections because logs don't match your table schema? - Automatic schematization (a customer favorite!)

A consistent theme from preview customers was how painful it is to deal with log formats.

Azure Monitor pipeline is the only solution that automatically shapes and schematizes data, so it lands directly in standard Azure tables such as Syslog and CommonSecurityLog. Learn more.

That means:

No custom parsing pipelines downstream
No broken detections due to schema drift
Faster time to value for security teams

This happens before data reaches the cloud – right where it matters most.

What happens to my telemetry when the network goes down? - Local buffering in persistent storage and automated backfill

Networks fail. Maintenance happens. Sites go offline.

Azure Monitor pipeline is built for this reality. It buffers telemetry locally in your configured persistent storage during network interruptions and automatically backfills data when connectivity is restored. Learn more.

The result:

No gaps in security visibility
No manual replays
Confidence that critical telemetry isn’t lost

How do I reduce ingestion costs without sacrificing signal quality? - Filter and aggregate at the edge

Nobody likes to pay for the data that they do not need...

With Azure Monitor pipeline, customers can filter, aggregate, and shape the telemetry at the edge, sending only high‑value data to Azure. Learn more.

This helps teams:

Reduce ingestion costs
Improve detection quality
Keep cloud analytics focused on signal, not volume

Cost optimization and signal quality are no longer trade‑offs – you get both.

How do I keep up when telemetry volumes spike to hundreds of thousands of events per second? - Scaling

One of the biggest pain points we hear is scale.

Azure Monitor pipeline is designed for sustained high throughput ingestion, scaling horizontally and vertically to handle hundreds of thousands to millions of events per second. Learn more.

This isn’t about theoretical limits; it’s about handling the real-world extremes that break traditional forwarders.

How do I send telemetry in a secure manner? - Secure ingestion with TLS and mTLS

Security teams consistently tell us that plain TCP ingestion just isn’t acceptable – especially in regulated environments.

Azure Monitor pipeline addresses this head‑on by providing TLS‑secured ingestion endpoints with mutual authentication, ensuring telemetry is encrypted in transit and accepted only from trusted sources. Learn more.

The result:

Secure ingestion at the boundary by encrypting data in transit using TLS with automated certificate provisioning and zero downtime rotation.
Clients and Azure Monitor pipeline endpoints both validate each other before ingestion by enabling mutual authentication with mTLS, and it’s easy to set it up with our default experience.
Do you have your own PKI and certificate management systems? - Feel free to bring your own certificates to enable secure ingestion.

If the pipeline is this critical — how do I know it's healthy?

One thing we heard loud and clear during preview:

“If this pipeline is critical, I need to see how it’s doing.”

Azure Monitor pipeline now exposes health and performance signals, so it’s no longer a black box. Learn more.

Customers can answer questions like:

Is my pipeline receiving, processing, and sending telemetry?
What’s the CPU and memory usage of each pipeline instance?
Why is a pipeline unhealthy—or down?

Observability for observability felt like the right bar to meet.

How do I plan infrastructure without over- or under-provisioning?

Planning pipeline infrastructure shouldn't be a guessing game – and we heard this loud and clear during preview.

GA includes clear sizing guidance to help you plan the right infrastructure based on your expected telemetry volume and workload characteristics. Not rigid formulas, but practical starting points that give you a confident baseline so you can design intentionally, deploy faster, and avoid costly over- or under-provisioning. Learn more.

Alright, these are a bunch of exciting features. How much do I need to pay for them?

Azure Monitor pipeline is included at no additional cost for ingesting telemetry into Azure Monitor and Microsoft Sentinel.

With general availability, Azure Monitor pipeline is production-ready so you can run the most demanding ingestion scenarios with confidence. If you’re already using it in preview, welcome to GA. If you’re just getting started, there’s never been a better time to dive in.

As always, your feedback is what drives this forward. Drop a comment below, reach out directly, or share what you're building. We'd love to hear from you.

Troubleshoot with OpenTelemetry in Azure Monitor - Public Preview

KayodePrince — Mon, 20 Apr 2026 18:14:20 GMT

OpenTelemetry is fast becoming the industry standard for modern telemetry collection and ingestion pipelines. With Azure Monitor’s new OpenTelemetry Protocol (OTLP) support, you can ship logs, metrics, and traces from wherever you run workloads to analyze and act on your observability data in one place.

What’s in the preview

Direct OTLP ingestion into Azure Monitor for logs, metrics, and traces.
Automated onboarding for AKS workloads.
Application Insights on OTLP for distributed tracing, performance and troubleshooting experiences.
Pre-built Grafana dashboards to visualize signals quickly.
Prometheus for metric storage and query.
OpenTelemetry semantic conventions for logs and traces, so your data lands in a familiar standard-based schema.

How to send OTLP to Azure Monitor: pick your path

AKS: Auto-instrument Java and Node.js workloads using the Azure Monitor OpenTelemetry distro, or auto-configure any OpenTelemetry SDK-instrumented workload to export OTLP to Azure Monitor. Get started
- Limited preview: Auto-instrumentation for .NET and Python is also available. Get started
VMs/VM Scale Sets (and Azure Arc-enabled compute): Use the Azure Monitor Agent (AMA) to receive OTLP from your apps and export it to Azure Monitor. Get started
Any environment: Use the OpenTelemetry Collector to receive OTLP signals and export directly to Azure Monitor cloud ingestion endpoints. Get started

Diagram: Choose your ingestion path

Under the hood: where your telemetry lands

Metrics: Stored in an Azure Monitor Workspace, a Prometheus metrics store.
Logs + traces: Stored in a Log Analytics workspace using an OpenTelemetry semantic conventions–based schema.
Troubleshooting: Application Insights lights up distributed tracing and end-to-end performance investigations, backed by Azure Monitor.

Application Map on OpenTelemetry signals

Why it matters

Standardize once: Instrument with OpenTelemetry and keep your telemetry portable.
Reduce overhead: Fewer bespoke exporters and pipelines to maintain.
Debug faster: Correlate metrics, logs, and traces to get from alert to root cause with less guesswork.
Observe with confidence: Use dashboards and tracing views that are ready on day one.

Next step: Try the OTLP preview in your environment, then validate end-to-end signal flow with Application Insights and Grafana dashboards. Learn More

Copy dashboards from Dashboards with Grafana to Azure Managed Grafana

aayodeji — Thu, 26 Mar 2026 17:28:43 GMT

Azure Monitor Dashboards with Grafana provides an in‑portal Grafana experience optimized for Azure Monitor and managed Prometheus data.

For many teams, that simplicity is exactly what they need.

As observability practices mature, teams often need more than visualization: broader data source support, stronger security controls, and advanced workflows like Azure Managed Grafana MCP. Until now, moving dashboards from Dashboards with Grafana into Azure Managed Grafana often meant recreating them by hand or exporting JSON, extra friction when teams want to move faster.

The new Copy to Managed Grafana experience removes that friction.

Introducing Copy to Managed Grafana from Azure Monitor Dashboards with Grafana

Why a copy experience was needed

Dashboards with Grafana and Azure Managed Grafana serve complementary roles.

Dashboards with Grafana focuses on:

Fast, zero‑setup visualization
Tight integration with Azure Monitor and Prometheus
An embedded experience directly inside the Azure portal

Azure Managed Grafana extends that foundation with:

Full Grafana workflows, including alerts, reporting, and automation
Support for additional data sources and plugins
Enterprise‑grade security features such as private endpoints and managed identity
Cross‑team reuse through folders, APIs, and Role Based Access Controls

Historically, teams that outgrew Dashboards with Grafana didn’t have a simple, in‑product way to bring their dashboards forward, so continuing in a more advanced Grafana environment required extra manual steps.

The goal is simple: copy dashboards to Azure Managed Grafana as needs grow—while continuing to use Dashboards with Grafana for day‑to‑day work.

Introducing “Copy to Managed Grafana”

Customers can now copy dashboards from Dashboards with Grafana into Azure Managed Grafana directly from the Azure portal—without changing the original dashboard.

This feature is:

In‑context – start from your dashboard in Dashboards with Grafana
Seamless – no exports or re‑creation
Non‑disruptive – keep using the source dashboard while you adopt Managed Grafana

The flow is straightforward:

Select “Copy to Managed Grafana” from your dashboard in Dashboards with Grafana. This feature doesn’t work on built-in dashboards, so you would have to save a copy of built-in Dashboards before you can copy those.
Choose an existing Azure Managed Grafana workspace or create a new one
Complete the copy and continue working in a full Grafana environment, making data connections where needed

You can easily copy to an existing Azure Managed Grafana instance or create a new one

Because it appears where teams already build dashboards, the option is easy to find when it becomes relevant.

Advanced capabilities, like additional data sources, alerts, and folder organization, are configured after copying, so teams can adopt them when they’re ready.

This keeps the transition predictable and avoids surprises.

Dashboards with Grafana is the fastest way to visualize Azure Monitor data with Grafana. When teams need more control, scale, or extensibility, Azure Managed Grafana is the natural next step, without forcing you to stop using Dashboards with Grafana.

Together, they form a single observability journey:

Start quickly with Dashboards with Grafana
Copy dashboards into Azure Managed Grafana when you need more capabilities
Enjoy end to end observability within the Azure ecosystem as requirements evolve

You don’t have to trade speed today for flexibility later.

Learn more by reading the doc: Copy an Azure Monitor dashboard to Azure Managed Grafana - Azure Monitor | Microsoft Learn

Introducing Azure Managed Grafana MCP: The Managed Telemetry Gateway for AI Agents

aayodeji — Thu, 19 Mar 2026 20:10:08 GMT

AI agents are rapidly becoming a core part of how teams build, operate, and improve cloud systems, from coding assistants to autonomous remediation workflows. To deliver on that promise in the enterprise, agents need a secure, governed way to access real production telemetry. Azure Managed Grafana MCP lets AI agents securely query the same production telemetry you already connect to Azure Managed Grafana, like Azure Monitor metrics and logs, Application Insights, and Kusto, using your existing Azure RBAC and managed identities.

How do you securely connect AI agents to real production telemetry, without standing up yet another piece of infrastructure?

Today, enabling an agent to query systems like Azure Monitor, Application Insights, or Kusto often requires deploying and operating a self‑hosted MCP server, wiring up identity and networking, and maintaining additional runtime infrastructure. That friction slows adoption and expands the security surface area.

Azure Managed Grafana MCP removes that entire layer.

With this release, every Azure Managed Grafana instance now includes a fully managed, remote MCP server that is ready by default.

What is Azure Managed Grafana MCP?

Azure Managed Grafana MCP is a built‑in, managed MCP endpoint that allows AI agents to securely query enterprise telemetry and operational data through Azure Managed Grafana.

Instead of deploying your own MCP server, customers can simply:

Point their agent to the Azure Managed Grafana MCP endpoint
Grant the agent a managed identity
Start querying production data immediately

No containers. No extra infrastructure. No duplicated auth systems.

Azure Managed Grafana MCP is very easy to configure with your existing AMG instance

Because most Azure Managed Grafana customers already connect data sources like Azure Monitor metrics, logs, Kusto, and Application Insights to Azure Managed Grafana, the MCP server can expose that telemetry to AI agents instantly, using the same RBAC and access controls teams already trust.

Why we built this

As we’ve talked with customers experimenting with Foundry and coding agents, a consistent theme has emerged: agents are only as useful as the data they can reason over.

Requiring teams to stand up and operate a separate MCP layer introduces real cost:

Additional infrastructure to deploy and maintain
Custom identity and token handling
Expanded attack surface
Slower experimentation and adoption

This Azure Managed Grafana MCP takes a different approach. Rather than asking customers to build new infrastructure for agents, we leverage infrastructure they already run and trust: Azure Managed Grafana.

This shifts Grafana from being just a visualization layer to something more strategic:

A secure telemetry access plane
An analytical engine for agent reasoning
A bridge between operational data and autonomous action

Core value propositions

Zero infrastructure overhead

Azure Managed Grafana MCP is fully managed and enabled by default:

No self‑hosted MCP servers
No additional networking configuration

Agents connect directly to Azure Managed Grafana and start querying data.

Secure by design

Security is not bolted on, it’s inherited:

Uses existing Azure RBAC
Supports managed identities
Respects current Azure Managed Grafana access controls

There’s no need to duplicate authentication or authorization logic, and the security posture remains consistent with existing observability access patterns.

Immediate enterprise scenarios

By exposing production telemetry through MCP, teams can unlock high‑value agent workflows immediately:

Root cause analysis using Application Insights
Automated operational summaries
Real‑time diagnostics
Cross‑resource telemetry correlation
Structured data access via Kusto

Chatting with an agent using Azure Managed Grafana MCP in Foundry Playground

Chatting with an agent using Azure Managed Grafana MCP

These are scenarios customers already run manually today and this MCP server makes them accessible to agents.

Closing the loop: from insight to action

One of the most powerful aspects of Azure Managed Grafana MCP is what happens when agents have access to both code context and live telemetry.

For example:

An agent queries Application Insights for production errors
Identifies recurring exception patterns
Locates the source code emitting those errors
Generates a fix and submits a pull request

This closes the loop between observability and remediation, something that’s been largely manual until now.

Designing for agents, not just dashboards

Humans and agents consume data very differently.

Humans:

Navigate dashboards sequentially
Are limited by cognitive bandwidth
Correlate issues manually

Agents:

Process large datasets in parallel
Perform iterative drill‑downs without fatigue
Detect statistically significant patterns quickly

Azure Managed Grafana MCP is designed with this in mind. Instead of only exposing raw data, it enables agent‑optimized tools, like aggregated failure views across dozens of Application Insights instances, so agents can reason efficiently at scale. To make it easier for our customers, it is now available as a native tool within Microsoft Foundry, so you can easily connect it to your Foundry Agents.

Azure Managed Grafana MCP as a native Foundry tool

Looking ahead

Azure Managed Grafana MCP is the foundation for a broader vision:

Observability‑driven autonomous agents
Secure enterprise telemetry reasoning
AI systems that detect, diagnose, and act

Over time, this transforms Azure Managed Grafana from dashboard software into a strategic AI integration layer for Azure.

This isn’t just a visualization feature.

It’s an infrastructure shift.

Check out the doc for more information: Configure an Azure Managed Grafana remote MCP server | Microsoft Learn

Introducing Azure Managed Grafana 12

aayodeji — Fri, 13 Mar 2026 16:54:19 GMT

In this release, Azure Managed Grafana makes it easier to tighten access with current-user Entra authentication, speed up Azure Monitor logs exploration, and level up Prometheus and database monitoring experiences.

What’s new in Azure Managed Grafana 12

Use current-user Entra authentication for supported Azure data sources to query with the signed-in user’s permissions.
Analyze Azure Monitor logs faster with a new query builder and improved visualization and Explore experiences.
Explore Prometheus metrics with improved drill-down, prefix and suffix filters, group-by label support, plus OpenTelemetry and native histogram support.
Use updated, pre-built database monitoring dashboards for Azure PostgreSQL, Azure SQL, and SQL Managed Instance (SQL MI).

Advanced authentication: query with current user’s Entra credentials

Current-user Entra authentication is now available in Azure data sources. That means Grafana admins can configure supported data sources to re-use the logged-in user’s credentials when issuing queries. In practice, the signed-in user’s permissions define what data stores they can access, helping teams apply least-privilege access to each user while keeping the option to use Managed Identities and Service Principals in other data sources where that fits best. Supported data sources include:

Azure Monitor
Azure Data Explorer
Azure Monitor Managed Service for Prometheus

Faster log analysis: Click-to-build queries and smoother Explore

If you live in Azure Monitor logs, this update is for you. Improvements to log visualization in the Logs visualization panel and Grafana Explore make it easier to filter and extract meaningful insights from Azure Monitor logs. There’s also a new Azure Monitor logs query builder, so you can create and refine queries with a few clicks instead of writing Kusto Query Language (KQL) by hand. Performance is significantly faster too. Grafana Explore can now query and render up to 30K log records at a time, so you get much faster load times, faster searches, and more responsive navigation through large log volumes.

Prometheus query enhancements: drill down without the query gymnastics

Users new to Prometheus get a smoother path to explore metrics and analyze time series. Metrics drill-down now includes sidebar filters for prefix/suffix so you can quickly narrow metrics by naming conventions, and group-by label support to build more context-rich groupings. This is a true queryless exploration of Azure Managed Prometheus metrics when you’re troubleshooting or just identifying what’s been collected. This release also adds OpenTelemetry & native histogram support, including an OTel mode to automate label-join complexities when querying OTLP metrics.

New database monitoring dashboards

Azure Managed Grafana now includes new versions of pre-built dashboards for monitoring Azure Database for PostgreSQL and Azure SQL Databases (Preview). For teams building on Azure-native databases, these updated dashboards can help you get to a useful baseline faster, so you spend less time wiring panels and more time acting on what the data is telling you.

Getting started

To try Grafana 12, you can create a new Azure Managed Grafana instance with Grafana 12 selected, or upgrade an existing instance from the Azure portal.

From there, consider enabling current-user Entra authentication for supported Azure data sources, test the new Azure Monitor logs query builder in Explore for day-to-day investigations, and take the updated database dashboards for a spin if you run Azure PostgreSQL, Azure SQL, or SQL MI. Check out the doc for more information: Upgrade Azure Managed Grafana to Grafana 12 - Azure Managed Grafana.

Announcing new public preview capabilities in Azure Monitor pipeline

XemaPathak — Thu, 26 Feb 2026 23:27:24 GMT

Azure Monitor pipeline, similar to ETL (Extract, Transform, Load) process, enhances traditional data collection methods. It streamlines data collection from various sources through a unified ingestion pipeline and utilizes a standardized configuration approach that is more efficient and scalable.

As Azure Monitor pipeline is used in more complex and security‑sensitive environments — including on‑premises infrastructure, edge locations, and large Kubernetes clusters — certain patterns and challenges show up consistently.

Based on what we’ve been seeing across these deployments, we’re sharing a few new capabilities now available in public preview. These updates focus on three areas that tend to matter most at scale: secure ingestion, control over where pipeline instances run, and processing data before it lands in Azure Monitor.

Here’s what’s new — and why it matters.

Secure ingestion with TLS and mutual TLS (mTLS)
Pod placement controls for Azure Monitor pipeline
Transformations and Automated Schema Standardization

Secure ingestion with TLS and mutual TLS (mTLS)

Why is this needed?

As telemetry ingestion moves beyond Azure and closer to the edge, security expectations increase. In many environments, plain TCP ingestion is no longer sufficient.

Teams often need:

Encrypted ingestion paths by default
Strong guarantees around who is allowed to send data
A way to integrate with existing PKI and certificate management systems

In regulated or security‑sensitive setups, secure authentication at the ingestion boundary is a baseline requirement — not an optional add‑on.

What does this feature do?

Azure Monitor pipeline now supports TLS and mutual TLS (mTLS) for TCP‑based ingestion endpoints in public preview.

With this support, you can:

Encrypt data in transit using TLS
Enable mutual authentication with mTLS, so both the client and the pipeline endpoint validate each other
Use your own certificates
Enforce security requirements at ingestion time, before data is accepted

This makes it easier to securely ingest data from network devices, appliances, and on‑prem workloads without relying on external proxies or custom gateways. Learn more.

If the player doesn’t load, open the video in a new window: Open video

Pod placement controls for Azure Monitor pipeline

Why is it needed?

As Azure Monitor pipeline scales in Kubernetes environments, default scheduling behavior often isn’t sufficient.

In many deployments, teams need more control to:

Isolate telemetry workloads in multi‑tenant clusters
Run pipelines on high‑capacity nodes for resource‑intensive processing
Prevent port exhaustion by limiting instances per node
Enforce data residency or security zone requirements
Distribute instances across availability zones for better resiliency and resource use

Without explicit placement controls, pipeline instances can end up running in sub‑optimal locations, leading to performance and operational issues.

What does this feature do?

With the new executionPlacement configuration (public preview), Azure Monitor pipeline gives you direct control over how pipeline instances are scheduled.

Using this feature, you can:

Target specific nodes using labels (for example, by team, zone, or node capability)
Control how instances are distributed across nodes
Enforce strict isolation by allowing only one instance per node
Apply placement rules per pipeline group, without impacting other workloads

These rules are validated and enforced at deployment time. If the cluster can’t satisfy the placement requirements, the pipeline won’t deploy — making failures clear and predictable.

This gives you better control over performance, isolation, and cluster utilization as you scale. Learn more.

Transformations and Automated Schema Standardization

Why is this needed?

Telemetry data is often high‑volume, noisy, and inconsistent across sources. In many deployments, ingesting everything as‑is and cleaning it up later isn’t practical or cost‑effective.

There’s a growing need to:

Filter or reduce data before ingestion
Normalize formats across different sources
Route data directly into standard tables without additional processing

What does this feature do?

Azure Monitor pipeline data transformations, already in public preview, let you process data before it’s ingested.

With transformations, you can:

Filter, aggregate, or reshape incoming data
Convert raw syslog or CEF messages into standardized schemas
Choose sample KQL templates to perform transformations instead of manually writing KQL queries
Route data directly into built‑in Azure tables
Reduce ingestion volume while keeping the data that matters

Check out the recent blog about the transformations preview, or you can learn more here.

Getting started

All of these capabilities are available today in public preview as part of Azure Monitor pipeline.

If you’re already using the pipeline, you can start experimenting with secure ingestion, pod placement, and transformations right away. As always, feedback is welcome as we continue to refine these features on the path to general availability.

Public Preview: Azure Monitor pipeline transformations

susaraswat4 — Thu, 26 Feb 2026 23:25:47 GMT

Overview

The Azure Monitor pipeline extends the data collection capabilities of Azure Monitor to edge and multi-cloud environments. It enables at-scale data collection (data collection over 100k EPS), and routing of telemetry data before it's sent to the cloud. The pipeline can cache data locally and sync with the cloud when connectivity is restored and route telemetry to Azure Monitor in cases of intermittent connectivity. Learn more about this here - Configure Azure Monitor pipeline - Azure Monitor | Microsoft Learn

Why transformations matter

Lower Costs: Filter and aggregate before ingestion to reduce ingestion volume and in turn lower ingestion costs

Better Analytics: Standardized schemas mean faster queries and cleaner dashboards.

Future-Proof: Built-in schema validation prevents surprises during deployment.

Azure Monitor pipeline solves the challenges of high ingestion costs and complex analytics by enabling transformations before ingestion, so your data is clean, structured, and optimized before it even hits your Log Analytics Workspace.

Check out a quick demo here -

If the player doesn’t load, open the video in a new window: Open video

Key features in public preview

1. Schema change detection

One of the most exciting additions is schema validation for Syslog and CEF :

Integrated into the “Check KQL Syntax” button in the Strato UI.

Detects if your transformation introduces schema changes that break compatibility with standard tables.

Provides actionable guidance:

- Option 1: Remove schema-changing transformations like aggregations.

- Option 2: Send data to a custom tables that support custom schemas.

This ensures your pipeline remains robust and compliant with analytics requirements.

For example, in the picture below, extending to new columns that don't match the schema of the syslog table throws an error during validation and asks the user to send to a custom table or remove the transformations.

While in the case of the example below, filtering does not modify the schema of the data at all and so no validation error is thrown, and the user is able to send it to a standard table directly.

2. Pre-built KQL templates

Apply ready-to-use templates for common transformations.

Save time and minimize errors when writing queries.

3. Automatic schema standardization for syslog and CEF

Automatically schematize CEF and syslog data to fit standard tables without any added transformations to convert raw data to syslog/CEF from the user.

4. Advanced filtering

Drop unwanted events based on attributes like:

- Syslog: Facility, ProcessName, SeverityLevel.

- CEF: DeviceVendor, DestinationPort.

Reduce noise and optimize ingestion costs.

5. Aggregation for high-volume logs

Group events by key fields (e.g., DestinationIP, DeviceVendor) into 1-minute intervals.

Summarize high-frequency logs for actionable insights.

6. Drop unnecessary fields

Remove redundant columns to streamline data and reduce storage overhead.

Supported KQL sunctions

1. Aggregation 

summarize (by), sum, max, min, avg, count, bin

2. Filtering 

where, contains, has, in, and, or, equality (==, !=), comparison (>, >=, <, <=)

3. Schematization  

extend, project, project-away, project-rename, project-keep, iif, case, coalesce, parse_json

4. Variables for Expressions or Functions 

5. Other Functions 

String: strlen, replace_string, substring, strcat, strcat_delim, extract 
Conversion: tostring, toint, tobool, tofloat, tolong, toreal, todouble, todatetime, totimespan

Get started today

Head to the Azure Portal and explore the new Azure Monitor pipeline transformations UI. Apply templates, validate your KQL, and experience the power of Azure Monitor pipeline transformations. Find more information on the public docs here - Configure Azure Monitor pipeline transformations - Azure Monitor | Microsoft Learn