Following our previous blog post, we are still looking at tools for collecting metrics from an Openstack deployment in order to understand its resource utilization. Although Monasca has a comprehensive set of metrics and alarm definitions, the complex installation process combined with a lack of documentation makes it a frustrating experience to get it up and running. Further, although it is complex, with many moving parts, it was difficult to configure it to obtain the analysis we wanted from the raw data, viz how many of our servers are overloaded over different timescales in different respects (cpu, memory, disk io, network io). For these reasons we decided to try Prometheus with Grafana which turned out to be much easier to install and configure (taking less than an hour to set up!). This blog post covers the installation process and configuration of Prometheus and Grafana in a Docker container and how to install and configure Canonical’s Prometheus Openstack exporter to collect a small set of metrics related to an Openstack deployment.
Tag: monasca
In one of our projects we are making contributions to an Openstack project called Watcher, this project focuses on optimizing resource utilization of a cloud according to a given strategy. As part of this work it is important to understand the resource utilization of the cloud beforehand in order to make a meaningful contribution. This requires collection of metrics from the system and processing them to understand how the system is performing. The Ceilometer project was our default choice for collecting metrics in an Openstack deployment but as work has evolved we are also exploring alternatives – specifically Monasca. In this blog post I will cover my personal experience installing Monasca (which was more challenging than expected) and how we hacked the monasca/demo docker image to connect it to our Openstack deployment. Continue reading
In a previous series of blog posts (1, 2, 3), we have discussed how to install Monasca to monitor OpenStack, how to create alarms based on specific events happening in the monitored system, and how to setup notifications when any of these alarms are triggered.
Going further, in the context of the Cloud Orchestration initiative and the Hurtle framework, we go further by using Monasca to detect events in orchestrated applications and perform callbacks to the orchestrator so it can react to events. The motivation behind this is provide hurtle with processes able to perform continuous health management of any orchestrated application.
While initially designed to monitor the Cloud itself, it is easy to install the monasca agent on any platform, making it simple to monitor deployed VMs behaviour. Continue reading
Today marks the release of Watchtower v1.0.0. Watchtower is a Cloud Incident Management solution that we, the ICCLab, have been working on. It has been developed as part of the initiative with the same name primarily by Victor Munteanu. Continue reading
In this final part of the tutorial we will verify that all things are working properly.
Because of the large number of moving components the norm is that things will go wrong. Code changes daily both in Monasca and in Openstack and quite often things need further adjusting.
As a general rule, in case a component is misbehaving, change logging from INFO to DEBUG in /etc/monasca and restart the component. The look at the logs in /var/log/monasca and see what is wrong. For Thresh / Storm, logs can be found in /opt/storm/current/logs
In this part of the tutorial, we will install and configure all Monasca components.
In my previous blog post I covered my initial impressions on Monasca. In the following trilogy I will cover its installation, setup, and testing. The installation will be performed for the Java version of Monasca, as some components have both Java and Python code available. For those which only need a quick local setup best would be to use the vagrant setup found here.
The installation will be performed on Ubuntu 14.04 and will be split into 3 posts. The first one (this one) will cover dependency installation and configuration, the next one will cover Monasca’s installation and configuration, and the final one will cover the testing of the whole setup.
One of the focuses of the Cloud Incident Management research initiative are Monitoring as a Service solutions as they provide the building blocks for incident detection and resolution. As such, part of the work carried throughout the initiative was on identifying good, maintainable, monitoring solutions which can be easily adapted and integrated into a greater incident management architecture. The current blog post tries to cover Monasca showing the good, the bad and the ugly.
Monasca is a Monitoring as a Service solution which comes from HP and Rackspace: it focuses on providing a complete monitoring solution for Openstack. Monasca is an open source solution designed to be highly scalable, performant and fault-tolerant for a multi-tenant environment. It features a RESTful API though which one can interact with the system in order to query it or send metrics for processing.
The solution monitors both the Openstack Infrastructure as well as the VMs which run on it. Further, it can be easily integrated with Rackspace’s Stacktach which forwards all Openstack events coming from its different components to be processed by Monasca. Additionally, the primary authentication mechanism it uses as well as service catalog is Keystone.
Subscribe
Subscribe
Recent Comments