One of the most common ways to implement PowerShell error handling is to set the ErrorActionPreference variable (or ErrorAction parameter) to Stop, and capture these errors with a surrounding try/catch block.
This works perfectly fine in many situations. However one problematic use is when a cmdlet needs to write multiple unique errors to the error stream. One specific example is New-AzResourceGroupDeployment, which can write multiple validation or deployment errors if they are encountered.
If you use the standard try/catch approach here then the cmdlet stops after writing the first error (by design– because you set the action preference). This post provides some tips to handle this scenario to ensure you don’t miss the additional error stream records.
This is the third and final post in a series I’m writing on Azure’s Application Insights (AI) service. In the previous post we looked at how to create monitoring dashboards in Azure.
Here in this post we run through some examples for how to configure monitoring alerts with built-in Azure resource metrics and custom instrumented events and metrics.
This is the second post in a series I’m writing on Azure’s Application Insights (AI) service. In the previous post we looked at how to instrument our application code for monitoring.
Here in this post we will walk through how to create application monitoring dashboards directly in Azure using the Azure Dashboards feature and leveraging data from Application Insights and Azure resource metrics.
This is the first post in a new series I’m writing on Azure’s Application Insights (AI) service. The goal of the series is to walk through some of the basics for monitoring your Azure hosted services with Application Insights. We will cover topics like instrumentation, monitoring dashboards, and paging alerts.
In this post we have a look at code instrumentation: What is it? What are SLIs? How do we use the Application Insights client libraries? What are some instrumentation best practices?