Once you have migrated your solutions to Azure, whether it’s through a lift and shift or a modernization process you need know how your solutions are performing. Traditionally, monitoring can be a complicated subject. Monitoring is usually implemented at the end of a project even though we all know it’s something you should think of beforehand.
Capacity and performance are difficult to compare when you move from a traditional on-premise environment to a public cloud infrastructure as overhead works different, resources are distributed more efficiently, and your solution might respond differently to your newly created infrastructure.
When it comes to monitoring, traditional solutions that monitor hardware and operating systems are becoming irrelevant. They are focused on monitoring operating systems, whereas on a Public Cloud such as Microsoft Azure you want to know what’s happening at a resource level. Additionally, with the trend of moving to a platform based scenario such as Platform as a Service with Azure App Services or Azure SQL and CosmosDB (just to name a few), the operating system becomes less relevant.
Instead of monitoring the traditional metrics such as CPU usage, Memory allocation and Disk capacity you now want to focus on transactions, user behavior and experience. This is something we’ve always wanted but to be honest, a lot of companies stop after the defaults for monitoring have been implemented.
Performance monitoring on Azure
Azure has multiple solutions that provide insights into the performance of your application and it all comes together in Azure Monitor. With Azure Monitor, Microsoft provides a full stack monitoring solution that will allow you to retrieve insights, detect, analyze and respond to events and application behavior.
A lot of the monitoring comes out of the box and requires nothing more than simply enabling monitoring for your solution. But if you really want to benefit from the monitoring capabilities you can also configure the Application Insights SDK for your solution and gather telemetry from inside of your application (example: https://docs.microsoft.com/en-us/azure/azure-monitor/learn/dotnetcore-quick-start).
Azure Monitor
Azure Monitor is gebaseerd op twee verschillende data types:
Metrics are pretty much what you’re used to in a traditional monitoring scenario. The values (numerical) are collected and based on a threshold an alarm will go off (for example: CPU usage is too high during a specific period). Then we have logs, and this is where the Azure Monitor suite adds some real value to your environment. Logs can be any event (test or numeric data) that occurs within your (or Azure’s) system and are stored in a Log Analytics environment.
Usually a solution will write to the Azure Log Analytics database, but if a direct connection is not supported you can always configure the solution to write your logging to an Azure storage as Azure Monitor can use that as a source.
Source: Microsoft, March 2019
Once configured, you have a world of options available to you. We can simply gain insights into the performance and behavior of your application, visualize that behavior (dashboards and PowerBI) or even automatically respond based on alerts (for example auto scaling, adjust settings or sending a message to your Ops team).
Querying Logs
In cases where the default logging is not enough for you, Azure provides the world of insights by giving you the ability to write custom queries. Custom queries are written using the Kusto (KQL) language. It’s similar to SQL and easy to read:
What makes this ability especially powerful is that Azure allows you to configure alerts based on your own custom queries. Detecting specific behavior? Configure an alert!
Visualizing the insights
Visualizing the insights can be done in many ways. You can create a custom dashboard within the Azure Portal, simply use Azure Monitor or even export the data to your own monitoring solution. Additionally you can configure alerting, which is as simple as clicking the “Create Alert” option that is available on pretty much every configuration blade within the Azure Portal that provides some kind of logging or analytics.
Source: Microsoft, January 2019
Alerts are then connected to Action Groups. That sounds pretty tactical and high tech, but no worries. These groups are a collection of notification preferences you decide upon. Once an alert is generated, it will trigger the Action Group it is configured for. The Action Group will initiate a preconfigured action, which can be as simple as sending an E-Mail, Text message or send an API call. But if you’re really into automating service management: Action Groups can also use the IT Service Management Connector that is available on Azure. For example: triggering an alert can results in the creation of a work item in your ITSM solution. How cool is that 😊
To summarize
Does this mean the end for your current monitoring solution? It depends. When moving to the cloud you probably don’t want to throw away all that you have build right now. Eventually you might want to move away from your traditional monitoring solution, but in the meanwhile Azure Monitor provides you with many ways to incorporate Azure monitoring solutions into your own solution and vice versa. There’s a big chance Azure can provide insights into your cloud solution in ways that your current monitor solution cannot. At the very least they will complement each other. Microsoft works hard on adding new logging and monitoring capabilities every day. If a feature is missing right now, there’s a big chance it will be available within the next few months. Logging is usually enabled by default, so there’s no reason not to use it.
This concludes our series of articles on your migration journey to Azure. Did we discuss everything? Probably not! Azure is big, it’s growing and by the time this article is published new features are already being added to make your migration to the cloud even easier. But whichever road you take, do address the topics we discussed to make sure you’re not missing the important stuff.