Odac (Operations Dashboard for Apache CloudStack)

What's Odac all about?

I've been thinking about the Apache CloudStack UI's experience for operators, and although it's great in small environments, I believe that there could be significant improvement in the way that operators review and manage larger clouds. The layout of the native CloudStack UI is more focused on a graphical experience that helps explain the internal structure to the viewer. With a larger environment, the operator is (most likely) less interested in visually seeing relationships between the various infrastructure bits. What they want, is a dashboard view into their capacity (all available aspects), with drilldowns. They also need a much cleaner way to review the event stream that's generated by the system. To those ends, I started working on a project to create a prototype that might be one way to meet these needs.

The landing page shows the known zones:

The zone dashboard:

The zone historical capacity charts:

The event viewing page:

This is a fairly incomplete project at the moment so YMMV quite a bit.

Technical Summary

The project is broken up into three parts:

• cs-operator-dash: contains the Rails UI
• cs_eventconsumer: a gem that can run a daemon process to pull CloudStack events out of a RabbitMQ broker and push them into MongoDB
• cs_capacityretriever: a gem that can run a daemon process to periodically pull various capacity information from a CloudStack management server via my cloudstack_ruby_client gem, again pushing that data into MongoDB

Obviously this requires a running CloudStack management server (configured with the RabbitMQ event handler). It also requires MongoDB to store the data from the 2 daemon processes.

The basic concept is that the cs-operator-dash Rails app is largely read-only, and works with data being populated into MongoDB via the two daemon processes. cs-operator-dash uses the Mongoid ORM to map the appropriate models to the collections being created by the back-end processes.

One of the main benefits to using a "collector > datastore < UI" architecture is that it allows the data to be stored as a historical record (that's how I get the trend lines).

License

Licensed via the ASLv2