Total Pageviews

Translate

June 22, 2018

AWS Logging and Analysis - Part 6.2 - Configuring and Understanding CloudWatch Alarms and visualization using Dashboard

by 4hathacker  |  in AWS Logging and Analysis at  8:13 PM

Hi folks!!!

Welcome to AWS Logging and Analysis quest...

This is in follow up with the previous article in which we have configured metric filters in CloudWatch. Here, we will configure alarms for all those metric filters.

CloudWatch alarms observes metric filters. Whenever a state change is found w.r.t. the filter, CloudWatch alarm got activated. Now in the activation state, we can configure it to do some stuff. Let us elaborate this a more.

A CloudWatch Alarm acts on the basis of a pre-decided threshold of data points collected in the form of state change. Suppose, if a filter is checking over the "RunInstances" event for a threshold of 5 data points. It means if 5 instances will be created, alarm will observe the change over the filter. And alarm will be activated.

Strictly speaking, there are three states defined for an Alarm,

1. INSUFFICIENT_DATA - While we have configured a fresh alarm, till now metric is not available. There is not enough data to decide for the state change of alarm.

2. ALARM - This is what I am referring to as activated. It means a pre-decided threshold has already been crossed with the collected data points in the given time. In this state, a pre-defined task can take place. This could be an EC2 related action, any Auto-scaling stuff or my favorite, sending a notification to SNS topic. 

3. OK - It refers the state in which the data points are yet to cross the threshold. Coming back to the above example, if 3 instances will be created, alarm will be observing the changes. Still it will wait for the threshold level of 5 running instances to be crossed in that given period of time.

I will recommend to go through the CloudWatch Alarm documentation once to get more understanding.

Let us start configuring our CloudWatch Alarm for the very first metric filter that we have created. We will resume from where we left in the previous article.

1. Refer the image below, beside the filter name, there is an option "Create Alarm" with golden font. Click on the same.

Note: After previous article, if you have closed all the tabs, follow the steps provided to configure an arbitrary filter, you will reach here finally and then delete that arbitrary filter.

2. The first step was "Select Metric" which we have just followed. Now, second step is "Define Alarm". Provide alarm name and description of alarm. The alarm will get activated if we provide valid data points in a given period. I have set the data point as greater than or equal to 1. And the period for evaluation is set as 1 minute. 

3. In the additional settings, we have to provide the information for the missing data. It depends on the metric filter evaluation. Logically, for the unauthorized filter, data cannot come every time so I will treat it as "missing" which is default. In some scenarios, like Lambda functions if there occur errors, and data is unavailable, it can be treated as good and "not breaching". While for continuous monitoring stuffs like CPUMonitoring, ELB related events, etc. missing data must be considered as "breaching".

4. In the Actions Tab, select for whenever the "STATE IS ALARM",  create a notification topic by giving a name like "cis-alarms" and then an email-id e.g. "Security Team<Security_Team@company.com>"

5. A pop up will appear to confirm for the mail id via a confirmation link sent over the mail. Once confirmed the alarm creation will be successful. Try to find your Alarm name below each of the metric filter tab.

As we have discussed before, the freshly configured alarms enter their "INSUFFICIENT_DATA" state. I have done some breaches on the filter events which can be found in the alarm details by checking the specific alarm.

For example,

1. Logging in via root account and "cis-aws-af3-rootaccountusage" got activated.

2. Logging with a user without mfa authentication and "cis-aws-af2-signinwithoutmfa" got activated.

After evaluation period, if no valid threshold crossings found, these will enter into "INSUFFICIENT_DATA" state.

I did a little more tweaking to activate some more alarms. Post that, I wanted to see the time based activation of alarms. For that, there are two ways,

1. CloudWatch Management Console: Here you can see every alarm status in separate graphs with blue or red dots over the threshold line.

2. Dashboard: It will be the best way to explore CloudWatch Alarms.

2.1 Go to Dashboard and Select "Create Dashboard".

2.2 In the pop up appeared, set the name as "CIS_DASH"

2.3 Post that, a new pop up will appear to select for the widget type. Select "Stacked Area" and click "Configure".
2.4 One more pop will appear. Give the title as "CIS_DASH_1"

2.5 Select "All" --> "Log Metrics" --> "Metrics with no dimensions". There all the activated alarms are visible to you. Select all, which will show in the current alarm status in stacked area.
2.6 Click on "Create Widget" in the bottom right. And it will settle in the Dashboard console.

2.7 Save the DashBoard for further use.

2.8 In the widget settled, at the top left there will be three vertical dots denoting the "widget options". Click it and select the "View Metrics" option.
2.9 A count vs. time graph will appear with all the stacked area covered by activated alarms.

We forgot about the SNS triggered for every ALARM (actcivated) state. This will show the same information as appeared in the console alarm state describing the alarm name, metric name, no. of datapoints received, etc.



0 comments:

Like Our Facebook Page

Nitin Sharma's DEV Profile
Proudly Designed by 4hathacker.