Hyperic HQ is one of the early open source providers of management and monitoring for cloud based applications in Amazon Web Services. Using Hyperic HQ we can monitor the Amazon EC2 CPU, Memory, Instance Disk, EBS disks etc. Hyperic HQ also provides rich visualization capabilities, trend analysis, capacity planning and advanced alerts capabilities to the infrastructure administrators. Many customers use Hyperic HQ in the AWS environment to monitor and manage their infrastructure, but Hyperic HQ has some disadvantages when our infrastructure becomes complex and elastic in AWS environment. Let us see some of the scenarios below:
Hyperic HQ problem when using Amazon Auto scaling service: Hyperic HQ Server collects the information from the Hyperic HQ agent installed in the Amazon EC2 instances. All the Amazon EC2 instances that need to be launched should be bundled with the Hyperic HQ agent in S3 or EBS backed AMIs for this communication to happen. When the EC2 instances are launched and terminated by the Amazon Auto Scaling, Hyperic HQ server can interpret this Amazon EC2 instance termination requests as an Amazon EC2 Server break down status and may start alerting the administrators. This will be an unnecessary noise to be handled by the Admin team.
Hyperic HQ clustering requires Multi Casting: Since monitoring service is an important part of the infrastructure administration, many times we need to setup our Hyperic HQ monitoring servers in cluster mode to avoid single point of failure. This clustering solution might require the usage of Multicasting networks/protocols inside Hyperic HQ, since this kind of setup is not possible in Amazon Web Services there are chances of single point of failure for the Hyperic HQ monitoring servers. This is not an ideal scenario for the admin team which depends upon Hyperic HQ to monitor and manage their entire infrastructure.
1 comment:
Interesting comments, and thank you for sharing your thoughts. This would be a great addition to the Hyperic forums, http://forums.hyperic.com.
Would you mind cross-posting there, so that other users can add their thoughts, and so that our product team can better learn how they might address this?
Post a Comment