Azure SQL Resources Reclassified from cmdb_ci_database to cmdb_ci_cmp_resource Causing Duplicate CI

chinmaykate · 3 weeks ago

We are investigating an issue in our CMDB related to Azure SQL resource onboarding through the Azure Service Graph Connector.

Current Behaviour

We have observed that Azure SQL resources (Microsoft.Sql/servers/databases) are initially created in the cmdb_ci_database.

However, after some time (typically during a subsequent connector run), the same CI is reclassified to cmdb_ci_cmp_resource.

When the next import occurs, the connector appears unable to identify the previously reclassified record and creates a new CI, resulting in duplicate Cloud Resource records.

Example Flow

Azure SQL Database imported.
CI created under cmdb_ci_database.
Later the CI class changes to cmdb_ci_cmp_resource.
Next Azure import runs.
Identification process does not match the existing reclassified CI.
New CI is created.
Duplicates continue to accumulate over time.

Investigation Performed

Verified duplicate records exist in cmdb_ci_cmp_resource.
Reviewed Identification Rules for affected classes.
Analysed Identification Simulation results.
Checked CI audit history.
Investigated Azure Service Graph Connector configuration.
Reviewed Robust Transform Engine related configurations.
Verified that records originally existed under database classes before being moved.

Questions

During CI class reclassification, are Identification Rules evaluated?
What mechanism performs the class switch from cmdb_ci_database to cmdb_ci_cmp_resource?
- IRE?
- Service Graph Connector Entity Operations?
- Robust Transform Engine?
- Class Switching Framework (glide.class.switch.enabled)?
Where can the reclassification logic be traced?
Has anyone seen Azure SQL resources automatically reclassified from database classes to cloud resource classes?
What is the best way to identify which process or transform performed the class change if audit history does not clearly show the source?

Additional Context

Source: Azure Service Graph Connector
Affected Resources: Microsoft.Sql/servers/databases
Duplicates are created daily after reclassification occurs.
Looking to understand the exact point where target class determination and class switching happen.

Any guidance on where to trace this behaviour or similar experiences would be greatly appreciated.

Thank you.

kmohammed · 2 weeks ago

Hi @chinmaykate,

Work through your questions in order - the pattern you describe (correct class first, generic class later, then duplicates) is the classic symptom of two connector data sources claiming the same Azure resource with different target classes.

1. Are Identification Rules evaluated during reclassification? Yes. IRE first identifies the existing CI using the identifiers in the incoming payload, and only then, if the payload class differs from the CI's current class, does it consider a class change (upgrade / downgrade / reclassification, as allowed for that class in CI Class Manager). That is also why the next run duplicates: once the CI sits in cmdb_ci_cmp_resource, the cmdb_ci_database identifier (which is evaluated in the context of the database class and its identifier entries) no longer matches it in the same way, so the following SQL import creates a new database CI instead of updating the reclassified one.

2. What performs the switch? Not glide.class.switch.enabled - that property is about the legacy class-switch behaviour, it is not what moves these CIs. In a Service Graph Connector the target class is determined before IRE, in the connector's Robust Transform / entity operations for each data source: a dedicated Azure SQL data source maps Microsoft.Sql/servers/databases to a database class, while a generic Azure resource inventory data source maps Azure resources generically to cmdb_ci_cmp_resource. If the same resource Id is processed by the generic data source after the SQL data source, its payload arrives at IRE with class cmdb_ci_cmp_resource, IRE identifies the existing CI, and reclassifies it. RTE itself does not switch the class of an existing CI - it decides the class in the payload; IRE does the reclassification.

3. Where to trace it - do this in timestamp order:

a. On one affected CI, open the audit history filtered to sys_class_name and note the exact time and the sys_updated_by / discovery source of the reclassification.

b. Match that time to the import history: check the connector's data source runs / import set runs that completed just before that timestamp. The run that matches is almost always the generic resource data source, not the SQL one. Also compare each CI's Most recent discovery / data source last updated values (cmdb_datasource_last_update) - it will name the data source that last touched, i.e. reclassified, the CI.

c. For a definitive payload, re-run Identification Simulation / review the IRE payload for that resource from each data source separately - the generic payload will show class cmdb_ci_cmp_resource for the same resource Id the SQL payload shows as a database class.

4. Fix: stop the two sources fighting over one resource type. In the Azure connector configuration, exclude Microsoft.Sql/servers/databases (and any other types owned by a dedicated data source) from the generic cmdb_ci_cmp_resource processing - check both the data source filter / resource-type selection and any custom RTE entity operation that maps Azure resources generically - and leave the dedicated SQL data source as the only owner of that resource type. Then clean up in this order: re-run the SQL data source so the surviving CIs are back in the database class, and use de-duplication tasks to retire/merge the duplicate cmp_resource records created in between - do not just delete them before stopping the generic source, or they will be recreated on the next run.

If audit alone does not name the process, the data-source-last-updated record plus the matching import set run timestamp in step 3b is the reliable pointer - it identifies the exact data source whose payload caused IRE to reclassify.