One neat thing you can do with Log Analytics is that you can
create alert definitions in Azure that fire when,
for example, rows are returned in your Kusto query.
Now alerting is something that goes across all of Azure Resource Manager,
but here I want to constrain our discussion to log search queries.
That's what I'll actually do my demo on.
However, this slide describes the object model for all Azure alerts,
so let's make sure we understand it.
In Azure,
we define an alert rule where we specify what
resources or resources we're examining, what signal logic we're concerned with.
This could be a metric value, for instance,
CPU utilization on a virtual machine, or it could be an activity log event,
fire the alert when a VM is in a stopped state or,
as I mentioned, you can write a KQL, a Kusto Query Language query,
to serve as the signal logic and criteria.
Once that criteria reaches fruition, as it were,
in other words, once the alert rule is triggered,
you then invoke what's called an action group,
and these include things like traditional notifications,
as well as actions.
I'll give you the options on that in the next slide, actually.
Now in order to keep your compliance and keep alert of these alerts,
you've got statuses.
The alert has 1, 2, 3 states New, Acknowledged, and Closed.
So, this allows you and your team to track these alerts historically,
you also can hinge other operations on alerts.
For example,
in Azure DevOps, you can configure a gate on your release
pipeline to check whether there are any open alerts on those
Azure resources that you're deploying to,
and if so, that would stop the release from happening in Azure Pipelines.
The action group's pretty powerful because it goes beyond
simple email and text‑based notifications.
You can configure push notifications to your IT staff and
development staff's mobile devices,
and you can also run code potentially to remediate the firing of that alert.
Options for that include, say,
a Python or a PowerShell script that you're hosting
as an Azure Automation runbook.
It could be a C# or JavaScript file that you're running in
Azure Functions, or it could be a stepwise workflow that
you've created in Logic Apps, you see?
There is an IT Service Management connector that you can
optionally onboard in your subscription,
that as long as you're ITSM platform supports the connector will allow the
Action group in Azure to create a new ticket automatically.
And lastly, there is a generic option to do an HTTP or HTTP webhook.
This allows you to call an API that's located within Azure or outside of Azure,
and it's your generic option in order to do some kind of
automation handling if any of the preceding options isn't what you need specifically.