Announcing the Launch of Customizable Email Subjects for Log Search Alerts V2 in Azure Monitor
We are thrilled to announce the launch of a new feature in Azure Monitor: Customizable Email Subjects for Log Search Alerts V2, available during May. What it is Customizable Email Subjects for Log Search Alerts V2 is a new feature that enables customers to personalize the subject lines of alert emails, making it easier to quickly identify and respond to alerts with more relevant and specific information. How it works This feature allows you to override email subjects with dynamic values by concatenating information from the common schema and custom text. For example, you can customize email subjects to include specific details such as the name of the virtual machine (VM) or patching details, allowing for quick identification without opening the email. Getting Started To get started with Customizable Email Subjects for Log Search Alerts V2, you can use the following methods: Using ARM Template: Create an alert rule with action properties using an ARM template. This option will be available during May. In order to create an alert rule with a customize email subject you should use ARM template with the latest API version (2021-08-01): Resource Manager template samples for log search alerts - Azure Monitor | Microsoft Learn And add the action properties parameter with the value of the subject (including static and dynamic values), for example: { "actionProperties": { "Email.Subject": "This is a custom email subject" } } At the end of the blog post you can find an example attached to an ARM template for your use. Using UI: Create an alert rule with action properties using the UI. This option will be available during June. How to use Dynamic values? To customize the email subject, you should use the action properties. The action properties are specified as key/value pairs by using static text, a dynamic value extracted from the alert payload, or a combination of both. The format for extracting a dynamic value from the alert payload is: ${<path to schema field>}. For example: ${data.essentials.monitorCondition}. Use the format of the common alert schema to specify the field in the payload, whether or not the action groups configured for the alert rule use the common schema. Looking Forward We are confident that this feature will significantly enhance your monitoring experience. By providing personalized alert emails, you can quickly identify and respond to issues with more relevant and specific information. Your Feedback Matters We look forward to your feedback, for questions or feedback, feel free to reach out to nolavime@microsoft.com or use the Give Feedback form directly in the Azure Monitor portal.The Azure Copilot Observability Agent Chat - Stop Writing Queries, Start Asking Questions.
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. Start by selecting 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. The agent operates here as your personal observability assistant - and 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 found that NullPointerExceptions caused significant failures in application operations and proceeded to ask the agent to chart operation failures: From exploration to investigation Through your chat with the observability agent, you can also trigger a full, deep investigation process. A deep investigation doesn't handle just one question, but maps all related resources, identifies anomalies, performs correlations, analyzes root causes, and eventually provides you with a detailed report, including findings and recommendations. To do that, ask the agent explicitly to run a deep investigation, or select it from the suggestions provided during the conversation. 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.comAzure Monitor Health Model - API Refresh
API Refresh? Discovery scope extended to include Application Insights Azure Resource Graph query Signals Enhancement for Azure resources Resource health is used as a default signal Recommended signals are available Alert rules can be imported as signals dynamic thresholds for metric signals Aggregation rules Import health reports and data annotations -->> Link to docs
Public Preview Update: Azure Copilot Observability Agent
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 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.comAzure Monitor Service Level Indicators (SLI)
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
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
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 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. 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 MoreAzure VMs host (platform) metrics (not guest metrics) to the log analytics workspace ?
Hi Team, Can some one help me how to send Azure VMs host (platform) metrics (not guest metrics) to the log analytics workspace ? Earlier some years ago I used to do it, by clicking on “Diagnostic Settings”, but now if I go to “Diagnostic Settings” tab its asking me to enable guest level monitoring (guest level metrics I don’t want) and pointing to a Storage Account. I don’t see the option to send the these metrics to Log analytics workspace. I have around 500 azure VMs whose host (platform) metrics (not guest metrics) I want to send it to the log analytics workspace.Introducing Azure Managed Grafana MCP: The Managed Telemetry Gateway for AI Agents
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 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 LearnIntroducing Azure Managed Grafana 12
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.
