Bulk-configure diagnostic settings on Azure Logic Apps Consumptions
Bulk-configure diagnostic settings on Azure Logic Apps — without clicking through the Portal LA-BulkDiag is a small, single-file PowerShell script that does the whole job in one guided run. It enumerates every Consumption Logic App in a resource group, shows you which ones already have settings, lets you pick a scope (every bare LA / every LA / a hand-picked subset), and creates the diagnostic setting on each. It auto-renames on collision so re-running is safe, and it ships with 129 Pester tests covering helpers, parameter binding, and end-to-end flows with a mocked az . Source + full docs: GitHub - dengyanbo/LA-BulkDiag: Bulk diagnostics configuration for Azure Logic Apps What it gives you A numbered, color-coded table of every Consumption LA in the RG and its current diagnostic-setting state (bare / has N / list failed). A single scope prompt — bare / all / pick / cancel — so the common cases are one keystroke. Selection grammar for the picker / -Selection : 1,3-5,8 , bare , all , none . Auto-rename on name collision ( la-diag → la-diag-1 → …) so the upsert behavior of Azure’s API never silently replaces an existing setting. Preflight verification of the destination workspace / storage account via az resource show before touching any Logic App. -WhatIf for a dry-run preview. Non-zero exit code if any LA failed, so it composes cleanly in CI. What it is not: it does not target Standard Logic Apps ( Microsoft.Web/sites with kind=workflowapp ) — those use a different API. It also doesn’t target Event Hub destinations. For everything else, see the “Scope and what this is NOT” section in the GitHub README. Quick start Prerequisites PowerShell 5.1+ (Windows PowerShell or PowerShell 7 — both fine). Azure CLI on PATH: https://aka.ms/installazurecliwindows An interactive az login against the subscription that owns the Logic Apps. Built-in Monitoring Contributor on the RG is enough. Get the script git clone https://github.com/dengyanbo/LA-BulkDiag.git cd LA-BulkDiag One-liner — fully interactive You don’t need to know the destination IDs up front; the script will ask: .\Set-LogicAppDiagnostics.ps1 -ResourceGroup my-rg -SettingName la-diag You’ll see something like: Sub: my-sub (00000000-...) User: alice@contoso.com Destination not provided on the command line. Configure interactively: (paste the full ARM resource ID; leave blank to skip a destination) Log Analytics workspace resource ID: /subscriptions/.../workspaces/my-ws Storage account resource ID: Inspecting 3 Logic App(s) ... Logic Apps in 'my-rg': [ 1] order-processor bare (no settings) [ 2] notification-sender has 1: corp-governance [ 3] data-loader bare (no settings) How do you want to apply 'la-diag'? 1) bare -- apply to every BARE LA (recommended) 2) all -- apply to EVERY LA (may fail Azure-side on non-bare ones) 3) pick -- go into the selective picker 0) cancel Choice [1]: 1 Applying to every BARE LA. ==> order-processor Creating ... OK (Created). ==> data-loader Creating ... OK (Created). ================ Summary ================ LogicApp FinalName Status -------- --------- ------ order-processor la-diag Created data-loader la-diag Created Selected: 2 Succeeded: 2 Renamed: 0 Failed: 0 Not selected: 1 That’s the whole workflow. The commands you’ll actually use Grab the destination IDs once: $wsId = az monitor log-analytics workspace show -g ws-rg -n my-ws --query id -o tsv $saId = az storage account show -g sa-rg -n mysa --query id -o tsv 1. Apply to every bare LA — fully automated .\Set-LogicAppDiagnostics.ps1 -ResourceGroup my-rg ` -WorkspaceId $wsId -SettingName la-diag -Selection bare -Selection bare skips both the scope prompt and the y/N confirm — perfect for CI. 2. Send to both a workspace and a storage account .\Set-LogicAppDiagnostics.ps1 -ResourceGroup my-rg ` -WorkspaceId $wsId -StorageAccountId $saId ` -SettingName la-diag -Selection all 3. Metrics only, storage-only .\Set-LogicAppDiagnostics.ps1 -ResourceGroup my-rg ` -StorageAccountId $saId -SettingName la-metrics ` -Preset metrics-only -Selection all Available presets: all (default) / logs-only / metrics-only / workflowruntime . 4. Specific Logic Apps by index — non-interactive After running once and seeing the numbered table, you can target them directly: .\Set-LogicAppDiagnostics.ps1 -ResourceGroup my-rg -WorkspaceId $wsId ` -SettingName la-diag -Selection '1,3-5,8' 5. Dry-run before committing .\Set-LogicAppDiagnostics.ps1 -ResourceGroup my-rg -WorkspaceId $wsId ` -SettingName la-diag -Selection all -WhatIf 6. Just inspect — list LAs + existing settings, change nothing .\Set-LogicAppDiagnostics.ps1 -ResourceGroup my-rg -WorkspaceId $wsId ` -SettingName whatever -Selection none 7. Run the tests .\unit_test\Run-Tests.ps1 Auto-installs Pester 5 to CurrentUser if missing. Expected: Passed=129 Failed=0 . Selection grammar — cheat sheet Input Meaning 1 , 3 , 7 single index (1-based, matches the table) 1,3,5 multiple indices 1-5 inclusive range 1,3-5,8 mixed bare all LAs with no existing settings (recommended) all every LA (may fail on already-configured ones) none (or empty / q / cancel ) exit without changes Why the auto-rename matters Azure’s diagnostic-settings API is PUT — calling create --name la-diag on a Logic App that already has a setting named la-diag silently replaces the existing one. That’s a footgun if a colleague already set something up by hand. LA-BulkDiag refuses to overwrite. Instead, when -SettingName is already in use on a given LA, it auto-appends -1 , -2 , … until it finds a free name, and reports the actual name in the summary’s FinalName column. If you genuinely want to replace an existing setting, delete it first: az monitor diagnostic-settings delete -n <existing-name> --resource <la-id> Where to go next The GitHub repo has the full reference — parameter table, exit codes, status-value glossary, troubleshooting matrix (RBAC, MFA, throttling, category/sink conflicts), known limitations, and the full test inventory: 👉 https://github.com/dengyanbo/LA-BulkDiagLogic App Standard - When High Memory / CPU usage strikes and what to do
Introduction Monitoring your applications is essential, as it ensures that you know what's happening and you are not caught by surprise when something happens. One possible event is the performance of your application starting to decrease and processing becomes slower than usual. This may happen due to various reasons, and in this blog post, we will be discussing the High Memory and CPU usage and why it affects your Logic App. We will also observe some possibilities that we've seen that have been deemed as the root cause for some customers. How High Memory and high CPU affects the processing When the instructions and information are loaded into Memory, they will occupy a space that cannot be used for other sets of instructions. The more memory is occupied, the more the Operative System will need to "think" to find the correct set of instructions and retrieve/write the information. So if the OS needs more time to find or write your instructions, the less time it will spend actually doing the processing. Same thing for the CPU. If the CPU load is higher, it will slow down everything, because the available workers are not able to "think" multiple items at the same time. This translates into the Logic App processing, by the overall slowness of performance. When the CPU or Memory reach a certain threshold, we start to see the run durations going up and internal retries increasing as well. This is because the runtime workers are busy and the tasks have timeout limits. For example, let's think of a simple run with a Read Blob built-in connector action, where the Blob is very large (let's say 400MB). The flow goes: Request Trigger -> Read blob -> send email The trigger has a very short duration and doesn't carry much overhead, because we're not loading much data on it. The Read Blob though, will try to read the payload into Memory (because we're using a Built-in Connector, and these load all the information into Memory). Built-in connector overview - Azure Logic Apps | Microsoft Learn So, not considering background processes, Kudu and maintenance jobs, we've loaded 400MB into memory. Using a WS1 plan, we have 3.5GB available. By just having a blank Logic App, you will see some memory occupied, although it may vary. So, if we think it takes 500MB for the base runtime and some processes, it leaves us with 3GB available. If we load 4 files at the same time, we will be using ~1.8GB (files + base usage). Already using about 50% of the memory. And this is just for one workflow and 4 runs. Of course the memory is released after the run completes, but if you think on a broader scale, with multiple runs and multiple actions at the same time, you see how easy it is to reach the thresholds. When we see memory over ~70%, the background tasks may behave in unexpected ways, so it's essential to have a clear idea on how your Logic App is working and what data you're loading into it. Same thing for CPU. The more you load into it, the slower it gets. You may have low memory usage, but if you're doing highly complex tasks such as XML transformations or some other built-in data transforms, your CPU will be heavily used. And the bigger the file and the more complex the transformation, the more CPU will be used. How to check memory/CPU Correctly monitoring your resources usage is vital and can avoid serious impact. To help your Standard logic app workflows run with high availability and performance, the Logic App Product Group has created the Health Check feature. This feature is still in Preview, but it's already a very big assistance in monitoring. You can read more about it, in the following article, written by our PG members, Rohitha Hewawasam and Kent Weare: Monitoring Azure Logic Apps (Standard) Health using Metrics And also the official documentation for this feature: Monitor Standard workflows with Health Check - Azure Logic Apps | Microsoft Learn The Metrics can also assist in providing a better view on the current usage. Logic App Metrics don't drill down on CPU usage, because those metrics are not available at App level, but rather at App Service Plan level. You will be able to see the working memory set and Workflow related metrics. Example metric: Private Bytes (AVG) - Logic App metrics On the AppService Plan overview, you will be able to see some charts with these metrics. It's an entry point to understand what is currently going on with your ASP and the current health status. Example: ASP Dashboard In the Metrics tab, you are able to create your own charts with a much greater granularity and also save as Dashboards. You're also able to create Alerts on these metrics, which greatly increases your ability to effectively monitor and act on abnormal situations, such as High Memory usage for prolonged periods of time. Example: Memory Percentage (Max) - ASP Metrics Currently there are multiple solutions provided to analyze your Logic App behavior and metrics, such as Dashboards and Azure Monitor Logs. I highly recommend reading these two articles from our PG that discuss these topics and explain and exemplify this: Logic Apps Standard Monitoring Dashboards | Microsoft Community Hub Monitoring Azure Logic Apps (Standard) with Azure Monitor Logs How to mitigate - a few possibilities Platform settings on 32 bits If your Logic App was created long back, it may be running on an old setting. Early Logic Apps were created with 32 bits, which severely limited the Memory usage scalability, as this architecture only allows a maximum of 3GB of usage. This comes from the Operative System limitations and memory allocation architecture. After some time, the standard was to create Logic Apps in 64 bits, which allowed the Logic App to scale and fully use the maximum allowed memory in all ASP tiers (up to 14GB in WS3). This can be checked and updated in the Configuration tab, under Platform settings. Orphaned runs It is possible that some runs do not finish due to various possibilities. Either they are long running or have failed due to unexpected exceptions, runs that linger in the system will cause an increase in memory usage, because the information will not be unloaded from Memory. When the runs become orphaned, they may not be spotted but they will remain "eating up" resources. The easiest way to find these runs, is to check the workflows and under the "Running" status, check which ones are still running well after the expected termination. You can filter the Run History by Status and use this to find all the runs that are still in "Running". In my example, I had multiple runs that had started hours before, but were not yet finished. Although this is a good example, it requires you to check each workflow manually. You can also do this by using Log Analytics and execute a query to return all the Runs that are not yet finished. You need to activate the Diagnostic Settings, as mentioned in this blog post: Monitoring Azure Logic Apps (Standard) with Azure Monitor Logs To make your troubleshooting easier, I've created a query that does this for you. It will check only for the Runs and return those that do not have a matching Completed status. The OperationName field will register the Start, Dispatch and Completed status. By eliminating the Dispatched status, we're left with Start and Completed. Therefore, this query should return all the RunIDs that have a Start but not a matching Completed status, as it groups them by counting the RunIDs. LogicAppWorkflowRuntime | where OperationName contains "WorkflowRun" and OperationName != 'WorkflowRunDispatched' | project RunId, WorkflowName, TimeGenerated,OperationName, Status, StartTime,EndTime | summarize Runs = count() by RunId, WorkflowName, StartTime | where Runs == 1 | project RunId, WorkflowName, StartTime Large payloads As previously discussed, large payloads can create a big overload and increase greatly the memory usage. This applies not only to the Built-in Connectors, but also to the Managed connectors, as the information stills needs to be processed. Although the data is not loaded into the ASP memory when it comes to Managed connectors, there is a lot of data flowing and being processed in CPU time. A Logic App is capable of processing a big amount of data, but when you combine large payloads, a very large number of concurrent runs, along with large number of actions and Incoming/Outgoing requests, you get a mixture that if left unattended and continues to scale up, will cause performance issues over time. Usage of built-in connectors The Built-in Connectors (or In App) are natively run in the Azure Logic Apps runtime. Due to this, the performance, capabilities and pricing are better, in most cases. Because they are running under the Logic App Runtime, all the data will be loaded in-memory. This requires you to do a good planning of your architecture and forecast for high levels of usage and heavy payload. As previously shown, using Built-in connectors that handle very large payloads, can cause unexpected errors such as Out of Memory exceptions. The connector will try to load the payload into memory, but if starts to load and the memory is no longer available, it can crash the worker and return an Out Of Memory exception. This will be visible in the Runtime logs and it may also lead to the run becoming orphaned, as it get stuck in a state that is not recoverable. Internally, the Runtime will attempt to gracefully retry these failed tasks, and it will retry multiple times. But there is always the possibility that the state is not recoverable and thus the worker crashes. This makes it also necessary to closely monitor and plan for high usage scenarios, in order to properly scale Up and Out your App Service Plans. Learnings Monitoring can be achieved as well through the Log Stream, which requires you to configure a Log Analytics connection, but can provide a great deal of insight of what the Runtime is doing. It can give you Verbose level or simply Warning/Error levels. It does provide a lot of information and can be a bit tricky to read, but the level of detail it provides, can be a huge assistance in troubleshooting from your side and from the Support side. For this, you can navigate to your Log Stream tab, enable it, change to "Filesystem Logs" and enjoy the show. If an Out of Memory exception is caught, it will show up in red letters (as other exceptions show), and will be something similar to this: Job dispatching error: operationName='JobDispatchingWorker.Run', jobPartition='', jobId='', message='The job dispatching worker finished with unexpected exception.', exception='System.OutOfMemoryException: Exception of type 'System.OutOfMemoryException' was thrown. at System.Threading.Thread.StartCore() at System.Threading.Thread.Start(Boolean captureContext) at System.Threading.Thread.Start() No PROD Logic App should be left without monitoring and alerting. Being a critical system or not, you should always plan not only for disaster scenarios but also for higher than usual volumes, because nothing is static and there's always the possibility that the system that today has a low usage, will be scaled and will be used in some way that it was not intended to. For this, implementing the monitoring on the resources metrics is very valuable and can detect issues before they get overwhelming and cause a show stopper scenario. You can use the Metrics from the Logic App that are provided out of the box, or the metrics in the ASP. These last metrics will cover a wider range of signals, as it's not as specific as the ones from the Logic App. You can also create custom Alerts from the Metrics and thus increasing your coverage on distress signals from the Logic App processing. Leaving your Logic App without proper monitoring will likely catch you, your system administrators and your business by surprise when the processing falls out of the standard parameters and chaos starts to arise. There is one key insight that must be applied whenever possible: expect the best, prepare for the worst. Always plan ahead, monitor the current status and think proactively and not just reactively. Disclaimer: The base memory and CPU values are specific for your app, and it can vary based on number of apps in App Service Plan, the number of instances you have as Always Running, etc, and number of workflows in the app, and how complex these workflows are and what internal jobs needs to be provisioned.
OpenTelemetry in Azure Logic Apps (Standard and Hybrid)
Why OpenTelemetry? As modern applications become more distributed and complex, robust observability is no longer optional—it is essential. Organizations need a consistent way to understand how workflows are performing, trace failures, and optimize end-to-end execution. OpenTelemetry provides a unified, vendor-agnostic framework for collecting telemetry data—logs, metrics, and traces—across different services and infrastructure layers. It simplifies monitoring and makes it easier to integrate with a variety of observability backends such as Azure Monitor, Grafana Tempo, Jaeger, and others. For Logic Apps—especially when deployed in hybrid or on-premises scenarios—OpenTelemetry is a powerful addition that elevates diagnostic capabilities beyond the default Application Insights telemetry. What is OpenTelemetry? OpenTelemetry (OTel) is an open-source observability framework under the Cloud Native Computing Foundation (CNCF) that provides a unified standard for generating, collecting, and exporting telemetry data such as logs, metrics, and traces. By abstracting away vendor-specific instrumentation and enabling interoperability across various tools and platforms, OpenTelemetry empowers developers and operators to gain deep visibility into distributed systems—regardless of the underlying infrastructure or language stack. In the context of Azure Logic Apps, OpenTelemetry support enables standardized, traceable telemetry that can integrate seamlessly with a wide range of observability solutions. This helps teams monitor, troubleshoot, and optimize workflows with more precision and flexibility. How to Configure from Visual Studio Code? To configure OpenTelemetry for a Logic App (Standard) project from Visual Studio Code: Locate the host.json file in the root of your Logic App project. Enable OpenTelemetry by adding "telemetryMode": "OpenTelemetry" at the root level of the file. { "version": "2.0", "extensionBundle": { "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows", "version": "[1.*, 2.0.0)" }, "telemetryMode": "OpenTelemetry" } Define the following application settings in local.settings.json or within your CI/CD deployment pipeline: OTEL_EXPORTER_OTLP_ENDPOINT: The OTLP exporter endpoint URL where the telemetry data should be sent. OTEL_EXPORTER_OTLP_HEADERS (optional): A list of headers to apply to all outgoing data. This is commonly used to pass authentication keys or tokens to your observability backend. If your endpoint requires additional OpenTelemetry-related settings, include those in the application settings as well. Refer to the official OTLP Exporter Configuration documentation for details. How to Configure OpenTelemetry from Azure Portal? – Standard Logic Apps To enable OpenTelemetry support for a Standard Logic App hosted using either a Workflow Standard Plan or App Service Environment v3, follow the steps below: 1. Update the host.json File In the Azure portal, navigate to your Standard Logic App resource. In the left-hand menu, under Development Tools, select Advanced Tools > Go. This opens the Kudu console. In Kudu, from the Debug Console menu, select CMD, and navigate to: site > wwwroot Locate and open the host.json file in a text editor. Add the following configuration at the root level of the file to enable OpenTelemetry, then save and close the editor. { "version": "2.0", "extensionBundle": { "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows", "version": "[1.*, 2.0.0)" }, "telemetryMode": "OpenTelemetry" } 2. Configure App Settings for Telemetry Export Still within your Logic App resource, go to Settings > Environment Variables and select App settings. Add the following key-value pairs: App Setting Description OTEL_EXPORTER_OTLP_ENDPOINT The OTLP (OpenTelemetry Protocol) endpoint URL where telemetry data will be exported. For example: https://otel.your-observability-platform.com OTEL_EXPORTER_OTLP_HEADERS (Optional) Any custom headers required by your telemetry backend, such as an Authorization token (e.g., Authorization=Bearer <key>). Select Apply to save the configuration. How to Configure OpenTelemetry from Azure Portal? – Hybrid Logic Apps To enable OpenTelemetry support for a Standard Logic App using the Hybrid hosting option, follow the steps below. This configuration enables telemetry collection and export from an on-premises deployment, using environment variables and local file system access. 1. Modify host.json on the SMB Share On your on-premises file share (SMB), navigate to the root directory of your Logic App project. Locate the host.json file. Add the following configuration to enable OpenTelemetry and save the file. { "version": "2.0", "extensionBundle": { "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows", "version": "[1.*, 2.0.0)" }, "telemetryMode": "OpenTelemetry" } 2. Configure Environment Variables in Azure Portal Go to the Azure Portal and navigate to your Standard Logic App (Hybrid) resource. From the left-hand menu, select Settings > Containers, then click on Edit and deploy. In the Edit a container pane, select Environment variables, and then click Add to define the following: Name Source Value Description OTEL_EXPORTER_OTLP_ENDPOINT Manual <OTLP-endpoint-URL> The OTLP exporter endpoint URL where telemetry should be sent. Example: https://otel.yourbackend.com OTEL_EXPORTER_OTLP_HEADERS (Optional) Manual <OTLP-headers> Custom headers (e.g., Authorization=Bearer <token>) required by your observability backend. Once you've added all necessary settings, click Save. Example of Endpoint Configuration & How to Check Logs To export telemetry data using OpenTelemetry, configure the following environment variables in your Logic App’s application settings or container environment: Name Source Value Description OTEL_EXPORTER_OTLP_ENDPOINT Manual Entry https://otel.kloudmate.com:4318 The OTLP receiver endpoint for your observability backend. OTEL_EXPORTER_OTLP_HEADERS Manual Entry Authorization=<your-api-key> Used to authenticate requests to the telemetry backend. OTEL_EXPORTER_OTLP_PROTOCOL Manual Entry http/protobuf Protocol used for exporting telemetry (KloudMate supports gRPC/HTTP). In this example, we are using KloudMate as the destination for telemetry data. Once correctly configured, your Logic App will begin exporting telemetry data to KloudMate as shown below: Limitations and Troubleshooting Steps Current Limitations Supported trigger types for OpenTelemetry in Logic Apps are: HTTP Service Bus Event Hub Exporting metrics is not currently supported. Troubleshooting Steps No traces received: Validate OTEL_EXPORTER_OTLP_ENDPOINT URL and port availability. Ensure outbound traffic to observability backend is permitted. Authentication issues: Review and correct header values in OTEL_EXPORTER_OTLP_HEADERS. References Set up and view enhanced telemetry for Standard workflows - Azure Logic Apps | Microsoft Learn💡Integration Environment Update – Unified experience to create and manage alerts
We’re excited to announce the next milestone in our journey to simplify monitoring across Azure Integration Services. As a follow-up to our earlier preview release on unified monitoring and dashboards, we’re now making it easier than ever to configure alerts for your integration applications. This update introduces a consistent, application-centric alerting experience across Logic Apps, Service Bus, and API Management (APIM)—all available directly within the Integration Environment. What’s New With this release, you can now: Create alerts effortlessly using a simplified, unified interface Monitor your application’s health based on fired alerts Troubleshoot quickly using integrated dashboards and alert insights Track messages across services from a single, consolidated view Together with the earlier update that introduced dashboards and runtime telemetry, this completes the core loop: observe, get notified, and act—all from one place. Powered by Azure Monitor The entire experience is built on Azure Monitor, giving you: A streamlined UI tailored for integration scenarios Consistency with Azure-wide alerting practices The ability to reuse existing action groups, alert rules, and automation Access to advanced configurations for users who need more control Whether you’re new to Azure Integration Services or already managing complex enterprise apps, this means less friction and more flexibility. Unified Monitoring Experience in Action Here’s how it all comes together in the Integration Environment: Set up alert-based workflows to notify, escalate, or auto-remediate incidents View application-level alerts in one place Use dashboards to correlate issues across Logic Apps, APIM, and Service Bus Rely on familiar Azure Monitor constructs, so there's no need to start from scratch This holistic view turns Integration Environment into the control plane for managing health and performance of your event-driven and API-based applications. With this update, you can detect issues faster, respond proactively to integration failures, reduce operational overhead, and scale your monitoring using familiar Azure tooling. Get Started This update is now available in your Integration Environment in the Azure Portal. To get Started, follow the steps to configure Integration Environment and Application. Then you are ready to configure alerts for the resources in your application. Here are some key steps In the chosen application, navigate to Alerts page. Via edit, open the page to alert rules. You can do this for the parent resource, or expand them to select a child resource like workflow in case of Logic Apps, or API in case of API Management, queues in case of Service Bus. To get started, we provide you an option to start with recommended rules or you can choose Add rule as well. The recommended rules is a really easy way to configure alerts in one go for a resource. We also recommend default thresholds which you can choose as is or update them. Remove a rule from the list if not needed. When you Save, we use Azure monitor APIs to create a rule per row. After Save, you will see the link to rule if you want to make any updates beyond what’s show in the UI. The recipients for the Alerts can be configured in action group tabs, based on the alert severity. Through Add rule, you can also choose to create alert rules for signals beyond the recommended ones. This is another example of recommended rules for Service Bus queues The alerts page also shows the alert activity to get a clear visual on the health of the application and different resources in it. You can see the count of alerts by severity allowing you to focus and triage the more critical issues. At this point, you know what resources in the application need further troubleshooting. This is where the monitoring dashboards in Integration Environment help you get a metrics and log based views into the details of the health of each resource to do the root cause analysis and mitigate the issues and alerts. We’d Love Your Feedback We understand how critical observability and monitoring are to running reliable integration solutions. Our goal is to provide the best end-to-end monitoring experience for Azure Integration Services—and to do that, we need your input. Whether you're just getting started or managing enterprise-grade integrations, your feedback helps us improve the tools and features that matter most. 👉 Have ideas, suggestions, or gaps you’d like us to address? Reply to this blog post or submit your feedback —we're listening. Let’s build the future of Integration monitoring, together.Integration Environment and Application Monitoring enhancements (early preview refresh)
After our Public Preview announcement earlier this earlier, we are excited to share early preview into significant enhancements to the Integration Environment and Application Monitoring experience. These updates are designed to make it easier for you to monitor, trace, and manage your Azure Integration Services (AIS) applications at scale. Note: This capability is in limited Preview and can be accessed via this link - https://aka.ms/aismon/refresh . It will be available publicly in January'25 What’s New Single pane view into the Health of All Applications in Integration Environment Gain a consolidated view of your application's health through Integration Environment: Leverage Azure Alerts to monitor individual resources and view all triggered alerts in one place. Understand the overall health of your application with a single-pane view, helping you stay proactive in identifying and resolving issues. End-to-End Message Tracing Across AIS Resources Using a single correlation ID, you can now trace messages seamlessly across all AIS resources in your application. This enables: A comprehensive end-to-end itinerary of your message flow across resources. Enhanced troubleshooting and diagnostics for complex workflows. Note: We are actively addressing an issue that prevents Service Bus traces from displaying in some scenarios. At-Scale Monitoring for Logic Apps We’ve expanded monitoring capabilities for Logic Apps to support at-scale operations: Health Dashboard: Monitor the health of one or multiple Logic Apps within your application (previously limited to a single Logic App). Bulk Resubmission: Easily select and resubmit multiple Logic App runs in bulk, streamlining operational efficiency. Improved Browsing Experience The Integration Environment now provides a more intuitive browsing experience. Key enhancements include: API Connections in the Integration Application View: Easily locate and monitor API connections within your Logic App and in your integration application. Resource Status Visibility: Quickly check the current status of resources. Plan Details: View detailed information about your plan, including Name and SKU. Customizable Filters: Tailor the columns to display the most relevant information for your monitoring needs. Getting Started This new capability will be available in Public Preview in early January. If you’d like early access, use this link (https://aka.ms/aismon/refresh). Pre-requisites To use this experience completely, you need to use Workspace-based Application Insights resource. All the AIS resources in your Integration application should push logs to the same workspace. When you use the Dashboards, you select the above chosen workspace to power all the visualizations. The dashboards are built using Azure Workbooks and will be customization so that you can extend them based on your business needs. Learn more Single pane view into health of all applications In Integration Environment, the Insights on the menu item will take you to the aggregated view into the health of all applications. This view is built upon Azure Alerts. You will be able to see the health based on the fired alerts. The screen shot below shows each application, and the number of alerts by the Severity level. When you select a row and choose an application, a detailed table view is displayed, providing a drill-down into the alerts triggered by the resources within that application. This centralized view consolidates alerts from various types of Azure Integration Services (AIS) resources, making it easier to monitor and manage them. The table includes details such as the associated resource, the triggered alerts, their severity levels, and a direct link to each alert for more in-depth information. This unified experience simplifies the process of tracking and addressing issues across your application resources. The Open Alert Details link opens gives further details into the specific entities which are in unhealthy state. You can also take an action on the alert here and update the user response and add comments. To summarize, within a single pane you can see the health of your application that includes different AIS resources, drill into the alerts that make up the health of the application. You can even go one step further and update user response. All of this through a in a single pane, across different types of resources, without the need for any context switching. Monitoring Dashboard Enhancements The workbook-based dashboards are accessible through the Insights menu within an application. Under Logic Apps, the Overview page provides an aggregated view of the health of all Logic Apps in the application. From this page, you can drill down to view the health of individual Logic Apps, explore detailed run statuses, and monitor workflows for each Logic App. The trend charts show the runs and their trends over the selected time period. As you are ready to troubleshoot further, the Runs tab gives more details The chart below illustrates the total runs and their pass/fail rates for Logic Apps and their associated workflows. This widget provides a clear visual representation of workflow statuses, helping you quickly identify areas that may require attention. Selecting a row allows you to drill down into the specific runs for the selected Logic App or workflow. The runs for a workflow include all relevant details, with additional insights available in the properties bag to aid further troubleshooting. The table is filterable by run status, making it easier to focus on specific scenarios. Most importantly, it supports resubmission of failed runs, either individually or in bulk. Additionally, each entry includes a unique correlation ID, which tracks the flow across all AIS resources. Selecting a row opens a detailed table showing the AIS processing hops for the message, providing a comprehensive view of its journey through the system. When you select on a row in the runs table, we use this correlation ID to stitch the timelines of the processing of this message across all AIS resources in this application. You can also provide multiple operation IDs to look into the journey of multiple messages The final table on this page provides action-level details for the selected run, offering a deeper drill-down into each individual action. In the event of failures, the properties section includes error details to assist with root cause analysis. What’s Next We are sharing this early preview to get your feedback – do not hesitate to reach out to us via this blogpost or directly. We plan to release this in January in Public Preview. We are also targeting to include some of these capabilities such as bulk resubmission and health based on alerts in Logic Apps Standard as well. Stay Tuned for more updates!A workbook for Logic App (standard) run history and resubmitting multiple runs.
After we published a sample workbook for organizing the Logic Apps events emitted to Application Insight in this blog post, we received feedback from multiple customers to have the ability to select and resubmit multiple runs from this workbook. We worked with the Azure Monitor team to have the ability to select multiple rows and perform an ARM action iteratively on the selected rows. The Azure Monitor team recently released this feature and with that we are publishing a new sample workbook that enables you to select multiple runs for resubmission.
