Blog Post

Azure Database Support Blog
4 MIN READ

AZURE SQL DB AND LOG ANALYTICS BETTER TOGETHER – PART #2 – ALERTS

FonsecaSergio's avatar
FonsecaSergio
Icon for Microsoft rankMicrosoft
Aug 08, 2019

As you could see on previous post (AZURE SQL DB AND LOG ANALYTICS BETTER TOGETHER – PART #1) using Azure SQL DB + Log Analytics is quite easy.

Let see how can we improve even further with ALERTS

 

Let’s imagine I want to receive everyday a list of all failed logins to be reviewed

 

I will reuse a query from last post to get failed logins, and I will just change parameter of time to filter failed logins on last 1 day

 

 

 

//Failed Logins
AzureDiagnostics
| where TimeGenerated >= ago(1d) //Events on last 1 days
| where action_name_s == "DATABASE AUTHENTICATION FAILED"
| extend additional_information_xml=parse_xml(additional_information_s)
| extend Error_Code=additional_information_xml.login_information.error_code
| extend Error_State=additional_information_xml.login_information.error_state
| project
    TimeGenerated, event_time_t,
    ResourceGroup, LogicalServerName_s, database_name_s,
    session_id_d, client_ip_s, application_name_s, session_server_principal_name_s,
    Error_Code, Error_State
| order by TimeGenerated desc

 

 

 

You can see that at this moment I don’t have any error (0 records).

 

To create an Alert based on a query, just click on New alert rule

1 – CONDITIONS

Resource is already filled with LogAnalytics

Now we need to define in which condition it will fire. Just click on CONDITION

You can see the search query was prepopulated, you just need to set threshold value, period and frequency. 

Time Period. Specifies the time range for the query. The query returns only records that were created within this range of the current time. Time period restricts the data fetched for log query to prevent abuse and circumvents any time command (like ago) used in log query. 
For example, If the time period is set to 60 minutes, and the query is run at 1:15 PM, only records created between 12:15 PM and 1:15 PM is returned to execute log query. Now if the log query uses time command like ago (7d), the log query would be run only for data between 12:15 PM and 1:15 PM – as if data exists for only the past 60 minutes. And not for seven days of data as specified in log query.


Frequency. Specifies how often the query should be run. Can be any value between 5 minutes and 24 hours. Should be equal to or less than the time period. If the value is greater than the time period, then you risk records being missed.
For example, consider a time period of 30 minutes and a frequency of 60 minutes. If the query is run at 1:00, it returns records between 12:30 and 1:00 PM. The next time the query would run is 2:00 when it would return records between 1:30 and 2:00. Any records created between 1:00 and 1:30 would never be evaluated.


Threshold. The results of the log search are evaluated to determine whether an alert should be created. The threshold is different for the different types of log search alert rules.

REF: https://docs.microsoft.com/en-us/azure/azure-monitor/platform/alerts-unified-log#log-search-alert-rule—definition-and-types

2 – ACTION GROUPS

Actions group define what are you going to do if the condition above is true. You can:

  • Send an email
  • Send an SMS
  • Push a notification to Azure App
  • Receive a call
  • Or you can do some automation, using a runbookon Automation accounts
  • Call Azure FunctionsLogic Apps
  • Webhook actions allow you to invoke an external process through a single HTTP POST request.
  • ITSM(IT Service Management) action will allow users to create a work item in the connected ITSM tool when an alert is fired.

 

In this sample I will send and email

You can also customize Subject Line and customize the JSON payload for webhook if that was the case


At end you can set the alert severity, and suppress alert config

  • Alert severity– For this test I’ve used Sev 2 Informational for my scenario
  • Suppress alert config– If you don’t want the alert to be a SPAM on your mailbox, change the period here

 

3 – ALERT EMAIL

For this test I just set parameters: Period 30 min, frequency 5 min and Suppress alerts 30 min.Find below the email that I have received

On this tests we can see 2 errors

  • 18456 / 8 = Login failed for user ‘%.*ls’.%.*ls / The password is incorrect.
  • 18456 / 5 = Login failed for user ‘%.*ls’.%.*ls / User ID is not valid.

REF: https://docs.microsoft.com/en-us/sql/relational-databases/errors-events/mssqlserver-18456-database-engine-error

 

4 – ALERTS IN PORTAL

If you go to the Portal Monitor > Alerts, you are going to see some alerts fired

You can see that the way I configured, I was alerted during 30 min, every 5 min = 6 alerts. However I just received 1 email because I had the option to suppress the email (Only will send me an alert email after 30 min of the first one)

No other failed connection error happened after that

You can review the alert details, and check the data

After reviewing this alerts you can cleanup them

 

 

Post originally from https://fonsecasergio.wordpress.com/2019/03/31/azure-sql-db-and-log-analytics-better-together-part-2-alerts/

Updated Aug 08, 2019
Version 3.0
No CommentsBe the first to comment