Introducing the enhanced query diagnostics in Azure Log Analytics
We’re excited to introduce a set of new capabilities that simplify query diagnostics and troubleshooting in Azure Log Analytics. With this new experience, users can now easily resolve query issues that may surface using the suggested recommendations, have a deeper visibility into query execution statistics and utilize those to optimize query performances. What’s new? Improved query notification experience Concise details providing a clear understanding of query status, errors, and root cause Actionable recommendations and suggestions to quickly resolve query issues Contextual linkage to the Query Details pane for advanced diagnostics The revamped 'Query Details' pane After running a query, you can navigate to the revamp Query details to explore multiple query aspects over the new tabs: Overview – A curated set of key performance indicators, including: Execution time breakdown: Engine, Log Analytics Service, and Queue times Metrics such as Total CPU, Memory peak, Response size and more Raw statistics – Complete execution details, referenced workspaces, and technical metadata Errors – Raw error payloads for precise and advanced debugging With these enhancements, query troubleshooting is made easier - All within the familiar Azure Log Analytics experience over the Azure Portal. Learn more: Optimize log queries in Azure Monitor - Azure Monitor | Microsoft Learn
Logic Flow name in Azure Log Analytics
dependencies | where type == "Ajax" | where success == "False" | where name has "logicflows" | project timestamp, name, resultCode, duration, type, target, data, operation_Name, appName | order by timestamp desc This KQL query in Azure Application Insights> Azure Log Analytics is used to get errors for logicflows. It returns the data but, I cannot see the logicflow name or ID anywhere. Is there any way to fetch logicflow ID? The azure app insight is registered for a power app, where we are using automate flows to call apis. We need the flow's name in analytics. I tried looking the database, there is no field for logic flow's name or ID. Though when seen in user>sessions, it shows name in requestHeaders.
Announcing resource-scope query for Azure Monitor Workspaces
We’re excited to announce the public preview of resource-scope query for Azure Monitor Workspaces (AMWs)—a major step forward in simplifying observability, improving access control, and aligning with Azure-native experiences. This new capability builds on the successful implementation of resource-scope query in Log Analytics Workspaces (LAWs), which transformed how users access logs by aligning them with Azure resource scopes. We’re now bringing the same power and flexibility to metrics in AMWs. What is resource-scope query? Resource-scope query has been a frequently requested capability that allows users to query metrics scoped to a specific resource, resource group, or subscription—rather than needing to know which AMW the metrics are stored in. This means: Simpler querying: users can scope to the context of one or more resources directly, without knowledge of where metrics are stored. Granular Azure RBAC control: if the AMW is configured in resource-centric access mode, user permissions are checked against the resources they are querying for, rather than access to the workspace itself - just like how LAW works today. This supports security best practices for least privileged access requirements. Why use resource-centric query? Traditional AMW querying required users to: Know the exact AMW storing their metrics. Have access to the AMW. Navigate away from the resource context to query metrics. This created friction for DevOps teams and on-call engineers who do not necessarily know which AMW to query when responding to an alert. With resource-centric querying: Users can query metrics directly from the resource’s Metrics blade. Least privilege access is respected—users only need access to the resource(s) they are querying about. Central teams can maintain control of AMWs while empowering app teams to self-monitor. How does it work? All metrics ingested via Azure Monitor Agent are automatically stamped with dimensions like Microsoft.resourceid, Microsoft.subscriptionid, and Microsoft.resourcegroupname to enable this experience. The addition of these dimensions does not have any cost implications to end users. Resource-centric queries use a new endpoint: https://query.<region>.prometheus.monitor.azure.com We will re-route queries as needed from any region, but we recommend choosing the one nearest to your AMWs for the best performance. Users can query via: Azure Portal PromQL Editor Grafana dashboards (with data source configuration) Query-based metric alerts Azure Monitor solutions like Container Insights and App Insights (when using OTel metrics with AMW as data source) Prometheus HTTP APIs When querying programmatically, users pass an HTTP header: x-ms-azure-scoping: <ARM Resource ID> Scoping supports a single: Individual resource Resource group Subscription At this time, scoping is only support at a single-resource level, but comma-separated multi-resource scoping will be added by the end of 2025. Who Can Benefit? Application Teams: Query metrics for their own resources without needing AMW access. Central Monitoring Teams: Maintain control of AMWs while enabling secure, scoped access for app teams. DevOps Engineers: Respond to alerts and troubleshoot specific resources without needing to locate the AMW(s) storing the metrics they need. Grafana Users: Configure dashboards scoped to subscriptions or resource groups with dynamic variables without needing to identify the AMW(s) storing their metrics. When Is This Available? Microsoft. dimension stamping* is already complete and ongoing for all AMWs. Public Preview of the resource-centric query endpoint begins October 10th, 2025. Starting on that date, all newly created AMWs will default to resource-context access mode. What is the AMW “access control mode”? The access control mode is a setting on each workspace that defines how permissions are determined for the workspace. Require workspace permissions. This control mode does NOT allow granular resource-level Azure RBAC. To access the workspace, the user must be granted permissions to the workspace. When a user scopes their query to a workspace, workspace permissions apply. When a user scopes their query to a resource, both workspace permissions AND resource permissions are verified. This setting is the default for all workspaces created before October 2025. Use resource or workspace permissions. This control mode allows granular Azure RBAC. Users can be granted access to only data associated with resources they can view by assigning Azure read permission. When a user scopes their query to a workspace, workspace permissions apply. When a user scopes their query to a resource, only resource permissions are verified, and workspace permissions are ignored. This setting is the default for all workspaces created after October 2025. Read about how to change the control mode for your workspaces here. Final Thoughts Resource-centric query brings AMWs in line with Azure-native experiences, enabling secure, scalable, and intuitive observability. Whether you’re managing thousands of VMs, deploying AKS clusters, or building custom apps with OpenTelemetry, this feature empowers you to monitor in the context of your workloads or resources rather than needing to first query the AMW(s) and then filter down on what you’re looking for. To get started, simply navigate to your resource’s Metrics blade after October 10 th , 2025 or configure your Grafana data source to use the new query endpoint.Making Azure the Best Place to Observe Your Apps with OpenTelemetry
Our goal is to make Azure the most observable cloud. To that end, we are refactoring Azure’s native observability platform to be based on OpenTelemetry, an industry standard for instrumenting applications and transmitting telemetry.Automate Your Log Analytics Workflows with AI and Logic Apps
In this post, we’ll demonstrate how to build a simple yet powerful workflow using Azure Logic Apps, Log Analytics queries, and LLMs to automate log analysis, save time, and spot issues faster. While we focus here on an example using Application Insights data with Azure OpenAI, the same approach can be applied to any Log Analytics source - whether raw logs, security events, or custom logs. By customizing your queries and AI prompts to match your data and the model’s capabilities, you can easily adapt this workflow to meet your specific needs. Note: This blog post offers guidance for automating workflows with Log Analytics data and LLMs using existing Azure Monitor products. It’s intended as a flexible approach based on user needs and preferences, providing an additional option alongside other Microsoft experiences, such as Azure Monitor issues and investigations (preview). Application Insights as a Use Case Imagine you’re an Application Insights user relying on the AppTraces table - detailed logs of events, errors, and critical traces. You need to spot hour-over-hour spikes or drops, identify operations causing the most issues, and detect recurring patterns or keywords that reveal deeper problems. These insights help turn raw data into actionable information. Running queries and analyzing logs regularly is essential, and automation offers a way to make this process more efficient. This saves time and helps you focus on the most impactful insights - so you can quickly move on to what matters next. With Azure Logic Apps, you can create a recurring workflow that automatically runs your Log Analytics queries, sends the summarized results to Azure OpenAI for analysis, and delivers a clear, actionable report straight to your inbox on your preferred schedule. From Logs to Insights: Step-by-Step AI Workflow 1. Create a Logic App Go to the Azure Portal and create a new Logic App. Open the Logic App Designer to start building your workflow. Helpful resource: Overview - Azure Logic Apps | Microsoft Learn 2. Set a Trigger Add a trigger to start your flow - for this scenario, we recommend using the Recurrence trigger to schedule it on a weekly basis (or any frequency you prefer). Of course, you can choose other triggers depending on your specific needs. 3. Query Your Log Analytics Data Add the Azure Monitor Logs - “Run query and list results” connector to your Logic App. Connect it to your Log Analytics workspace (or another relevant resource). Write a Kusto Query Language (KQL) query to pull data from Log Analytics Tables. In our example, the query retrieves aggregated error-level (SeverityLevel = 3) and critical-level (SeverityLevel = 4) traces from the last week, grouped by hour and operation name, with three sample messages for context. This not only shows the number of errors, when they occurred, and which operations were most affected, but also gives the LLM in the next step a solid foundation for uncovering deeper insights and trends. The query: AppTraces | where TimeGenerated > startofday(ago(7d)) | where SeverityLevel in (3, 4) // Error = 3, Critical = 4 | summarize TracesCount = count(), SampleMessages = make_list(Message, 3) by bin(TimeGenerated, 1h), SeverityLevel, OperationName | order by TimeGenerated asc Tip: Log datasets can be huge - use the summarize operator to aggregate results and reduce the volume for the AI model. Helpful resource: Connect to Log Analytics or Application Insights - Azure Logic Apps | Microsoft Learn 4. Prerequisite - Azure OpenAI Resource Configuration Make sure you have an Azure OpenAI resource set up and an AI model (e.g., GPT-4) deployed before continuing with your workflow. Helpful resource: What is Azure OpenAI in Azure AI Foundry Models? | Microsoft Learn 5. Analyze and Summarize with Azure OpenAI In Logic Apps, add an HTTP action and set all the parameters to call the OpenAI API endpoint. Pass the query results from the previous step (step 3) as input and instruct the OpenAI model to: Summarize key findings - for example, the total number of errors and critical events, and identify the top operations generating the most issues. Highlight anomalies or trends - such as trends and spikes in errors over time (hour-by-hour), and detection of recurring error patterns or keywords. Provide recommendations prioritized by urgency to guide the next steps. Format the output in HTML for easy email rendering. Tip: The body structure sent to the AI includes both System and User rules, formatted together as one string (see below). Helpful resource: How to use Assistants with Logic apps - Azure OpenAI | Microsoft Learn Here’s the prompt example: "messages": [ { "role": "system", "content": "You are an Azure AI tool that creates a weekly report based solely on this prompt and input JSON data from Log Analytics. The input is a list of records, each with these fields: TimeGenerated (ISO 8601 timestamp string), SeverityLevel (integer, where 3=Error, 4=Critical), OperationName (string), TracesCount (integer), SampleMessages (JSON string representing a list of up to 3 messages). Your tasks: 1) Sum the TracesCount values accurately to provide total counts for the entire week and broken down by day and SeverityLevel. 2) Present TracesCount counts per OperationName, grouped by hour and day with severity-level breakdowns. 3) Identify and list the top 10 OperationNames by combined Error and Critical TracesCount for the week, including up to 3 unique sample messages per OperationName, removing duplicates. 4) Compare TracesCount hour-by-hour and day-by-day, calculating percentage changes and highlighting spikes (>100% increase) and significant drops. 5) Detect any new OperationNames appearing during the week that did not appear before. 6) Highlight recurring Errors and Critical issues based on keywords: timeout, exception, outofmemory, connection refused. 7) Assign urgency levels based on frequency, impact, and trends. 8) Provide clear, prioritized recommendations for resolving the main issues. Format your output as valid inline-styled HTML using only these tags: <h2>, <h3>, <p>, <ul>, <li>, and <hr>. Include these report sections in this order: Executive Summary, Weekly Totals and Daily Breakdown, Hourly and Daily Trend Comparison, New & Emerging OperationNames, Detailed Operation Errors, Data Quality & Confidence, Recommendations. Include an opening title with the report’s time period." }, { "role": "user", "content": "string(outputs('Run_query_and_list_results'))" } ] } 6. Send the Report via Email Use the Send an email (V2) connector, or another endpoint connector, such as Teams. Send the AI-generated report to your team, stakeholders, or yourself. Customize the email subject, body, and importance level as needed. Section of the final email report: Important reminder: Once your flow is ready, enable it in Logic Apps to ensure it starts running according to the schedule. Key Takeaways By combining Azure Logic Apps, Log Analytics, and Azure OpenAI, you can turn raw, complex logs into clear, actionable insights - automatically. This workflow helps reduce manual analysis time and enables faster responses to critical issues. Ready to try? Build your own automated log insights workflow today and empower your team with AI-driven clarity.General Availability of Azure Monitor Network Security Perimeter Features
We’re excited to announce that Azure Monitor Network Security Perimeter features are now generally available! This update is an important step forward for Azure Monitor’s security, providing comprehensive network isolation for your monitoring data. In this post, we’ll explain what Network Security Perimeter is, why it matters, and how it benefits Azure Monitor users. Network Security Perimeter is purpose-built to strengthen network security and monitoring, enabling customers to establish a more secure and isolated environment. As enterprise interest grows, it’s clear that this feature will play a key role in elevating the protection of Azure PaaS resources against evolving security threats. What is Network Security Perimeter and Why Does It Matter? Network Security Perimeter is a network isolation feature for Azure PaaS services that creates a trusted boundary around your resources. Azure Monitor’s key components (like Log Analytics workspaces and Application Insights) run outside of customer virtual networks; Network security perimeter allows these services to communicate only within an explicit perimeter and blocks any unauthorized public access. In essence, the security perimeter acts as a virtual firewall at the Azure service level – by default it restricts public network access to resources inside the perimeter, and only permits traffic that meets your defined rules. This prevents unwanted network connections and helps prevent data exfiltration (sensitive monitoring data stays within your control). For Azure Monitor customers, Network Security Perimeter is a game-changer. It addresses a common ask from enterprises for “zero trust” network security on Azure’s monitoring platform. Previously, while you could use Private Link to secure traffic from your VNets to Azure Monitor, Azure Monitor’s own service endpoints were still accessible over the public internet. The security perimeter closes that gap by enforcing network controls on Azure’s side. This means you can lock down your Log Analytics workspace or Application Insights to only accept data from specific sources (e.g. certain IP ranges, or other resources in your perimeter) and only send data out to authorized destinations. If anything or anyone outside those rules attempts to access your monitoring resources, Network Security Perimeter will deny it and log the attempt for auditing. In short, Network Security Perimeter brings a new level of security to Azure Monitor: it allows organizations to create a logical network boundary around their monitoring resources, much like a private enclave. This is crucial for customers in regulated industries (finance, government, healthcare) who need to ensure their cloud services adhere to strict network isolation policies. By using the security perimeter, Azure Monitor can be safely deployed in environments that demand no public exposure and thorough auditing of network access. It’s an important step in strengthening Azure Monitor’s security posture and aligning with enterprise zero-trust networking principles. Key Benefits of Network Security Perimeter in Azure Monitor With Network Security Perimeter now generally available, Azure Monitor users gain several powerful capabilities: 🔒 Enhanced Security & Data Protection: Azure PaaS resources in a perimeter can communicate freely with each other, but external access is blocked by default. You define explicit inbound/outbound rules for any allowed public traffic, ensuring no unauthorized network access to your Log Analytics workspaces, Application Insights components, or other perimeter resources. This greatly reduces the risk of data exfiltration and unauthorized access to monitoring data. ⚖️ Granular Access Control: Network Security Perimeter supports fine-grained rules to tailor access. You can allow inbound access by specific IP address ranges or Azure subscription IDs, and allow outbound calls to specific Fully Qualified Domain Names (FQDNs). For example, you might permit only your corporate IP range to send telemetry to a workspace, or allow a workspace to send data out only to contoso-api.azurewebsites.net. This level of control ensures that only trusted sources and destinations are used. 📜 Comprehensive Logging & Auditing: Every allowed or denied connection governed by Network Security Perimeter can be logged. Azure Monitor’s Network Security Perimeter integration provides unified access logs for all resources in the perimeter. These logs give you visibility into exactly what connections were attempted, from where, and whether they were permitted or blocked. This is invaluable for auditing and compliance – for instance, proving that no external IPs accessed your workspace, or detecting unexpected outbound calls. The logs can be sent to a Log Analytics workspace or storage for retention and analysis. 🔧 Seamless Integration with Azure Monitor Services: Network Security Perimeter is natively integrated across Azure Monitor’s services and workflows. Log Analytics workspaces and Application Insights components support Network Security Perimeter out-of-the-box, meaning ingestion, queries, and alerts all enforce perimeter rules behind the scenes. Azure Monitor Alerts (scheduled query rules) and Action Groups also work with Network Security Perimeter , so that alert notifications or automation actions respect the perimeter (for example, an alert sending to an Event Hub will check Network Security Perimeter rules). This end-to-end integration ensures that securing your monitoring environment with Network Security Perimeter doesn’t break any functionality – everything continues to work, but within your defined security boundary. 🤝 Consistent, Centralized Management: Network Security Perimeter introduces a uniform way to manage network access for multiple resources. You can group resources from different services (and even different subscriptions) into one perimeter and manage network rules in one place. This “single pane of glass” approach simplifies operations: network admins can define a perimeter once and apply it to all relevant Azure Monitor components (and other supported services). It’s a more scalable and consistent method than maintaining disparate firewall settings on each service. Network Security Perimeter uses Azure’s standard API and portal experience, so setting up a perimeter and rules is straightforward. 🌐 No-Compromise Isolation (with Private Link): Network Security Perimeter complements existing network security options. If you’re already using Azure Private Link to keep traffic off the internet, Network Security Perimeter adds another layer of protection. Private Link secures traffic between your VNet and Azure Monitor; Network Security Perimeter secures Azure Monitor’s service endpoints themselves. Used together, you achieve defense-in-depth: e.g., a workspace can be accessible only via private endpoint and only accept data from certain sources due to Network Security Perimeter . This layered approach helps meet even the most stringent security requirements. In conclusion, Network Security Perimeter for Azure Monitor provides strong network isolation, flexible control, and visibility – all integrated into the Azure platform. It helps organizations confidently use Azure Monitor in scenarios where they need to lock down network access and simplify compliance. For detailed information on configuring Azure Monitor with a Network Security Perimeter, please refer to the following link: Configure Azure Monitor with Network Security Perimeter.Public Preview: Smarter Troubleshooting in Azure Monitor with AI-powered Investigation
Investigate smarter – click, analyze, and easily mitigate with Azure Monitor investigations! We are excited to introduce the public preview of Azure Monitor issue and investigation. These new capabilities are designed to enhance your troubleshooting experience and streamline the process of resolving health degradations in your application and infrastructure.Announcing the Public Preview of Azure Monitor health models
Troubleshooting modern cloud-native workloads has become increasingly complex. As applications scale across distributed services and regions, pinpointing the root cause of performance degradation or outages often requires navigating a maze of disconnected signals, metrics, and alerts. This fragmented experience slows down troubleshooting and burdens engineering teams with manual correlation work. We address these challenges by introducing a unified, intelligent concept of workload health that’s enriched with application context. Health models streamline how you monitor, assess, and respond to issues affecting your workloads. Built on Azure service groups, they provide an out-of-the-box model tailored to your environment, consolidate signals to reduce alert noise, and surface actionable insights — all designed to accelerate detection, diagnosis, and resolution across your Azure landscape. Overview Azure Monitor health models enable customers to monitor the health of their applications with ease and confidence. These models use the Azure-wide workload concept of service groups to infer the scope of workloads and provide out-of-the-box health criteria based on platform metrics for Azure resources. Key Capabilities Out-of-the-Box Health Model Customers often struggle with defining and monitoring the health of their workloads due to the variability of metrics across different Azure resources. Azure Monitor health models provide a simplified out-of-the-box health experience built using Azure service group membership. Customers can define the scope of their workload using service groups and receive default health criteria based on platform metrics. This includes recommended alert rules for various Azure resources, ensuring comprehensive monitoring coverage. Improved Detection of Workload Issues Isolating the root cause of workload issues can be time-consuming and challenging, especially when dealing with multiple signals from various resources. The health model aggregates health signals across the model to generate a single health notification, helping customers isolate the type of signal that became unhealthy. This enables quick identification of whether the issue is related to backend services or user-centric signals. Quick Impact Assessment Assessing the impact of workload issues across different regions and resources can be complex and slow, leading to delayed responses and prolonged downtime. The health model provides insights into which Azure resources or components have become unhealthy, which regions are affected, and the duration of the impact based on health history. This allows customers to quickly assess the scope and severity of issues within the workload. Localize the Issue Identifying the specific signals and resources that triggered a health state change can be difficult, leading to inefficient troubleshooting and resolution processes. Health models inform customers which signals triggered the health state change, and which service group members were affected. This enables quick isolation of the trouble source and notifies the relevant team, streamlining the troubleshooting process. Customizable Health Criteria for Bespoke Workloads Many organizations operate complex, bespoke workloads that require their own specific health definitions. Relying solely on default platform metrics can lead to blind spots or false positives, making it difficult to accurately assess the true health of these custom applications. Azure Monitor health models allow customers to tailor health assessments by adding custom health signals. These signals can be sourced from Azure Monitor data such as Application Insights, Managed Prometheus, and Log Analytics. This flexibility empowers teams to tune the health model to reflect the unique characteristics and performance indicators of their workloads, ensuring more precise and actionable health insights. Getting Started Ready to simplify and accelerate how you monitor the health of your workloads? Getting started with Azure Monitor health models is easy — and during the public preview, it’s completely free to use. Pricing details will be shared ahead of general availability (GA), so you can plan with confidence. Start Monitoring in Minutes Define Your Service Group Create your service group and add the relevant resources as members to the service group. If you don’t yet have access to service groups, you can join here. Create Your Health Model In the Azure Portal navigate to Health Models and create your first model. You’ll get out-of-the-box health criteria automatically applied. Customize to Fit Your Needs In many cases the default health signals may suit your needs, but we support customization as well. Investigate and Act Use the health timeline and our alerting integration to quickly assess impact, isolate issues, and take action — all from a single pane of glass. You can access health models today in the Azure portal! For more details on how to get started with health models, please refer to our documentation. We Want to Hear From You Azure Monitor health models are built with our customers in mind — and your feedback is essential to shaping the future of this experience. Whether you're using the out-of-the-box health model or customizing it to fit your unique workloads, we want to know what’s working well and where we can improve. Share Your Feedback Use the “Give Feedback” feature directly within the Azure Monitor health models experience to send us your thoughts in context. Post your ideas in the Azure Monitor community. Prefer email? Reach out to us at azmonhealthmodels@service.microsoft.com — we’re listening. Your insights help us prioritize features, improve usability, and ensure Azure Monitor continues to meet the evolving needs of modern cloud-native operations.Using Azure API Management as a proxy for Application Insights Telemetry
Introduction Organizations enforcing Entra ID authentication on their Application Insights resources often face a sudden problem: browser-based telemetry stops flowing. This happens when local authentication is disabled — a necessary step to enforce strict identity controls — but sending data from browser environments comes with inherent security challenges, and the Application Insights JavaScript SDK is no exception. As a result, telemetry from web clients is silently dropped, leaving gaps in monitoring and frustrated teams wondering how to re-enable secure telemetry ingestion. This article provides a solution: using Azure API Management (APIM) as a secure proxy that authenticates telemetry using a managed identity before forwarding it to Application Insights. This pattern restores observability while honoring your organization's authentication policies. Solution Architecture The proposed architecture involves routing JavaScript-based telemetry data through Azure API Management, which authenticates requests using its managed identity before forwarding them to the Application Insights ingestion endpoint. This setup ensures that only authenticated telemetry is ingested, aligning with security best practices. It's important to note that this change specifically targets telemetry originating from the browser. If your web application also uses Application Insights SDKs (e.g., for .NET, Node.js, Java, or Python) on the server side, those SDKs will continue to send telemetry directly to Application Insights. This is because server-side environments can natively support Entra ID authentication. Step-by-Step Guide Deploy Azure API Management Begin by creating an instance of Azure API Management (APIM). Refer to the official documentation for detailed steps. Enable Managed Identity for APIM Create a managed identity for your API Management service. This identity will be used to authenticate against Application Insights. Instructions are available here. Grant APIM Access to Application Insights Navigate to your Application Insights resource Select Access control (IAM). Select Add then Add role assignment. Choose the Monitoring Metrics Publisher role. Assign this role to the managed identity of your API Management instance Disable Local Authentication in Application Insights Disable local authentication in your Application Insights resource to ensure that only telemetry authenticated with Entra ID is ingested. In your Application Insights resource, select Properties Set Local Authentication to Disabled Add an API to API Management Define a new API in API Management to act as the ingestion endpoint for telemetry sent from the Application Insights JavaScript SDK. This API will serve as the front door, routing incoming telemetry to the appropriate backend for processing. Configure the API to forward requests to the Application Insights ingestion endpoint with the required auth tokens. In the Azure portal, navigate to your API Management instance and select APIs from the resource menu. Add a new HTTP API with the following details: Display Name: App Insights Proxy Web Service URL: The ingestion endpoint from your Application Insights connection string, appended with "/v2.1/track". For example, “https://{your-region}.in.applicationinsights.azure.com/v2.1/track” API URL Suffix: "v2/track" Configure API Management Policies In the Design section of your API: Select All operations. Edit the Inbound processing policy. Leverage the CORS and authentication-managed-identity policies to configure the proxy API. <inbound> <cors allow-credentials="true"> <allowed-origins> <origin>https://your-allowed-origin.com</origin> </allowed-origins> <allowed-methods> <method>POST</method> </allowed-methods> <allowed-headers> <header>Origin</header> <header>X-Requested-With</header> <header>Content-Name</header> <header>Content-Type</header> <header>Accept</header> <header>Cache-Control</header> <header>Sdk-Context</header> <header>X-Set-Cross-Origin-Resource-Policy</header> <header>Content-Encoding</header> </allowed-headers> </cors> <authentication-managed-identity resource="https://monitor.azure.com"/> <base> </inbound> Replace ‘https://your-allowed-origin.com’ with the domain of your web application that hosts the Application Insights JavaScript SDK. This configuration handles CORS preflight requests made by the Application Insights JavaScript SDK and appends the necessary authentication token. You can configure this policy in other APIM policy scopes as desired. Add POST Operation to API Add a POST operation to handle telemetry data sent by the Application Insights SDK. With the newly created API: Select Add Operation Set the URL Method to POST and the path to “/” to ensure that API Management doesn’t alter the request path. This keeps the client-facing URL aligned with the earlier API URL suffix setting and avoids appending extra segments to the backend URL, which is already fully defined in the Web Service URL setting. Disable or Supply API Management Subscription Key To allow unauthenticated clients (like browsers) to send telemetry to the new API: Go to the Settings tab of the new API Uncheck Subscription required Note: If your API Management API requires a subscription key, then you can use the customHeaders configuration from the JavaScript SDK to include the key as the required HTTP header. // ... rest of the SDK setup cfg: { // Application Insights Configuration connectionString: "your-connection-string-value", customHeaders: [{ header: "Ocp-Apim-Subscription-Key", value: "your_APIM-subscription_key_value" }] } }); Update Application Insights SDK Configuration Modify your application’s connection string configuration in the JavaScript SDK to send telemetry to the new API Management proxy API instead of the default ingestion endpoint. Whether you're using the script-based integration or NPM-based integration, make sure the IngestionEndpoint value in your connection string points to your APIM proxy URL. This ensures telemetry is routed through API Management, where it can be authenticated and forwarded to Application Insights. Using Script-based integration: <script type="text/javascript"> !(function (cfg){function e() // ... rest of the SDK setup cfg: { // Application Insights Configuration connectionString: “InstrumentationKey={your-ikey};IngestionEndpoint=https://{your-apim-name}.azure-api.net/;LiveEndpoint=https://…" }}); </script> Using NPM-based integration: If you're using the SDK via NPM, update the `connectionString` in your initialization code the same way: import { ApplicationInsights } from '@microsoft/applicationinsights-web' const appInsights = new ApplicationInsights({ config: { connectionString: 'InstrumentationKey={your-ikey};IngestionEndpoint=https://{your-apim-name}.azure-api.net/;LiveEndpoint=https://...' /* ...Other Configuration Options... */ } }); appInsights.loadAppInsights(); appInsights.trackPageView(); Conclusion By leveraging Azure API Management as a telemetry proxy, you can enforce Entra ID authentication for Application Insights JavaScript telemetry. This approach enhances security without compromising observability, aligning with best practices for modern application monitoring. Limitations: While this approach enables Entra ID authentication and blocks unauthenticated access to your Application Insights resource, it does not fully prevent spoofing from the browser. Because browser environments are inherently exposed, a determined actor could inspect network traffic and simulate telemetry requests to your APIM endpoint. This could result in polluted telemetry or excessive data ingestion that exhausts your daily cap. Additional Considerations Enhancing Telemetry Security with Policies To further enhance security, consider implementing additional API Management policies such as ip-filter and rate-limit-by-key. For more control over the telemetry contents, policies like find-and-replace can help sanitize or redact sensitive telemetry data. It's important to note that this proxy setup does not replace the telemetry controls provided by the JavaScript SDK—features like client-side sampling and custom telemetry initializers still function as expected and remain your first line of defense for managing telemetry volume and quality. Performance and Scalability Implications When routing telemetry through Azure API Management, it’s essential to evaluate the performance trade-offs introduced by the proxy layer. While APIM is designed for high availability and scalability, introducing a proxy can add latency and impact throughput—especially under high telemetry volumes. Key considerations include: Latency: Each telemetry call routed through APIM introduces additional network hops and processing time. This may affect real-time telemetry scenarios or user experience if not properly tuned. Throughput: Ensure your APIM instance can handle the sustained volume of telemetry traffic. Monitor for throttling or dropped requests under load. Rate Limiting: Use policies like rate-limit-by-key to protect your backend and avoid exceeding ingestion quotas in Application Insights. Autoscaling: For production workloads, consider using the Premium tier with autoscaling to dynamically adjust capacity based on demand. For detailed guidance on throughput capacity and scaling strategies, refer to: Azure API Management scalability and performance documentation This built-in flexibility ensures your telemetry proxy remains responsive and reliable as your monitoring needs evolve.Azure Monitor Network Security Perimeter - Features available in 56 Public Cloud Regions
What is Network Security Perimeter? The Network Security Perimeter is a feature designed to enhance the security of Azure PaaS resources by creating a logical network isolation boundary. This allows Azure PaaS resources to communicate within an explicit trusted boundary, ensuring that external access is limited based on network controls defined across all Private Link Resources within the perimeter. Azure Monitor - Network Security Perimeter - Public Cloud Regions - Update We are pleased to announce the expansion of Network Security Perimeter features in Azure Monitor services from 6 to 56 Azure regions. This significant milestone enables us to reach a broader audience and serve a larger customer base. It underscores our continuous growth and dedication to meeting the security needs of our global customers. The Network Security Perimeter feature, now available in these additional regions, is designed to enhance the security and monitoring capabilities of our customers' networks. By utilizing our solution, customers can achieve a more secure and isolated network environment, which is crucial in today's dynamic threat landscape. Currently, NSP is in Public Preview with Azure Global customers, and we have expanded Azure Monitor region support for NSP from 6 regions to 56 regions. The region rollout has enabled our customers to meet their network isolation and monitoring requirements for implementing the Secure Future Initiative (SFI) security waves. Key Benefits to Azure Customers The Network Security Perimeter (NSP) provides several key benefits for securing and managing Azure PaaS resources: Enhances security by allowing communication within a trusted boundary and limiting external access based on network controls. Provides centralized management, enabling administrators to define network boundaries and configure access controls through a uniform API in Azure Core Network. Offers granular access control with NSP rules based on IP addresses or subscriptions. Includes logging and monitoring capabilities for visibility into traffic patterns, aiding in auditing, compliance, and threat identification. Integrates seamlessly with other Azure services and supports complex network setups by associating multiple Private Link Resources with a single perimeter. These characteristics highlight NSP as an excellent instrument for enhancing network security and ensuring data integrity based on the network isolation configuration. For detailed information on configuring Azure Monitor with a Network Security Perimeter, please refer to the following link: Configure Azure Monitor with Network Security Perimeter (Preview) Reference documentation links: Network Security Perimeter - Concepts Transition to a network security perimeter in Azure Have a Question / Any Feedback? Reach us at AzMon-NSP-Scrum@microsoft.com
