2.18 Introduction to Azure Monitor

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

19 hours 58 minutes
Video Transcription
Welcome back. In this episode, we're going to dive into the last of our topics for module to with an introduction toe as your monitor.
Our objectives include understanding what as your monitor is taking a look at metrics and logs and finally alerts and action groups.
So first, what is as your monitor as your monitor maximizes your cloud resource is by collecting, analyzing and acting on performance and availability. Data from cloud and on purposes. Environments
as your monitor provides insights on how applications and infrastructure are performing in these environments, so you can proactively identify issues affecting them and other dependent. Resource is
as your monitor works across your azure and on purposes. Resource is by collecting data from a variety of places. This could be anything from application Monterey Data for code you've written or could be from the operating systems, where your applications air running where the operating system is located, and azure, another cloud or on premises data center.
You can also look at more abstract data coming from your azure subscriptions and azure active directory
as soon as you start creating resource is an azure like virtual machines or Web APS azure monitor begins collecting this data
as your monitor is broken into three different areas to provide full visibility into your solutions.
First, there is monitoring and visualizing Metrix. This is data to help you understand both the health operation and performance of your systems. Next is clearing and analyzing locks. These logs include diagnostic data and telemetry from other monitoring solutions
as your monitor provides the capabilities of searching through all these data points and analyzing it to find patterns and diagnosis issues.
Finally, they're setting up alerts in actions.
If a resource or event happens, you can set up alerts to notify you of these conditions and even take automated remediation actions. This provides quicker resolutions to issues as well as removes. The knee for admin is due mainly resolve errors, thereby reducing downtime.
Now I've made mention of metrics and logs while discussing as your monitors. So let's clarify what these terms mean.
First is metrics these air numerical values that define a resource er system at a point in time.
They're real time data points coming from your resource is some common metrics include network, third put and virtual machine seep you and ram usage. For example, If CPU percentage is running at 90% or higher. This would probably be a good indication that the system is being taxed or process has gone awry
and as your monitor will have a historical view of this metric where an alert would be generated
next door logs logs are events that are occurring on a system for windows at Mons. These would be things occurring in the event beer on a Windows server or in the CIS log for, Lennox admits, as your monitor also collects actions taken on a resource or inside a tenant. For instance, when a virtual machine has turned on or off,
logs can be queried using the Cousteau quarry language to retrieve data from Azure Monitor.
We'll see some more on the syntax of this language later on.
Here I have a screen shot of the metrics available on a virtual machine. These air pretty typical things you've probably already looked at. Inside of something like Task Manager, a resource monitor on a Windows server, for instance, we have the average CPU percentage and network total throughput.
Next, we have the ability to quarry our log data. The screen shot is an example of a query against our performance, bonded or data. This upper part is where we input are Que que ele query and the bottom is our results from the query.
This is generated from data gathered from the virtual machine, for example, showing the available megabytes available on V M. 01
Now having all this data is a great thing, but what can we do with it? Let's talk about our third pillar called Alerts and Actions. Alerts proactively notify you when conditions are met. Based on the monitoring data, they allow you to identify and re mediate issues hopefully before your users notice.
Previously, alerts and actions were a function of a separate product called Log Analytics and application insights,
but they can now be found built into azure monitor. We have several options for what we can configure alerts against, including metrics, log search queries and activity logs. Activity logs contain actions that are taken on resource is in your azure subscription or when I service the health event occurs like maintenance or incidents.
Here we have an example of how an alert is built. First, at the top of the diagram, we have to define the resource we want to alert on and the signal coming from the resource to check.
Next we define the criteria, which is a combination of the signal, plus some logic to alert on. For example, our signal might be CPU percentage and the criteria would be if it is greater than 80%. Next, we have an action group of sign. This action group defines what we're going to do when the CPU hits 80% or higher.
This could be something like Cindy, an email or a text message.
And finally we have the monitor condition, which is the alert state. This is where the alert is in the resolution process. It could be new as it was just detected acknowledged, meaning the alert has been reviewed and is actively being worked on or close, meaning the issue is now resolved.
In our alert anatomy, I mentioned action groups thes our collection of preferences for your notifications. These include who to notify or what action to take. One alert has been triggered. We have several options for alerts such as a voice call, sending an SMS or e mail, or even taken an automated action like triggering a run book. or I t s in action.
I t s m connectors can be created to connect to something like service now or system center service manager.
That does it for the slides. For right now. Let's follow this up with a post assessment question. What language is used to query log data?
The answer is the Cousteau quarry. Language or cake? Well, or maybe it's pronounced kee cool. Kind of like sequel. I'm not too sure
coming up. Next. We're gonna take everything we just learned about azure monitor and jump into our portal to check it out in our azure monitor demo. See you in the next episode.
Up Next