Le mécanisme d'import permet d'importer un élément dont la définition est répartie entre plusieurs sources. Un hôte par exemple, peut être présent dans 2 sources (ou plus):
L'objet final sera donc un hôte ayant les propriétés de la première et de la deuxième source.
Apres La collecte des données c'est l'étape de vérification et fusion des éléments qui possèdent au moins une clé de synchronisation commune. Voir Comment ça fonctionne ?
Les clés de synchronisation utilisées dépendent du type de l'élément et de la source. Les pages des sources listes les clé utilisées par défaut.
Exemple
Par exemple, 2 hôtes avec la même adresse seront regroupés par le mécanisme d'import des sources en un seul hôte. Les 2 hôtes suivants présents dans deux sources distinctes :
define host {
host_name Hote 1
address localhost
propriété_commune valeur1
propriété1 valeur1
}
|
define host {
host_name Hote 2
address localhost
propriété_commune valeur2
propriété2 valeur2
} |
seront regroupés en un seul hôte contenant les 2 propriétés:
define host {
host_name Hote 1
address localhost
propriété_commune valeur1
propriété1 valeur1
propriété2 valeur2
} |
L'hôte résultant de la fusion des 2 hôtes ayant une clé de synchronisation commune contient les propriétés définies sur les hôtes ayant cette clé commune.
Lorsque la même propriété est définie par plusieurs hôtes, la valeur effective est celle dont la source a le plus petit numéro d'ordre. Dans l'exemple, on voit que la propriété commune a pour valeur la première valeur définie, soit "valeur1" et que le nom de l'hôte est "Hote 1".
Parmi les clés de synchronisation d'un objet, le SE_UUID est traité d'une manière différente.
Lorsqu'un élément possède un SE_UUID dans sa définition, il est considéré comme unique dans le mécanisme d'import des sources, et il ne sera pas fusionné avec un élément ayant un SE_UUID différent. Il peut par contre toujours être fusionné avec des éléments sans SE_UUID ou avec d'autres éléments ayant le même SE_UUID.
C'est utile dans le cas où on veut définir 2 hôtes avec la même adresse par exemple. Le SE_UUID permet de dire qu'il s'agit de 2 hôtes distincts et ils ne seront pas fusionnés.
define host {
# Shinken Enterprise. Lines added by import core. Do not remove it, it's used by Shinken Enterprise to update your objects if you re-import them.
_SE_UUID core-service-60f9373a47d511e8a3c1080027a3ae8c
_SE_UUID_HASH 61917cb49e8f3b524ee2e9482f59a2e9
# End of Shinken Enterprise part
host_name Host 1
address host_addr
}
define host {
# Shinken Enterprise. Lines added by import core. Do not remove it, it's used by Shinken Enterprise to update your objects if you re-import them.
_SE_UUID core-service-6454ba8a47d511e897f8080027a3ae8c
_SE_UUID_HASH bc7ea10870bdcb985dd1ba4dbcc62688
# End of Shinken Enterprise part
host_name Host 2
address host_addr
retry_interval 4
check_running_timeout 4
} |
Les 2 hôtes ne seront pas fusionnés à cause de la présence du SE_UUID.
Un SE_UUID à la forme suivante:
_UUID core-type_element-identifiant_unique |
Les clés de synchronisation sont accrochés aux éléments importés utilisées pour les identifier dans les sources.
Le fonctionnement et l'utilité des clés de synchronisation sont décrits de manière plus détaillée dans la page de documentation dédiée: Résolution des problèmes liés à l'import des sources.
Les propriétés suivantes sont ajoutées comme clés de synchronisation de l'objet Shinken:
hostname ( pour rappel, le hostname est égal à PREFIX-HOSTNAME ( du site distant ), au moment de l'import ).
Cette clé de synchronization est dynamique.
En effet, si le préfixe de renommage du Synchronizer distant change, les noms des hôtes seront renommés ainsi que leur sync-key pour être en adéquation.