Our Configuration Management Database (CMDB) is constantly out of date because of how quickly our cloud assets (AWS/Azure) spin up and down. Is it even possible to maintain a "Single Source of Truth" in a containerized environment? What tools or discovery processes are you using to ensure your Configuration Items (CIs) are accurate for incident impact analysis?
3 answers
Maintaining a manual CMDB in 2025 is a losing battle. You must transition to "Automated Discovery" and "Service Mapping." Tools like ServiceNow Discovery or AWS Config can automatically update your CMDB whenever a new resource is provisioned. The focus should shift from tracking every single virtual machine to tracking the "Logical Services" and their dependencies. Use "Tagging" as your primary source of metadata. If a resource isn't tagged correctly at creation, it shouldn't even be allowed to run. This ensures that your CMDB reflects the actual state of your infrastructure in near real-time, which is essential for effective change and incident management.
Are you finding that the sheer volume of data from automated discovery is creating "CMDB Noise" that makes it harder for your agents to find relevant info?
Focus on "Health Metrics" for your CMDB. If you can't trust the data, the team won't use it. Regularly audit your most critical business services first.
I agree with Brenda. A small, accurate CMDB is 100x more valuable than a massive, outdated one. Start with your top 10 business-critical services and expand from there.
Scott, that is a huge issue! We had to implement "Inclusion Rules" to prevent the CMDB from being flooded with ephemeral data like short-lived containers. We only track "Long-lived" assets or critical infrastructure components. By filtering the discovery feed, we kept the database manageable and useful for the Service Desk. You have to decide what actually constitutes a "Configuration Item" that provides value for decision-making versus just raw inventory data that belongs in a log file.