Après une introduction rapide à la supervision, cet article montre à partir d'exemples concrets comment la vision métier permet aux équipes d'exploitation d'être plus efficaces et mieux productives. Notamment en limitant/évitant les temps perdus à traiter de fausses alertes et, surtout, en priorisant la résolution des incidents en fonction de leur niveau d'impact sur les services métiers. Nous introduirons par la suite RealOpInsight [1], un outil open source générique qui permet d'insérer une vision métier dans les environnements de supervision. Compatible avec Nagios [2], Zabbix [3], Zenoss [4], Icinga [5], Centreon [6], op5 [7] et bien d'autres outils encore, il offre la possibilité de fédérer des informations provenant de plusieurs sources de supervision distribuées et hétérogènes.
(1) Prenons l'exemple d'une infrastructure composée de 1000 équipements (serveurs, commutateurs, routeurs, etc.) – ce qui reste encore faible, sachant que beaucoup d'infrastructures contemporaines sont composées de plusieurs milliers d'équipements. Si on a 8 sondes par équipement, on aura à gérer 1000x8 = 8000 indicateurs.
1. La supervision
Cette partie introduit quelques terminologies et notions de base qui faciliteront la compréhension de l'article.
1.1 Terminologies
Nous appellerons :
Service IT des fonctionnalités IT de base offertes par une application. Exemple : le service mysqld, qui fournit les fonctionnalités de création, d'accès et de manipulation de bases de données MySQL.
Service métierdésigne un service fournissant une valeur ajoutée aux utilisateurs ou aux autres applications. Exemple : un service d'hébergement de sites Internet.
Équipement ITdésigne un serveur ou un équipement réseau (par exemple un switch, un routeur).
Incident désigne une défaillance survenue sur une application ou sur un équipement IT ; cela peut entraîner une dégradation ou une indisponibilité de service.
Sonde est un programme permettant de vérifier l'état de fonctionnement d'un service IT. Dans Nagios par exemple, cela correspond à un check.
Sonde active est une sonde réalisée par le serveur de supervision.
Une Sonde passive est réalisée par un agent/entité externe au serveur de supervision ; l'état d'une sonde passive est envoyé au serveur de supervision via le réseau (par exemple trap SNMP).
L'impact d'un incident désigne le niveau de dégradation induit par l'incident sur les services.
Source de supervision : propre au vocabulaire RealOpInsight, désigne un serveur de supervision fournissant des API pour extraire les informations liées aux sondes.
API (Application Programming Interface) désigne une interface de programmation offerte par un programme ou un système informatique pour permettre à des entités externes de faire appel à ses fonctionnalités internes (par exemple API RPC).
RPC (Remote Procedure Call) désigne un mécanisme d'appel de procédure distante, qui permet à des programmes clients dans un système informatique de type client-serveur de faire appel à des fonctionnalités du serveur via des API spécifiques (par exemple REST).
1.2 Supervision open source
L'écosystème des outils de supervision open source est assez fourni [8], de sorte qu'il est difficile d'établir une liste exhaustive des outils disponibles. On peut cependant noter des outils majeurs comme Nagios et ses dérivés (Icinga, Centreon...), Zabbix et Zenoss, qui se démarquent de par leur forte popularité [9].
Simplement résumée sur la figure 1, la supervision avec ces outils fonctionne suivant le principe suivant : les équipements et les services IT sont régulièrement contrôlés via des sondes (actives ou passives). Les données collectées via ces sondes sont ensuite présentées dans une console, aussi appelée tableau de bord. Typiquement, chaque sonde est représentée par une entrée dans le tableau de bord. Ce qui permet de déterminer l'état de santé du service IT associé. Sur l'exemple de la figure qui est tiré de Nagios, le vert indique un état normal, le rouge une anomalie critique, tandis que le jaune indique une dégradation majeure mais non critique (Warning).
Fig. 1 : Illustration du principe de supervision avec Nagios, Zabbix et Zenoss
Cependant, cette présentation qui se focalise sur une vision de bas niveau des services ne permet pas de connaître l'état de santé réel des services métiers en cas d'incident. Ce qui n'est pas à l'avantage de l'équipe opérationnelle.
2. Enjeux de la supervision métier
De prime abord, on peut remarquer que deux incidents de même criticité sur les services IT n'ont pas forcement le même niveau d'impact sur les services tel que perçu au niveau métier. De plus, en fonction des services métiers que l'on souhaite superviser, certains incidents peuvent ne pas avoir d'impact sur les services concernés. Ces incidents peuvent, au regard de ces services, être considérés comme non pertinents.
Il convient donc de faire en sorte que les outils de supervision puissent permettre de prendre en compte ces différents types de situations.
2.1 Exemples illustratifs
La figure 2 illustre une infrastructure permettant de fournir des flux vidéo. L'infrastructure repose sur trois disques durs et des bases de données. Supposons qu'à un moment donné, l'un des trois disques soit défectueux, comme indiqué sur la figure (disque avec une croix rouge). Une question à poser serait de savoir à quel niveau la défaillance impacte le service de flux vidéo. Y a-t-il interruption de service ? Sinon, quel est le niveau d'impact ?
Fig. 2 : Schéma illustrant une défaillance dans une infrastructure fournissant un service de flux vidéo reposant sur trois disques durs
Au-delà d'une ligne dans la console de supervision indiquant la défaillance du disque, déterminer le niveau réel de dégradation induit sur le service de flux vidéo nécessite de prendre en compte des informations complémentaires concernant par exemple la configuration des disques. D'une part, supposons que les disques soient montés en RAID 0. Comme illustré sur la figure 3(a), la défaillance du disque entraînerait l'interruption de service, vu que les données sont reparties sur tous les disques. D'autre part, si les disques étaient montés en RAID 1, il n'y aurait pas d'interruption de service – étant donné que les données sont répliquées sur les différents disques. En revanche, comme illustré sur la figure 3(b), l'administrateur pourrait souhaiter que le service soit marqué comme dégradé pour attirer l'attention sur la défaillance du disque.
Fig. 3 : Du besoin de prise en compte de la vision métier dans un environnement de supervision. Dans le cas (a), la configuration en RAID 0 des disques ne supporte pas la résilience, alors que dans le cas (b), le RAID 1 apporte un support de résilience. Dans les deux cas, l'outil de supervision doit permettre aux administrateurs d'en tenir compte pour évaluer l'impact des incidents sur les services métiers.
Cet exemple n'est qu'un cas parmi tant d'autres. À partir du même exemple de plateforme de flux vidéo, on pourrait aussi faire des analyses similaires concernant les incidents qui pourraient survenir au niveau des bases de données.
2.2 Aller au-delà des incidents individuels, penser métier
Nous l'avons vu, se focaliser sur les incidents individuels ne permet pas d'avoir une vision pertinente de l'état de santé réel d'une infrastructure supervisée. Ce qui peut impacter l'efficacité et la productivité de l'équipe opérationnelle.
C'est pourquoi, il est important que les outils de supervision permettent d'aller au-delà des sévérités des incidents pris individuellement, en fournissant notamment des fonctionnalités qui permettent de tenir compte des spécificités de l'infrastructure sous-jacente. C'est là un des nouveaux enjeux de la supervision à l'ère des architectures orientées services et des nuages informatiques, où seule la valeur ajoutée apportée au niveau de l'utilisateur et des services métiers compte.
3. Vers une vision métier de la supervision
L'approche proposée ici est incrémentale. Se greffant naturellement et intuitivement sur votre socle de supervision existant, elle vous tournera résolument vers une nouvelle ère de la supervision avec un gain en productivité et en efficacité au-delà de vos attentes. Pour y arriver, nous vous suggérons une démarche qui peut se résumer en quatre points :
- Redéfinition de la sévérité d'un incident ;
- Identification de vos services métiers et de leurs dépendances ;
- Hiérarchisation des services métiers ;
- Construction de tableaux de bord adaptés à vos services métiers.
3.1 Impact d'un incident d'un point de vue service métier
Un incident ne sera dit critique que s'il entraîne l'indisponibilité d'un ou plusieurs service(s) métier(s).
Tout autre incident sera considéré comme non-critique, avec la possibilité de lui affecter une priorité plus ou moins importante selon le niveau de dégradation induit sur les services (par exemple incident mineur, incident majeur).
3.2 Vision hiérarchique de services
Il faut ensuite identifier les services métiers que l'on souhaite superviser. Pour chaque service, il faut identifier les autres services dont il dépend (dépendances avec des services métiers, dépendances avec des services IT de base).
Cette étape peut paraître anodine, cette notion de dépendance entre services constitue le socle même d'une vision métier de la supervision. Si on prend l'exemple présenté à la section 2.1, on peut par exemple identifier les relations de dépendances suivantes :
flux vidéo ← service web ← base de données ← réseau ← système d'exploitation ← matériel
Dans cet exemple, ← indique une relation de dépendance et « matériel » représente génériquement un ou plusieurs composant(s) matériel(s) selon le besoin de supervision. On peut par exemple vouloir des indicateurs sur le remplissage des disques, la charge mémoire, la charge CPU, etc.
3.3 Vue de service et cartographie
Une fois les relations entre les services identifiées, la prochaine étape consiste à établir une hiérarchie de services : nous appelons cela « vue de service ».
Au niveau de l'environnement d'exploitation, la vue de service doit avoir une cartographie. Comme illustré sur la figure 4, le but est de permettre aux administrateurs/opérateurs de mieux visualiser les relations entre les services. Et surtout, cela leur permettrait d'avoir en un coup d’œil un aperçu rapide et cohérent sur l'état de santé de la plateforme de service concernée.
Important : pour qu'une vue de service soit cohérente et pertinente, on doit associer une sonde à chaque service de la couche basse (feuilles de l'arborescence). C'est grâce à ces sondes que les statuts des services de la couche basse seront déterminés. À partir de là, les statuts des services métiers se situant aux niveaux intermédiaires et supérieurs de la hiérarchie de la vue de service peuvent être calculés.
Fig. 4 : Illustration d'une cartographie de services
3.4 Mécanisme flexible de calcul et de propagation de sévérités
L'organisation en hiérarchie de services permet en outre d'avoir un mécanisme puissant et flexible de calcul et de propagation de sévérités. Ce qui permet d'évaluer finement l'impact réel de chaque incident.
Cela repose, d'une part, sur des règles d’agrégation de sévérités qui permettent de déterminer au niveau de chaque service comment sa sévérité sera calculée en fonction des sévérités des services fils. D'autre part, des règles de propagation permettent de déterminer au niveau de chaque service comment sa sévérité sera propagée au service parent.
4. RealOpInsight
RealOpInsight est une solution open source qui permet d'apporter une vision métier dans les environnements de supervision. Conçu comme un outil complémentaire pour des outils de supervision existants, il est compatible avec nombre d'entre eux.
Sans être exhaustif, ses caractéristiques incluent :
- Interopérabilité et zéro surcoût d'intégration : entièrement bâtie sur des standards et technologies ouverts, la solution s'intègre – et peut s'intégrer – facilement avec une grande variété d'outils de supervision. Nagios, Zenoss, Zabbix, Shinken, Centreon, GroundWork, Icinga ou op5 ne sont que quelques exemples. Son architecture d'intégration basée sur des API RPC (voir section 4.1 pour plus de détails) lui permet de s'intégrer facilement dans tout type d'environnement de supervision (nouveau ou existant), sans nécessiter de changement majeur.
- GUI multiplateforme avec support de notification système : basé sur Qt, RealOpInsight exploite toute la puissante d'une application graphique et offre une console de supervision conviviale, performante et multiplateforme (compatible avec Linux, Windows et Mac OS X). De plus, la solution exploite la zone de notification du système d'exploitation pour informer les opérateurs en temps réel des changements ; même quand la fenêtre de l'application n'est pas active.
- Console des opérations synthétique et consistante : offrant un tableau de bord construit dynamiquement à partir d'un fichier de vue de service, la console des opérations (présentée à la section 4.5) offre des composants graphiques avancés incluant un explorateur d'arborescence (TreeView), une cartographie de services et une console de messages, le tout dans un même tableau de bord. Grâce à la puissance de gestion des événements de la souris tirée de Qt, la console offre en outre des fonctionnalités d'exploitation utiles, comme des infobulles pour avoir des détails sur l'état des services à la volée, le zoom rapide sur la cartographie, la gestion de focus (mise en évidence de services), le filtrage de messages à la volée, etc.
- Supervision unifié : à partir de la version 2.4, RealOpInsight permet d'extraire et de fédérer au sein d'un même tableau de bord des informations provenant de plusieurs sources de supervision distribuées et hétérogènes. Grâce à son moteur de collecte de données sophistiqué et ultra performant, chaque tableau de bord peut supporter jusqu'à dix sources de supervision simultanément sans induire de latence significative au niveau utilisateur.
4.1 Architecture
RealOpInsight est conçu pour être générique et fortement interopérable. Comme illustré sur la figure 5, l'intégration avec les sources de supervision repose essentiellement sur des API RPC, ce qui le rend peu sujet aux spécificités des différents types d'outils de supervision sous-jacents. Par exemple, on n'a pas à se soucier de comment Zabbix ou Nagios stockent les données en interne.
Fig. 5 : Architecture d'intégration de RealOpInsight avec les outils de supervision
L'outil suppose actuellement trois familles de solutions de supervision : Zabbix, Zenoss et toutes les solutions basées ou inspirées de Nagios (Nagios lui-même, Shinken, op5, Icinga, GroundWork, Centreon...).
Avec Zabbix l'intégration repose sur ses API JSON-RPC [10]. L'intégration avec Zenoss repose sur ses API natives de type JSON API [11], tandis que pour Nagios et ses dérivés, qui n'offrent pas d'API natives, RealOpInsight offre deux modes d'intégration : la première consiste à déployer un démon spécifique (ngrt4nd [12]) sur le serveur de supervision et à passer par ce démon pour extraire les données et la seconde alternative, recommandée pour des raisons de performances, consiste à utiliser un module Livestatus accessible via le réseau. Si vous utilisez MK Livestatus, vous pouvez l'activer via une socket xinetd [13]. Pour les utilisateurs de Shinken, le module Livestatus peut être nativement activé sur réseau [14].
L'intégration de RealOpInsight dans votre environnement de supervision peut se résumer en quatre étapes :
- l'installation ;
- la création et l'édition de la vue de service ;
- la configuration de l'accès aux sources de supervision ;
- l'utilisation de la console des opérations.
4.2 Installation
Selon votre système d'exploitation, vous pouvez installer le logiciel soit en utilisant le script d'installation (compilation de sources), soit en utilisant un installateur de binaires (openSUSE, Fedora, Ubuntu et Windows). Quelle que soit l'approche adoptée, la procédure d'installation est simple. La taille de cet article ne permettant pas de présenter les différents cas, nous vous recommandons de suivre les procédures décrites dans la documentation officielle : http://realopinsight.com/en/index.php?page=documentation.
RealOpInsight est composé de trois utilitaires que vous devez avoir après l'installation :
- le Gestionnaire de configuration, qui est accessible via la commande ngrt4n-manager(ou via le menu dans Windows) ;
- l’Éditeur de vue de service, qui est accessible via la commande ngrt4n-editor, via le menu dans Windows, ou via le menu de la console des opérations ;
- la Console des opérations, qui est accessible via la commande ngrt4n-oc ou via le menu dans Windows.
4.3 Configuration
Toutes les configurations sont réalisées via le Gestionnaire de configuration (cf. Section 4.2), dont une capture d'écran est présentée sur la figure 6.
Fig. 6 : Capture d'écran du gestionnaire de configuration
La configuration consiste essentiellement à définir les paramètres d'accès aux sources de supervision. Pour chaque source, on doit indiquer son type (Nagios, Zabbix, Zenoss) et ensuite, préciser les paramètres d'accès à l'API sous-jacente. Selon le type de source, certains paramètres du formulaire peuvent ne pas être nécessaires :
- La propriété « Adresse web du moniteur » définit l'URL d'accès au serveur de supervision. Ce paramètre est requis pour des sources de type Zenoss ou Zabbix, mais optionnel pour des sources de type Nagios. L'URL indiquée est en outre chargée dans le navigateur embarqué dans la console des opérations (cf. Section 4.5) pour donner un accès rapide à l'interface web par défaut de l'outil de supervision.
- La propriété « Chaîne d'authentification »définit un jeton pour s'authentifier au niveau du point d'accès à l'API. Pour des sources de type Zabbix et Zenoss, la valeur doit correspondre à un compte d'utilisateur valide sous la forme login:mot_de_passe (voir l'exemple de la figure). Pour des sources de type Nagios, ce paramètre n'est nécessaire que si vous utilisez le service ngrt4nd, il doit alors contenir le jeton d’authentification défini par le service [12].
- La propriété « Adresse du serveur », nécessaire et requise pour des sources de type Nagios, doit pointer vers l'adresse (IP ou nom DNS) du serveur de supervision.
- La propriété « Port » utilisée conjointement avec la propriété « Adresse du serveur » définit le port sur lequel le service ngrt4nd ou la socket Livestatus écoute sur le serveur indiqué.
- La propriété « Intervalle de mise à jour », requise et valable pour toutes les sources, définit la durée entre deux mises à jour de la console des opérations (en notant qu'à chaque instant, l'opérateur a la possibilité d'actualiser la console via le menu ou via le bouton d'accès rapide dans la barre d'outils).
4.4 Édition d'une vue de service
L’éditeur de RealOpInsight (cf. Section 4.2) permet de simplifier la création et la manipulation de la hiérarchie d'une vue de service. Une capture d'écran est présentée sur la figure 7. En dessous de la zone des menus (barre de menus et barre d'outils), la zone d'édition est composée de deux parties :
- À gauche, un explorateur d'arborescence permet de manipuler la hiérarchie en toute simplicité : ajout/suppression de services à la volée (menus contextuels avec options de copier/coller), réorganisation rapide de l'arborescence via des glisser-déposer, sélection de service à la volée, etc.
- À droite, l'éditeur comprend des champs permettant d'éditer les propriétés des services. Lorsqu'un service est sélectionné dans l'arborescence, ses propriétés sont automatiquement chargées dans la partie d'édition., permettant ainsi à l'utilisateur de les modifier à la volée.
Les propriétés d'un service comprennent entre autres :
- un nom qui sert d'étiquette pour le service ;
- le type de service : service métier, ou service de couche basse (qui doit être associé à une sonde, voir détails ci-dessous) ;
- une règle de calcul de sévérité (par exemple moyenne, sévérité la plus élevée) ;
- une règle de propagation de sévérité (par exemple décrémentation, incrémentation, idem) ;
- un message d'alerte personnalisé (optionnel) à afficher dans la console de messages lorsque le service est dans un état d'anomalie : par défaut, le message renvoyé par la sonde est utilisé ;
- un message de notification personnalisé (optionnel) à afficher dans la console de messages lorsque le service passe d'un état d'anomalie à un état normal : par défaut, le message renvoyé par la sonde est utilisé ;
- la sonde associée (pour un service couche basse, propriété « Source de données ») : comme noté précédemment, cette propriété est essentielle pour avoir une vue de service cohérente et consistante. La suite de cette section décrit comment définir cette propriété en fonction du type de l'outil de supervision.
Fig. 7 : Capture d'écran de l'éditeur de vue de service
4.4.1 Service couche basse basé sur une sonde Nagios ou dérivé
Pour un service de couche basse reposant sur une sonde Nagios, la sonde est référencée sous la forme [SourceId:]host_description[/service_description] :
- SourceId (optionnel) indique la source concernée ; ce champ peut avoir l'une des valeurs suivantes : source0 (valeur par défaut), source1, source3, source4, source4, source5, source6, source7, source8ou source9 ;
- host_descriptiondésigne l'identifiant d'un équipement (par exemple serveur, commutateur, routeur...) tel que défini dans les configurations de Nagios ;
- service_description (optionnel), indique la description du service tel que défini dans Nagios. Si ce champ est omis, la sonde ping sera considérée.
Par exemple, Source0:mysql-server01/Root Partition désigne le check Nagios chargé de contrôler le remplissage de la partition racine sur le serveur mysql-server01 supervisé par l'instance Nagios définie par Source0.
4.4.2 Service couche basse basé sur une sonde Zabbix
Pour un service de couche basse reposant sur une sonde Zabbix, la sonde est référencée sous la forme [SourceId:]host[/trigger] :
- SourceId (optionnel) indique la source concernée ; ce champ peut avoir l'une des valeurs citées précédemment ;
- Host indique l'identifiant d'un équipement tel qu'indiqué dans Zabbix ;
- Trigger indique le nom d'un déclencheur associé à l'équipement host dans Zabbix ; si ce champ est omis, le déclencheur contrôlant la disponibilité de l'équipement (ping) sera considéré ;
Par exemple, Source1:MySQL Server/Lack of available memory on server {HOSTNAME} fait référence au déclencheur qui contrôle l'occupation mémoire sur le serveur MySQL Server supervisé par l'instance Zabbix définie par Source1.
4.4.3 Service couche basse basé sur une sonde Zenoss
Pour un service de couche basse reposant sur une sonde Zenoss, la sonde est référencée sous la forme [SourceId:]device[/component] :
- SourceId(optionnel) indique la source concernée ; ce champ peut avoir l'une des valeurs citées précédemment ;
- Host indique l'identifiant d'un équipement tel qu'indiqué dans Zenoss ;
- component indique le nom d'une sonde associée à l'équipement indiqué par host dans l'instance de Zenoss pointée par SourceId ; si ce champ est omis, la sonde contrôlant la disponibilité de l'équipement (ping) sera considérée ;
Par exemple,Source2:localhost/http fait référence à la sonde qui supervise l'état du service http sur le serveur Zenoss (localhost) défini par Source2.
4.5 Console des opérations
Comme mentionné à la section 4.2, la console des opérations peut se lancer via un terminal (commande ngrt4n-oc), ou via le menu dans Windows. Dans les deux cas, vous devez sélectionner une vue de service à charger.
Son interface, dont une capture est présentée sur la figure 8, se compose des parties suivantes :
- Un explorateur d'arborescence (dans la partie gauche) permet de naviguer dans la hiérarchie de la vue de service de manière simple et intuitive. À l'aide de la souris, on a accès à des infobulles qui donnent des informations détaillées sur chaque service, on peut filtrer les messages liés aux différents services à la volée, centrer la cartographie sur un service sélectionné à la volée, etc.
- Une cartographie de services (premier onglet de la partie centrale supérieure) permet d'avoir une vision instantanée sur l'état des services. À l'aide de menus contextuels, des boutons ou de la molette de la souris, on peut (dé)zoomer sur la cartographie, filtrer les messages liés aux services à la volée, avoir des infobulles qui donnent des informations détaillées sur chaque service, centrer la cartographie sur un service sélectionné à la volée, etc.
- Un navigateur embarqué (second onglet de la partie centrale supérieure) permet d'avoir un accès rapide aux interfaces web natives des outils de supervision sous-jacents.
- Une console de messages (partie centrale inférieure) donne les détails sur les sondes associées aux services de la couche basse.
- Un panneau de statistiques (coin supérieur droit) donne des informations statistiques sur l'état des services de la couche basse (sondes). À l'aide de la souris, on peut avoir une infobulle qui donne les détails sur le nombre et le pourcentage de sondes ayant les différentes sévérités (normal, majeur, mineur, critique, indéfini).
- Une barre de menus et une barre d'outils (partie supérieure) offrent l'accès aux fonctionnalités via des menus.
Fig. 8 : Capture d'écran annotée de la console des opérations
4.6 Modèle de sévérités
RealOpInsight repose sur un modèle de sévérités particulier, qui permet d'unifier les modèles de sévérité des différents outils de supervision sous-jacents. Cinq niveaux de sévérité sont disponibles :
- Normal : indique que le service concerné fonctionne normalement ;
- Mineur (Minor) : indique que le service concerné est faiblement impacté ;
- Majeur (Major) : indique que le service concerné est fortement dégradé ;
- Critique (Critical) : indique que le service concerné est indisponible ou inaccessible ;
- Indéfini (Unknown) : indique que pour une raison quelconque, on n'est pas en mesure d'évaluer l'état du service concerné.
Le tableau ci-dessous résume l'équivalence entre ce modèle et les modèles de sévérité de Nagios et dérivés, de Zabbix et de Zenoss.
RealOpInsight | Nagios | Zabbix | Zenoss |
NORMAL | OK | CLEAR | CLEAR |
MINOR | - | INFORMATION, WARNING | DEBUG |
MAJOR | WARNING | AVERAGE | WARNING |
CRITICAL | CRITICAL | HIGH, DISASTER | ERROR, CRITICAL |
UNKNOWN | UNKNOWN | NOT CLASSIFIED | - |
Conclusion
Dans cet article, nous avons montré qu'à l'ère des nuages informatiques et des architectures orientées services, considérer la supervision d'un point de vue métier est devenu un enjeu majeur. Non seulement cela permet d’être efficace en évitant de perdre du temps sur de fausses alertes, mais aussi, cela permet d'améliorer la productivité et l'efficacité des équipes opérationnelles en leur permettant de prioriser la résolution des incidents en fonction de leur impact sur les services métiers.
Nous avons par la suite présenté le projet RealOpInsight qui répond à cette problématique avec des outils de supervision couramment utilisés comme Nagios, Zabbix et Zenoss. Open source, et avec une approche originale qui vise interopérabilité et généricité, le logiciel se greffe facilement sur différents types d'outils de supervision. De plus, depuis sa version 2.4, il permet d'extraire des informations provenant de plusieurs sources de supervision en parallèle, ce qui permet d'offrir une vue métier unifiée dans des environnements de supervision distribués et hétérogènes.
Nous n'avons pas abordé d'autres aspects avancés de RealOpInsight concernant par exemple l'agrégation et la propagation de sévérités. Les lecteurs intéressés pourront trouver des détails dans la documentation officielle disponible sur Internet : http://realopinsight.com.
Références
[1] RealOpInsight : http://www.realopinsight.com
[2] Nagios : http://www.nagios.com
[3] Zabbix : http://www.zabbix.com
[4] Zenoss : http://www.zenoss.com
[5] Icinga : http://www.icinga.com
[6] Centreon : http://www.centreon.com
[7] op5 Monitor : http://www.op5.com
[8] Panorama de monitoring-fr.org sur les solutions de supervision open source : http://wiki.monitoring-fr.org/supervision/links
[9] Sondage sur les outils de supervision préférés des utilisateurs : http://www.linuxquestions.org/questions/2012-linuxquestions-org-members-choice-awards-104/network-monitoring-application-of-the-year-4175441862/page3.html
[10] Documentation de l'API de Zabbix : https://www.zabbix.com/wiki/doc/api
[11] Documentation de l'API de Zenoss : http://community.zenoss.org/community/documentation/official_documentation/api
[12] Documentation du service ngrt4nd : http://realopinsight.com/en/index.php?page=install-and-configure-daemon-for-nagios
[13] Documentation de MK Livestatus : http://mathias-kettner.de/checkmk_livestatus.html
[14] Documentation de Shinken Livestatus : http://www.shinken-monitoring.org/wiki/livestatus_shinken
