One of the fundamental characteristics of cloud computing is rapid elasticity: resources such as server instances can appear and disappear rapidly.
Good IT management practice requires that we administer and monitor our resources independent from the provider of these resources. So we have services and assets on the one hand and asset administration and monitoring on the other hand. Asset administration often revolves around some kind of ‘configuration management database CMDB‘. The challenge in the cloud is that this database changes much more rapidly.
CMDBs are notoriously incomplete. With cloud computing this is likely to be worse. How can new tool functionality help?
In this post I want to give some examples and outline some basic features for this. My favourite way of doing this is taking a small example and then expand it to illustrate the concepts.
Take a website. Even if it is procured as a service rather than ran on company owned servers, it should be in the CMDB. Basic monitoring for it would check if the URL still responds. If it fails to respond in time, an alert is sent.
One way of extending this is to figure out what the ‘adjacent’ assets are. Examples include DNS records and nameservers, because these are essential for the correct delivery of service, as perceived by the users. Other examples are any associated third party content and content distribution networks.
How would this work? The asset management tool and the monitoring service are likely to be independent tools, so there could be some interaction where, driven by asset management policies, monitoring service rules are added as appropriate. I.e when you list a webserver in the CMDB it will be automatically added to the monitoring service, and the adjacent DNS assets are automatically added as well. This speeds up troubleshooting, as the monitoring service gives inside into the component that is failing.
Another situation is with auto-scaling servers. When load increases, auto-scaling automatically adds server instances. It would be nice if auto-scaling would also register the instance in the CMDB as well as with the monitoring service. In fact, the instance could do this itself, by way of a ‘please monitor me’ message.
Now if you think this is simple, please figure out what to do when server instances are stopped. What do you want to happen with the CMDB entries and the monitoring data? You don’t want to delete it immediately.
Finally, turning things around, the CMDB should also contain the monitoring rules themselves. Remember they have configuration data, they cost money, so they are assets.