Zabbix is a rich monitoring system, which support SNMP, JMX, IPMI and uses its own agents for more functionality.
The great advantage of Zabbix is that it is self-sufficient : all the tools you need are in the packages and got connected to each others, whereas on Nagios you have to add tens of plugins.
Zabbix JMX monitoring is pretty simple : using a “JMX Gateway”, it will get connected to the server and collect information which will be transferred to the Zabbix Proxy / Server.
On the first place, we have to enable the JMX monitoring in Eucalyptus, so the JVM will allow connections to its monitoring systems. Edit /etc/eucalyptus/eucalyptus.conf
More details for more options regarding the JMX (ie : ssl support, passwords) here
Regarding the Zabbix ‘s configuration, something I am really fan of is Zabbix’s documentation. For example, click here…
Installing distributed systems can be a tedious and time consuming process. Luckily there are many solutions for distributed configuration management available to the open source community. Over the past few months, I have been working on the Eucalyptus cookbook which allows for standardized deployments of Eucalyptus using Chef. This functionality has already been implemented in MicroQA using individual calls to Knife (the Chef command line interface) for each machine in the deployment. Orchestration of the deployment is rather static and thus only 3 topologies have been implemented as part of the deployment tab.
Last month, Riot Games released Motherbrain, their orchestration framework that allows flexible, repeatable, and scalable deployment of multi-tiered applications. Their approach to the deployment roll out problem is simple and understandable. You configure manifests that define how your application components are split up then define the order in which they should be deployed.
In previous posts, I shared how to use Ubuntu Cloud Images and eustore with Eucalyptus and AWS. This blog entry will focus on how to use these assets to create EBS-backed EMIs in 12 steps. These steps can be used on AWS as well, but instead of creating an instance store-backed AMI first, Ubuntu has already provided AMIs that can be used as the building block instance on AWS. Let’s get started.
On Eucalyptus and AWS, it is required the user has the appropriate IAM policy in order to perform these steps. The policy should contain the following EC2 Actions at a minimum:
In addition, the user needs an access key ID and secret key. For more information, check out the following resources:
Thats it! You have successfully created an EBS-backed EMI/AMI. As mentioned earlier, these steps can be used on AWS just as well (just skip steps 1 & 2, and use one of the Ubuntu Cloud Images in the AWS region of your choice). Enjoy!
and play around with eucalyptus nc-hooks while we are at it ;)
Do you really really need and want to do custom modifications to your working environment … think twice!
Now that you have through and through thought out the maintenance burden and other facts lets do it :)
User needs to add 100(s) or 1000(s) of IP addresses to instance(s). Currently in Eucalyptus you can only add one elastic IP to an instance. in AWS VPC you can add up to 240 IP addresses to one big instance.
What is stylesheet ? XML stylesheet is used to generate the XML file that is used to start up the virtual machine. In Eucalyptus it is located at NodeController’s/etc/eucalyptus/libvirt.xsl. the input file is generated by NC.
You can manually test your modifications using xsltproc like this:
Copy the style sheet and use some existing instances data…
The Netflix Cloud Platform has shown how a large scale system can be deployed in a public cloud and maintain an extreme level of performance and reliability. As Adrian Cockcroft has said in the past, Netflix focused on having functional and scalable code rather than worrying immediately about how to make it portable. At Eucalyptus we have been working over the past year on making sure that as many of the NetflixOSS projects that interact directly with the cloud can be used on Eucalyptus. This level of portability means that anyone with even 1 single linux box can use their system as a test bed for deploying NetflixOSS more broadly on a public cloud. So far at Eucalyptus we have working versions of Asgard, Simian Army, Aminator, and Edda. These tools are cornerstones for app deployment and monitoring with the NetflixOSS stack. In this post I will…
Throughout my tenure as a Quality Engineer, I have had a love/hate relationship with logs. On one hand, they can be my proof that a problem is occurring and possibly the key to tracking down a fix. On the other hand, they can be an endless stream of seemingly unintelligible information. In debugging a distributed system, such as Eucalyptus, logging can be your only hope in tracing down issues with operations that require the coordination of many components.
Logs are generally presented to users by applications as flat text files that rotate their contents over time in order to bound the amount of space they will take up on the filesystem. Gathering information from these files often involves terminal windows, tail, less, and timestamp correlation. The process of manually aggregating, analyzing and correlating logs can be extremely taxing on the eyes and brain. Having a centralized logging mechanism is…
Elastic Load Balancing
To get started download the binary for your platform: