Doublons de CI dans la CMDB : comprendre l'IRE ServiceNow

Discovery tourne toutes les nuits. Les scans se terminent sans erreur bloquante. Et pourtant, la même machine apparaît trois fois dans la CMDB, sous trois noms légèrement différents, avec trois dates de dernière découverte.

Le réflexe habituel consiste à accuser Discovery, puis à lancer une campagne de fusion manuelle. Six semaines plus tard, les doublons sont revenus. Le problème n'est presque jamais dans la collecte. Il est dans ce qui se passe juste après, au moment où les données collectées frappent la CMDB.

Ce point de passage porte un nom : l'Identification and Reconciliation Engine, l'IRE. C'est lui, et lui seul, qui décide si un enregistrement entrant correspond à un CI existant ou justifie une création. Comprendre ses règles change la nature du travail : on arrête de nettoyer des symptômes, on ferme les portes par lesquelles les doublons entrent.

Ce que Discovery fait, et ce qu'il ne fait pas

Discovery collecte. Il interroge un hôte via SSH, WMI ou SNMP, applique ses probes et ses sensors, et produit un ensemble d'attributs. À aucun moment il ne compare ce résultat à ce qui existe déjà dans la CMDB.

Cette comparaison est le rôle de l'IRE. Discovery lui transmet une charge utile JSON, l'IRE l'évalue contre les règles d'identification de la classe visée, puis tranche : mise à jour d'un CI existant, création d'un nouveau CI, ou signalement d'une ambiguïté.

La conséquence est directe. Un doublon apparu après un scan n'est pas un défaut de collecte, c'est un verdict du moteur. L'IRE a regardé les données et a conclu, logiquement compte tenu de ce qu'il avait sous les yeux, qu'il ne connaissait pas cette machine.

Comment l'IRE décide qu'un CI existe déjà

Chaque classe de CI possède une règle d'identification. Elle est visible dans le CI Class Manager, onglet Identification Rule, ou en liste via Configuration puis Identification/Reconciliation puis CI Identifiers.

Une règle contient une ou plusieurs identifier entries. Chaque entrée porte :

une priorité numérique,
un ou plusieurs criterion attributes, c'est à dire les attributs qui servent de clé,
une indication précisant si l'entrée identifie le CI par lui même ou via une relation vers un autre CI.

L'IRE évalue ces entrées dans l'ordre croissant de priorité. Sur cmdb_ci_hardware, la première entrée combine par exemple numéro de série et type de numéro de série, la suivante utilise le numéro de série seul, et ainsi de suite. Dès qu'une entrée trouve une correspondance unique, le CI est mis à jour et les entrées restantes ne sont pas évaluées. Si aucune entrée ne produit de correspondance après évaluation complète, un nouveau CI est créé.

Un doublon, c'est un payload qui a traversé toutes les identifier entries de sa classe sans jamais correspondre à un enregistrement existant.

L'autre moitié du moteur : la réconciliation

L'identification décide de l'existence du CI. La réconciliation décide de son contenu. Les règles de réconciliation précisent quelle source de données a le droit d'écrire quel attribut, sur quelle table. Les règles de précédence de source départagent deux sources autorisées sur le même attribut.

Ces règles ne créent pas de doublons, mais elles produisent l'autre symptôme classique : un attribut qui change de valeur à chaque cycle parce que deux sources se le disputent. Si vous constatez ce comportement, cherchez du côté de la réconciliation, pas de l'identification.

Première cause : les écritures qui contournent l'IRE

Les règles d'identification ne s'appliquent qu'aux méthodes qui passent par le moteur. Passent par l'IRE : Discovery, Service Mapping, les Service Graph Connectors, les imports réalisés via IntegrationHub ETL, et les API d'identification de la plateforme.

Ne passent pas par l'IRE : un GlideRecord qui insère directement dans une table CMDB, une transform map classique qui cible cmdb_ci_server, un import manuel, un script de reprise écrit pour une migration.

// Écriture directe : aucune identifier entry n'est évaluée
var ci = new GlideRecord('cmdb_ci_server');
ci.initialize();
ci.name = 'srv-app-01';
ci.insert(); // le CI est créé même si srv-app-01 existe déjà

Le CI créé de cette manière arrive dans la table avec les seuls attributs que le script a renseignés, et sans enregistrement dans sys_object_source, la table qui relie un CI à ses sources de données et qui n'est alimentée que lorsque l'IRE s'exécute. Si les criterion attributes de la classe ne sont pas remplis, aucun scan ultérieur ne pourra rattacher la machine réelle à cet enregistrement. Discovery envoie son payload, l'IRE ne trouve rien, et crée son propre CI à côté.

C'est la cause la plus fréquente sur les plateformes reprises après une migration, et la plus simple à fermer.

Deuxième cause : l'attribut d'identification vide ou invalide

Si le payload ne porte aucun des criterion attributes nécessaires à au moins une identifier entry, l'IRE n'a rien à comparer. Il retourne l'erreur MISSING_MATCHING_ATTRIBUTES.

Le cas le plus courant concerne le numéro de série, et il mérite un détour, parce que la plateforme ne fait pas confiance à toutes les valeurs collectées. Les numéros de série découverts sont stockés dans la table cmdb_serial_number, avec un indicateur valid. Une valeur est marquée invalide lorsqu'elle est vide, lorsqu'elle est composée d'un seul caractère répété, ou lorsqu'elle figure dans la table des numéros de série invalides dscy_invalid_serial, qui liste les valeurs génériques posées par certains constructeurs et hyperviseurs.

Le scénario terrain est toujours le même. Une flotte de machines virtuelles remonte une valeur générique ou vide. L'entrée fondée sur le numéro de série ne peut pas travailler. L'IRE bascule sur l'entrée suivante, en général le nom. Le jour où le nom change, parce que la machine est renommée, change de domaine ou remonte en majuscules, un nouveau CI apparaît.

Attention au réflexe inverse : rendre le champ serial_number unique au niveau de la table est une mauvaise idée documentée par ServiceNow, parce que ce champ n'est unique ni par conception ni dans la réalité des parcs.

Troisième cause : les CI dépendants privés de leur parent

Certaines classes ne s'identifient pas seules. Une base de données, une instance applicative, un processus : leur identité n'a de sens que rattachée à un hôte. Leur règle d'identification contient des related entries qui exigent la présence de la relation vers le parent dans le payload.

Si le payload arrive sans ce parent, ou avec un parent que l'IRE n'arrive pas à identifier lui même, l'item échoue avec MISSING_DEPENDENCY. Selon le cas, le moteur conserve l'élément comme payload partiel dans la table cmdb_ire_partial_payloads, en attendant qu'une source complète l'information, puis fusionne les deux.

Le piège se situe en amont. Si l'hôte parent est déjà dupliqué, chaque doublon d'hôte reçoit sa propre copie des bases, des instances et des processus qu'il porte. Un seul serveur mal identifié produit ainsi une dizaine de CI en double. C'est pour cette raison qu'un chantier de déduplication commence toujours par les classes d'infrastructure, jamais par les couches applicatives.

Quatrième cause : plusieurs correspondances au lieu d'une

Le cas inverse existe aussi. Le payload correspond à plusieurs CI existants, par exemple parce que deux enregistrements portent le même numéro de série valide. L'IRE ne tranche pas seul : il regroupe les CI concernés dans une tâche de déduplication, sur la table reconcile_duplicate_task.

Ces tâches sont créées au fil de l'eau, au moment où la donnée traverse le moteur, et non par un job nocturne. Une file de tâches de déduplication qui s'allonge est donc un signal en temps réel, pas un rapport d'audit. Une plateforme dont personne ne regarde cette file accumule silencieusement des paires de CI que l'IRE a déjà détectées.

Pour la remédiation, la plateforme fournit un assistant de fusion tâche par tâche, et un tableau de bord de déduplication dans CMDB Workspace, avec des modèles qui appliquent les mêmes réglages à un lot de tâches d'une même classe.

Diagnostiquer avant de nettoyer

Fusionner des CI sans avoir identifié la cause garantit leur retour au cycle suivant. L'ordre de travail utile est le suivant.

Prendre deux CI en double et comparer leurs criterion attributes, pas leurs noms ni leurs adresses IP.
Ouvrir la liste liée sys_object_source sur chacun. Un CI sans source connue n'est pas passé par l'IRE : la cause est en amont, dans un script ou un import.
Vérifier cmdb_serial_number pour la machine concernée, et croiser avec dscy_invalid_serial.
Rejouer un payload représentatif dans Identification Simulation, qui construit la charge utile à partir des criterion attributes de la classe et montre la décision du moteur sans rien écrire.
Lire les erreurs retournées par le moteur. Les plus parlantes sont MISSING_MATCHING_ATTRIBUTES, REQUIRED_ATTRIBUTE_EMPTY, MISSING_DEPENDENCY et INSERT_NOT_ALLOWED_FOR_SOURCE.

{
  "items": [
    {
      "className": "cmdb_ci_linux_server",
      "values": {
        "name": "srv-app-01",
        "serial_number": "VMware-42 0c 5f",
        "ip_address": "10.20.30.40"
      }
    }
  ]
}

Un payload aussi simple suffit à savoir si la classe visée identifie sur le nom, sur le numéro de série, ou sur une combinaison des deux.

Ce qu'il faut mettre en place

Fermer les écritures directes est la première mesure, et la seule qui produise un effet durable. Toute alimentation de la CMDB doit passer par une méthode qui traverse le moteur, et les scripts de reprise historiques doivent être réécrits ou désactivés.

Ensuite, documenter les criterion attributes classe par classe avant d'ouvrir une nouvelle source de données. Une source qui ne peut pas fournir les attributs de clé de sa classe produira des doublons dès le premier import, quelle que soit la qualité de l'intégration.

Enfin, traiter les tâches de déduplication comme une file de travail avec un responsable, et non comme une purge annuelle. Et rester prudent avec les règles livrées en standard : ajouter un attribut à une identifier entry rend l'identification plus stricte, donc augmente le nombre de créations. Toute modification de règle se teste dans Identification Simulation avant d'atteindre la production.

La question à se poser n'est pas « pourquoi Discovery crée des doublons », mais « quel attribut manque au moteur pour reconnaître cette machine ». La réponse tient presque toujours en un nom de colonne.

Pourquoi vos CI se dupliquent malgré Discovery : comprendre l'IRE

Table des matières