CMDB : Are you the one at your home?
In all households, there is one person who has answers to all questions like — where is item A placed, item B is missing; has it gone for repair, has item C been disposed, why are item D and E are always together, when was item F purchased and the list goes on.. While growing up, in my home, this person was my mother and in my family now, to my surprise I am that person. It's my responsibility to keep things in their designated place, make sure all things are operational as expected, refill stuff when they run out, keep track of what comes into the house and what goes out, also ensure that new items find a place where they belong. Imagine keeping water bottles next to set of important documents, there will always be a fear of our life proofs getting washed away :D
If I were to translate this role of mine at home to a technical term, I would call myself CMDB — Configuration Management Database. As critical it is to a household, it is super critical for any Observability Implementation. It’s the first step in the Observability journey. You would have been told that metrics, logs and traces (MELTs from hereon, where E stands for Events) are the first step, believe me, they are not. They are the fundamental concepts, but not the first step. Even if you have the LMT in place, they are practically not super effective as the application server list is not known, even if that information is somehow maintained within the team, the relationship between the different applications that the particular application interacts with is not known. In Observability, to have end to end visibility, its is important to know all the upstream and downstream relationships so that the impact of a problem or a change being performed can be assessed correctly. CMDB maintains a repository of all software, hardware, network devices, servers, applications and databases assets (called Configuration Items), the relationships and dependencies between them, their attributes and information that describe their characteristics, specifications, version, owner, status, location, and other relevant details. Discovery of Configuration Items can be both automated and manual based on the IT landscape of your organization, the details of it are beyond the scope of this post. CMDB also plays an important role in managing Incidents and Changes as they need to be tagged to the correct application and quickly identifying the scope of impact. As an Observability Team, you are not responsible for owning or managing the CMDB, but your team will be the primary consumers. One of the most common providers of CMDB is ServiceNow and it provides connectors and APIs for most of the monitoring tools. (True for other providers as well). Even if you have a custom Observability toolset, you should be able to ingest data from most CMDB providers using APIs. A daily incremental load or even a full refresh into monitoring tools serve the purpose well. Then go about using this data along with MELTs to get a full view of the application health at a given time.
An important question to address is — What if the quality of CMDB in my organization is not optimal. Answer is — Do not deter. Still plan the Observability implementation based on whatever is available. Talk to the executives who can influence improving the CMDB and talk to them about the benefits. The quality of CMDB is a common problem across industry. The only way out is to keep working on maturing the CMDB and Observability implementation along with it. But if you plan to start without CMDB, you will soon have to re-do your efforts and re-plan the whole thing again.
If you are CMDB of your home, take pride in it and know that the household can potentially fall flat without you. Also, on a lighter note, I feel you!
