Briefly brainstorming, here is what I have come up with:
1. How would you like to have your monitor group rule be set? for eg: based on certain tags / security groups regions etc..
a. AWS Tags (specifically, Name or auto-scaling tags auto created with AWS CloudFormation)
- This is our primary use case. EC2 instances and other resources are usually named or tagged with something specific to a release. For instance, release 1 all instances would be named with or tagged with "PROD1". For release 2, all instances would be tagged or named with "PROD2" in them.
b. VPC ID
In some cases, we have different VPCs for different departmental groups. When discovering monitors, on AWS account may have two or more different VPCs created for differnt departments. Grouping by VPC would be great as well.
c. AWS Account
In other cases, we have completely separate AWS accounts for different departments. For instance, Marketing has their own AWS account for marketing resources. I would like to auto-discover those resources and assign them to the Marketing Monitoring Group. For a Dev Team, we have a separate AWS account specifically for their resources. It would be great to discover AWS resources in that AWS account and automatically group them into a group for Dev Team X.
2. What kind of other configurations w.r.t to aws you feel is lacking with us?
a. The only other thing I can think of off the top of my head is how to handle Docker monitors and Server Monitors when decommissioning an older configuration.
For instance, the DevOps Team deploys all new infrastructure each time there is a release.
Example: Release 1 is running on AWS EC2 instances, Docker Instances, Docker Containers, Application Elastic Load Balancers and all of those resources are in a monitoring group named PROD1 Release. After PROD2 has been fully deployed and the DevOps Team wants to decommission the PROD1 resources, we receive a _TON_ of alerts for Server Monitors going down and Docker Instances going down. These are going down on purpose though and we do not want the alerts. There have been some internal discussions about integrating internal infrastructure management applications with Site24x7 in order to turn off the Server/Docker instance monitors in Site24x7 before the AWS resources are terminated, but this is very far off time-wise. It would be great if there was a way for Site24x7 to see that an EC2 instance being terminated and that is the reason why Docker and Server Monitors are going down. I don't think Site24x7 can do that at all today.
Alternatively, if there is a way to automatically build dependencies among EC2 instance -> Server Agent -> Docker Agent when auto-discovering/auto-deploying monitors. Then, if the EC2 instance was terminated, perhaps we would not receive alerts for the Server Agents or Docker Agents.