Go to All Forums

What's new in AWS infrastructure monitoring

Good day folks!

Today we are excited to unveil two new additions in AWS infrastructure monitoring. First, we are bringing in IAM role based support for securely connecting your AWS account with Site24x7; then we are bringing in a raft of new additions to the AWS add monitor flow for an improved CloudWatch integration. Now, let's take a look at them one by one.

 

IAM role based access.

Instead of creating IAM users, generating access keys, sharing them and rotating them in the future, you can now enable cross-account access and establish a trust relationship between your AWS account and Site24x7's AWS account. Thus you can securely delegate access to the various AWS resources in your account to an IAM entity in Site24x7's account and don't have to worry about your access keys getting compromised.

The key based approach of granting access to your AWS account is still available, so you can choose the method that suits your needs and proceed with that.

 

AWS service selection.

There might be situations where you don't want to monitor certain AWS services, or don't have a particular supported service running in your AWS account. To cater to such circumstances, we have brought in a new "services to be discovered" field. Now instead of making edits to the permissions present in the custom policy JSON or selecting and assigning multiple service-specific policy documents, you can just select the services which you want us to discover and monitor and be done with it.

Advance discovery options

 

Rediscovery interval.

To get a near real time view of your AWS environment, Site24x7 queries your AWS service every 5 minutes. So any change made in your AWS environment ? new instance provisioned, instance terminated, DB table name modified, new topic created, etc. can be detected and reproduced in the Site24x7 console. With the "rediscovery interval" field you can now configure the frequency at which these  checks are performed.

 

Site24x7 supports three modes of rediscovery polling intervals

  • Default polling: For EC2 instance 5 minutes, for other supported services 1 hr

  • Fewer polling : For EC2 instance 5 minutes, for other supported services 6 hrs

  • Never : No rediscovery will occur. To initiate rediscovery you'll have to use the poll now option.

Note: It's important to note that the default behavior of the ?poll now? option will be the same regardless of the type of rediscovery interval option selected. For example, imagine a scenario where you have configured the fewer polling option for your AWS account. Here rediscovery will happen every 5 minutes for EC2 instances and for other supported AWS resources it will occur every 6 hours. If you initiate the poll now option in-between, say in the 11th minute, rediscovery will start to occur for all supported AWS resources (including EC2 instances and other supported AWS resources). It is also important to note that the rediscovery polling interval, will not affect the performance metric polling interval applicable for each individual AWS service.

 

Exclude AWS resource from discovery using tags.

Imagine a scenario where you only require monitoring for EC2 instances, so you select the EC2 instance check box in the "services to be discovered field." This discovers all your EC2 instances running in different availability zones. However, what if you want to go one step further and discover only EC2 instances that are running in a specific region say US-east or you want to exclude EC2 instances launched in a particular VPC and what about the instances running in your development environment, do you really need to monitor them?

 

Now with our tag-based support, you can exclude the resources you don't want to monitor with ease. Currently, we support three types of tag-based exclusion.

Exclude AWS resource discovery using tags

 

System defined tags : filter resources attached to a particular region or launched in a specific VPC platform.

Example: $REGION US-East(Ohio)                 Example: $VPC   VPC-2sdfd237    

Currently only two system attributes (Region and VPC ID) are supported in tag based exclusion.

 

User defined tags : use the same tags that you have assigned for various resources in the AWS console.

For example, let's assume, you have configured a tag  with the key "stack" and value "test" for a set of EC2 instances running in your development environment, and you want to exclude these resources from getting discovered, so you can go ahead and mention the various user defined tags in the field provided. All the user-defined tag restrictions present in AWS is applicable here as well.

 

Site24x7 custom tag : configure the tag "monitor_site24x7" on your AWS resources and set its value as false.

The tag "monitor_site24x7" can be attached individually or in bulk to most of the AWS services(except SNS). The resources which have this key and value will be excluded from discovery.

 

(Important! note for existing users) Editing the advanced discovery options.

Editing the "Services to be discovered field".

When you navigate to the edit section of the AWS add monitor form, you'll see that the various AWS services for which you have provided ReadOnly access will be checked in the "Services to be discovered field."

Unchecking a selected AWS service will ensure that no further rediscovery will occur for the said service. For example, consider a scenario where you want Site24x7 to stop discovering and adding newly created SNS topics, instead of editing the permissions present in the custom policy JSON, you can navigate to the edit section of the AWS "add a monitor" form and uncheck SNS topic from the services to be discovered field.

 

Editing the rediscovery interval

The rediscovery polling interval will be set to default polling mode. (Note: the existing  rediscovery polling interval ? 5 minutes for all supported AWS services will not be applicable from now on)

You can edit the rediscovery polling interval at any point in time. Once done, the newly configured polling frequency will become applicable for successive polls.

 

Configuring new tags in the edit section.

The AWS resources that are currently being monitored can't be excluded by configuring new tags. For Site24x7 to filter resources, the tags must be set before you initiate Auto Discovery or the tagged resource must be a new instance which has not been discovered yet.

For example, consider a scenario where you want to exclude a group of 5 instances which were launched in a specific VPC. But these resources have already been discovered and are currently being monitored. Configuring a exclude tag now with the key $VPC and value "VPC ID" won't help you filter these resources. These resources can only be excluded by suspending the said monitors from the Site24x console.

 

Resources

  1. Create a cross-account IAM role 
  2. Advanced discovery options
  3. Filter AWS resources

 

Hope, we were able to provide you with a good enough overview of the new enhancements we are bringing into AWS monitoring. If you have any feedback or comments, please feel to post it below. If you have any queries or concerns, please get in touch with our technical support, we would love to help you. We are glad to bring in these new enhancements, hope you guys don't forget to give this a try. Cheers!

 

 

Like (4) Reply
Replies (3)

Great job guys! Keep the AWS goodies coming.

 

If you had already been using the custom tag "monitor_site24x7" to filter AWS resources then the edit section of the "Exclude resource from discovery" will contain the key "monitor_site24x7" and the value "false". if not, the section will be empty.

This does not seem to be the case for me.

Like (0) Reply

Hi Tom,

Thanks a lot for taking your time to check out our new feature. Coming to your query, for existing customers we will be handling the custom tag exclude feature internally, all the EC2 instances that were tagged before with the key - value pair (monitor_site24x7 and false) will still be excluded from discovery. If you want us to show the already configured tag in the edit section, we will surely take it up. 

Like (0) Reply

No, that's fine. I just wanted to provide the feedback that it does not show in my case :)

Like (0) Reply

Was this post helpful?