All CMDBs Are Useless So We Built One

I love CMDBs, just not the ones you have. I also love configurations, but it seems my definition of configuration differs from most people’s.

A Configuration Management Database (CMDB) is an interesting thing, and common in all ITIL and Server/IT “management” systems. Most are auto-discovery, so you install an agent and they find out what the server is and what’s on it. Such as CPU, RAM, Disk, installed software, and other related things.

Note there is no ‘configuration’ in there, at least how I think about it, which means how you have configured your system, software, services, etc. It appears that CMDBs think of configuration as the hardware and what’s installed; that’s it. But as a hard-core operations guy, that stuff is mildly interesting, but I really care about the configuration of all the services, servers, and stuff that runs everything.

The CMDB world seems stuck in the old IT/PC management paradigm, where you needed to know your assets, where they are, what they are, and what’s on them. Very useful when you have a thousand PCs, printers, etc. strewn around a dozens offices while you try to enforce anti-virus, security, updates, etc.

But useless to a real Internet Operations team managing a fleet of servers in a cloud or data center, with things changing all the time, especially the versions and, shall we say it, the CONFIGURATIONS ! I’ve never seen a CMDB system that actually has configuration data in it. This is astonishing to me.

I really need to know how my Nginx is configured, what versions of SSL are enabled, and my MySQL options for data purging, and my HAProxy pool cookie settings, and my Kernel conntrack time wait timeouts are — these all deeply affect my large-scale systems and I need to know them, to report on them, to track their their history, and to alert on changes.

Yes, no one can do this for us. So we built it.

Our CMDB does all these things — it deeply discovers, collects, and stores all configurations of everything, parsing all the configs of the kernel and all recognized services, down the lowest Apache vhost directory level, 3rd tomcat instance app info, etc. It literally knows everything about everything, including any and all configurations. Of course it also gets trivial stuff like CPU, RAM, disks, installed software, running software, and more.

On top of that, we have auditing rules that can tell us when things deviate from best practices, and can find any differences between two or more servers (very common). It auto builds run books and meta data for each service; it can cross-check design specs, and alert when anything changes on a server. It even issues multi-lingual auti reports with recommendations.

We can version, alert on, and track any change of anything, both in our central OpsStack system AND on the command line on the server, where engineers often troubleshoot and work in ssh. And we are just getting started as this is an Ops Engineer’s dream.

The system runs every day to collect data, and on-demand, or even for new systems we are taking over to help us create migration and management plans. It’s easy when the system can find, see, and know everything.

This is a CMDB done right. It’s part of our OpsStack Operations Platform, which is also Operations done right.

Contact us if you want to know more about a real CMDB can help you manage your systems.