Utilisation efficace de l’identification CMDB

Rversion finale: Washingtondc

Mis à jour 1 févr. 2024

3 minutes de lecture

Utilisez efficacement l’identification CMDB.

Règles d'identification

Une règle d’identification indépendante identifie un CI en fonction des attributs du CI, indépendamment des autres CI.

Une règle d’identification dépendante identifie un CI par ses CI dépendants et les relations du CI identifié avec ces CI dépendants. L’identification avec une règle d’identification dépendante est basée sur les CI dépendants, ainsi que sur les relations et les qualificateurs entre le CI identifié et ses CI dépendants. L’identification prend alors plus de temps qu’avec une règle d’identification indépendante et est sujette à certaines erreurs d’identification. L’utilisation de règles dépendantes doit donc être minimisée.

La modélisation des CI détermine le type de règles d’identification requis pour une identification correcte des CI.

Créez des règles d’identification en utilisant l’ordre d’importance suivant :

Règles d’identification indépendantes — Il est toujours préférable de créer des règles d’identification indépendantes plutôt que des règles d’identification dépendantes. Lorsque vous modélisez un CI, définissez le CI avec un ensemble complet d’attributs qui se prêtent à une identification indépendante, éliminant ainsi la nécessité d’utiliser des CI supplémentaires pour l’identification.
Règles d’identification dépendantes : s’il est nécessaire de créer des règles d’identification dépendantes, définissez un niveau de dépendance unique. Deux est le nombre maximal de niveaux de dépendance pris en charge.
Évitez de créer des entrées d’identificateur de recherche. L’utilisation de l’entrée d’identificateur de recherche est fortement déconseillée, car elle peut réduire les performances. Si cela est inévitable, assurez-vous d’examiner d’abord les définitions de classe et envisagez les mises à jour qui permettent l’utilisation de règles d’identification indépendantes.
Limitez le nombre d’entrées d’identificateur dans une règle d’identification, idéalement à 1. Une deuxième entrée d’identificateur peut réduire davantage les performances, tout comme chaque entrée d’identificateur supplémentaire.
Créez des règles d’identification fortes dans lesquelles les entrées d’identificateur les plus fortes et les entrées connexes sont définies avec la priorité la plus élevée.
Assurez-vous que la règle d’identification se trouve au niveau de classe qu’elle doit être.

Payload

Créez la charge utile en utilisant l’ordre d’importance suivant :

Taille de la charge utile : limitez le nombre de CI par charge utile à 500.

Évitez les entrées en double dans la charge utile.

Exemple : si une règle d’identification a un attribut de critère pour le champ de nom , la charge utile suivante comporte des éléments en double, ce qui entraîne une défaillance :

var payload = {
    items: [{
        className:'cmdb_ci_linux_server',
        values: {
            name:'Win Server 200',
            ram:'2048'
        }},
{
        className:'cmdb_ci_linux_server',
        values: {
            name:'Win Server 200',
            ram:'4096'
        }}]
};

Ne transmettez pas de données système telles que les suivantes dans la charge utile.

var payload = {
    items: [{
        className:'cmdb_ci_linux_server',
        values: {
            name:'Win Server 200',
            sys_domain:'global',
            sys_domain_path:'xyz',
            sys_updated_on:'2017-06-15 16:25:11',
            sys_mod_count:23,
        }}]
};

Fournissez l’ensemble minimal nécessaire d’attributs de critères pour chaque élément de charge utile, conformément à ce qui est spécifié dans les règles d’identification correspondantes.

Lors de la mise en correspondance des CI, utilisez les sysIds des CI s’ils sont disponibles. S’il est fourni, IRE peut utiliser le sysId pour localiser directement un CI sans nécessiter d’attributs de critères de la règle d’identification. Dans ce cas, IRE n’utilise pas le sysId dans le processus de mise en correspondance.

Exemple : CI indépendant à mettre à jour — sysId disponible.

var payload = {
    items: [{
        className:'cmdb_ci_linux_server',
        values: {
            sys_id:'194876usytrr65378098',
            ram:'2048',
        }}]
};

Exemple : CI dépendant à insérer. Le CI Tomcat War dépend du CI Tomcat, et le CI Tomcat dépend du CI de serveur Linux. Les SysIds pour les CI Tomcat et Linux sont disponibles.

var payload = {
        items: [{
            className:'cmdb_ci_app_server_tomcat_war’, 
            values: {
                name:'war1',
                short_description:'my description'            }
        }, {
            className:'cmdb_ci_app_server_tomcat',
            values: {
                sys_id:'194876usytrr65378098'
            }
        }, {
            className:'cmdb_ci_linux_server',
            values: {
                sys_id:'09876tysueyt6345lakiu'
            }
        }],
        relations: [{
                    parent:1,
                    child:0,
                    type: 'Contains::Contained by’}, {
                        parent:1,
                        child:2,
                        type:'Runs on::Runs'}
                    ]
                };

Exemple : CI dépendant à mettre à jour — sysId disponible.

var payload = {
        items: [{
            className:'cmdb_ci_app_server_tomcat_war', 
            values: {
                sys_id:'039387euey637465sytet',
                short_description:'my description new'            }
        }]
                };

Lors de l’insertion de plusieurs CI, qui dépendent tous du même CI, vous devez sérialiser vos appels d’API. Dans le cas contraire, tenter de traiter simultanément de nombreux CI peut obstruer le système et détériorer considérablement les performances globales du système.