Skip to main content

Only Remember One IP Among 50,000 CMDB Assets? Search Across Models First

· 9 min read

The Scene: Xiao Zhao Loses 20 Minutes Because of One IP​

At 1 a.m., Xiao Zhao is called up to handle a P2 alert.

The alert says, "The service on node 10.0.1.5 is timing out." He opens CMDB and prepares to find out which machine this IP belongs to, what business it runs, and who owns it.

There are tens of thousands of assets in CMDB. Following instinct, he selects the "Host" model, enters the IP in the search box, and gets no result.

Xiao Zhao repeatedly switches models in the CMDB search interface

He switches to the "Database" model, searches again, and still gets no result.

Then he switches to the "Middleware" model. This time there is a hit, but he still feels uneasy: is this IP also a host? Is it also the deployment target of a database?

He goes back to the "Host" model, switches to exact-match mode, searches again, and finally gets a hit.

The whole process takes 20 minutes. He switches across three models and changes the matching mode once.

In the end, he finds that the same IP appears under three models: one host asset, one database asset, and one middleware asset. The first "Host" search actually did have a hit, but it was missed because matching was case-sensitive.

Xiao Zhao's bottleneck is not that he does not know how to use CMDB. It is not that CMDB lacks records either.

The root cause is that most CMDB search designs put "classify by model" before "search by keyword."

This design assumes that you already know which model the IP belongs to.

In the early stage, when the asset scale is small and model categories are clear, this assumption mostly works. One IP usually belongs to one model, so choosing a model by instinct is enough.

But when the asset scale reaches tens of thousands and cross-service dependencies become complex, this assumption often breaks. The same IP may appear under multiple models: it can be a host in the host model, a deployment target for a database in the database model, and a node referenced by middleware configuration in the middleware model.

Making classification a prerequisite creates two concrete problems:

First: when nothing is found, frontline engineers cannot tell whether the asset truly does not exist or exists somewhere else. They repeatedly try multiple models, waste time, or simply give up on CMDB and return to asking people and searching chat history.

Second: same-name assets across models cannot be seen in one pass. Searching only one model at a time repeatedly misses part of the information, and incident reviews later get inconsistent explanations about why something was not found.

Three Consecutive Breakpoints​

If we split this governance chain apart, the search-entry order blocks teams at three layers.

Layer One: Cross-Model Hits Cannot Be Seen at Once​

The core of Xiao Zhao's problem is that classification should belong to search results, not the search prerequisite.

In a CMDB with 50,000 assets, "I only remember one IP" is a normal troubleshooting state. Requiring engineers to select a model first is asking them to answer a classification question, "Is this a host, database, or middleware asset?", before they can ask the retrieval question, "Does this IP exist at all?"

In reality, the classification question often has no single correct answer. One IP can be both a host and a database deployment target. This "both at once" situation is common in production. Selecting one model first directly loses half the picture.

The idea behind cross-model full-text search is to remove "choose model" from the search entrance and present it in the results instead.

Layer Two: Case and Exact Matching Should Help People Who Only Remember Rough Spelling​

In real asset data, casing is often inconsistent. The same machine may be recorded as WebServer, webserver, or WEBSERVER.

If search is case-sensitive by default, people who only remember the rough spelling will miss valid records. The system should default to case-insensitive search so fuzzy memory can still hit. It should also provide an exact-match switch for scenarios that truly require strict distinction.

The reason Xiao Zhao's first search under the "Host" model missed the result was that he remembered the IP in lowercase while the recorded asset field was stored in uppercase form. Case-insensitive matching by default should have been a simple configuration choice.

Layer Three: Permission Filtering and Search History Decide Whether Results Feel Usable​

When there are many hits, pagination determines response speed. But more important than speed is that search results must be strictly limited by the user's organization permissions and instance-level permissions.

Frontline engineers should only see hits they are allowed to access, not a long list of results that cannot be opened.

Search history matters too. The same IP, error code, or node name is often searched repeatedly by different people. Keeping recent search terms and allowing one-click reuse saves repeated typing. That history should stay local to the user and not be persisted to the backend, giving frontline engineers convenience without polluting the search index itself.

Technical Insight: Turn Classification from a Condition into Presentation​

Across the three layers above, the core of the CMDB search-entry problem is a design choice between judgment condition vs. information presentation.

Putting "classify by model" before search treats classification as a judgment condition: judge first, then retrieve. This design is convenient when frontline engineers are certain, but becomes a blocker when they are not.

Putting "classify by model" in the results treats classification as information presentation: retrieve first, then judge. This design is still convenient when engineers are certain, because they can directly open the matching model. It is also convenient when they are uncertain, because the distribution of results tells them where to go deeper.

The essence of search is finding, not classifying. The entrance for finding should be as simple as possible; classification should be presented by the data itself, not pushed onto frontline engineers first.

Back to Xiao Zhao's opening scene. If CMDB had already been designed around "search first, choose later," what would those 20 minutes have looked like?

He opens CMDB and enters the IP in the search box. No model selection is needed.

Select model first vs. search first and inspect distribution: a search-entry paradigm shift

The system directly returns that this IP has hits in three models: one host, one database, and one middleware asset.

He first opens the "Host" model tag, sees one matching record, and the matched field is highlighted. He opens the detail view and confirms that it is a production server.

Then he checks the "Database" model tag, sees one matching record, and confirms it is the deployment target of a MySQL instance.

Then he checks the "Middleware" model tag, sees one matching record, and confirms it is the connection address of a Kafka node.

The whole process takes one minute. There is no model switching, no matching-mode adjustment, and no repeated worry about whether something was missed.

What BK Lite Adds Is the "Search First, Choose Later" Governance Chain​

In BK Lite CMDB, search is responsible for turning "classify by model" from a search prerequisite into a search result.

CMDB search supports cross-model asset retrieval by keyword. It first returns the total hit count and hit counts by model, presented as model tags. After selecting a model tag, users can page through that model's matched results. It supports an exact-match switch, defaults to case-insensitive matching, and allows switching when needed. Results are shown as a list on the left with matched fields highlighted. The selected asset's details are shown on the right, with direct navigation to the asset detail page. Search results are filtered by user organization permissions and instance-level permissions, strictly returning only what the user can see. Search history is stored locally for the user and supports one-click reuse or clearing.

CMDB search capability architecture: from input to result presentation

This capability is not only about making search faster. It lets people who do not know which model contains the asset search first and choose later.

Existing CMDBs are not unusable. The search entrance simply needs to move from "choose model first" to "search first and inspect distribution." For a CMDB with tens of thousands of assets, that change lets someone who only remembers one IP get the full answer in the first query, instead of being asked to guess repeatedly.

Questions to Ask Before Starting​

If your CMDB still follows a "choose model first, then search" design, use these questions as a quick self-check:

  • Does the search entrance require model selection first? If yes, make cross-model full-text search the default entrance first
  • Is search case-insensitive by default? Real asset data often has inconsistent casing, and defaults need to help people who only remember rough spelling
  • Is pagination stable? If many hits make the page freeze, frontline engineers will stop using CMDB
  • Are results strictly filtered by user permissions? Frontline engineers should not see hits they cannot open
  • Is search history retained? The same person and different people often search the same keywords repeatedly

For a CMDB with tens of thousands of assets, these adjustments let someone who only remembers one IP get the complete answer in the first query, instead of being asked to guess repeatedly.

Once this governance chain is in place, CMDB is no longer only a ledger filled in after the fact. It becomes an entrance that frontline engineers are actually willing to use during troubleshooting.