Azure Service Health helps you stay informed and take action when Azure service issues like outages and planned maintenance affect you. It provides you with a personalized dashboard that can help you understand issues that may be impacting resources in your Azure subscriptions.
For any event, you can get guidance and support, share details with your colleagues, and receive issue updates. Most importantly, you can configure customizable alerts to automatically notify you of service issues, planned maintenance, and health advisories.
We’ve posted a new video series to help you learn how to use Azure Service Health and ensure you stay on top of service issues. You’ll find out how to:
Set up your first Azure Service Health alert. Follow best practices in Azure Service Health alerting. Get alerted via mobile push notifications. Integrate Azure Service Health with your organization’s ticketing system, for example, ServiceNow. Understand the differences between Azure Service Health, Azure Resource Health, and the Azure Status page.
Watch the first video now:
Set up your Azure Service Health alerts today by visiting Azure Service Health in the Azure portal.
For more in-depth guidance, visit the Azure Service Health documentation. Let us know if you have a suggestion
The typical workflow we hear from customers – both ITOps and DevOps teams – is that alerts go to the appropriate team (on-call individual) based on some metadata such as subscription ID, resource groups, and more. The common alert schema makes this workflow more streamlined by providing a clear separation between the essential meta-data that is needed to route the alert, and the additional context that the responsible team (or individual) needs to debug and fix the issue.Azure Monitor alerts provides rich alerting capabilities on a variety of telemetry such as metrics, logs, and activity logs. Over the past year, we have unified the alerting experience by providing a common consumption experience including UX and API for alerts. However, the payload format for alerts remained different which puts the burden of building and maintaining multiple integrations, one for each alert type based on telemetry, on the user. Today, we are releasing a new common alert schema that provides a single extensible format for all alert types.
What’s the common alert schema?
With the common alert schema, all alert payloads generated by Azure Monitor will have a consistent structure. Any alert instance describes the resource that was affected and the cause
After you experience a Microsoft Azure service issue, you likely need to explain what happened to your customers, management, and other stakeholders. That’s why Azure Service Health provides official incident reports and root cause analyses (RCAs) from Microsoft.
Azure Service Health helps you stay informed and take action when Azure service issues like incidents and planned maintenance affect you by providing a personalized health dashboard, customizable alerts, and expert guidance. In this blog, we’ll cover how you can use Azure Service Health’s health history to review past health issues and get official root cause analyses (RCAs) to share with your internal and external stakeholders.
Review past health issues and get official root cause analyses (RCAs)
You can see 90 days of history about past incidents, maintenance, and health advisories in Azure Service Health’s “Health history” section. This is a tailored view of the Azure Activity Log provided by Azure Monitor.
If you experienced downtime, your internal or external stakeholders might expect an official report or RCA. As soon as they become available, RCAs can be found under any incident. Meanwhile, you can download and share Microsoft’s issue summary as a PDF.
Learn more about getting downloadable explanations in the
Azure Monitor for virtual machines (VMs) collects network connection data that you can use to analyze the dependencies and network traffic of your VMs. You can analyze the number of live and failed connections, bytes sent and received, and the connection dependencies of your VMs down to the process level. If malicious connections are detected it will include information about those IP addresses and threat level. The newly released VMBoundPort data set enables analysis of open ports and their connections for security analysis.
To begin analyzing this data, you will need to be on-boarded to Azure Monitor for VMs.
If you would like to start your analysis with a prebuilt, editable report you can try out some of the Workbooks we ship with Azure Monitor for VMs. Once on-boarded you navigate to Azure Monitor and select Virtual Machines (preview) from the insights menu section. From here, you can navigate to the Performance or Map tab to see a link for View Workbook that will open the Workbook gallery which includes the following Workbooks that analyze our network data:
Connections overview Failed connections TCP traffic Traffic comparison Active ports Open ports
These editable reports let you analyze your connection data
Azure Monitor Availability Testing allows you to monitor the availability and responsiveness of any HTTP or HTTPS endpoint that is accessible from the public internet. You don’t have to add anything to the web site you’re testing. It doesn’t even have to be your site, you could test a REST API service you depend on. This service sends web requests to your application at regular intervals from points around the world. It alerts you if your application doesn’t respond, or if it responds slowly.
At the end of this month we are deploying some major changes to this service, these changes will improve performance and reliability, as well as allow us to make more improvements to the service in the future. This post will highlight some of the changes, as well as describe some of the changes you should be aware of to ensure that your tests continue running without any interruption.
We are deploying a new version of the availability testing service. This new version should improve the reliability of the service, resulting in fewer false alarms. This change also increases the capacity for the creation of new availability tests, which is greatly needed as Application Insights
A few months ago, I shared best practices for alerting on metrics with Azure Database for PostgreSQL. Though I was able to cover how to monitor certain key metrics on Azure Database for PostgreSQL, I did not cover how to monitor and alert on the performance of queries that your application is heavily relying on. As a PostgreSQL database, from time to time you will need to investigate if there are any queries running indefinitely on a PostgreSQL database. These long running queries may interfere with the overall database performance and likely get stuck on some background process. This blog post covers how you can set up alerting on query performance related metrics using Azure Functions and Azure Key Vault.
What is Query Store?
Query Store was a feature in Azure Database for PostgreSQL announced in early Fall 2018 that seamlessly enables tracking query performance over time. This simplifies performance troubleshooting by helping you quickly find the longest running and most resource-intensive queries. Learn how you can use Query Store on a wide variety of scenarios by visiting our documentation, “Usage scenarios for Query Store.” Query Store, when enabled, automatically captures a history of query runtime and wait statistics. It