Soutenance mémoire
La surveillance des systèmes La surveillance des systèmes d’ d’d’ d’information information information
La notion de surveillance d’un système d’information, quel qu’il soit, intervient lorsque l’indisponibilité de ce système pose un problème, et qu’il est nécessaire d’avoir une réaction aussi efficace que possible pour un retour à la normale dans les meilleurs délais, selon ce qui est défini dans les SLA. Cela peut être pour un problème de coupure de fonctionnement qui engendrerait une perte de données, de temps ou d’argent. Dans la nomenclature ITIL, il s’agit de « Availability Management ». Cela peut aussi simplement permettre d’anticiper l’achat de matériel supplémentaire. La notion d’anticipation de la scalabilité du système informatique fait partie du processus « Capacity planning » dans ITIL. La mise en place d’une méta-surveillance peut permettre de détecter des problèmes de congestion du réseau ou de ressource limitée et apporte ainsi une solution au besoin d’anticipation.
Faut il surveiller l’informatique ou l’information ?
Tout au long de ce mémoire, il est plusieurs fois abordé le problème de la catégorisation de tel ou tel élément du système informatique. En effet, dans un processus de mise en production d’une application et de la mise en place de la surveillance de cette application, un élément peut être de type composant d’infrastructure ou de type service applicatif. C’est le cas d’un serveur web Apache par exemple. Si celui-ci peut être considéré comme une application qui tourne sur un serveur physique, on parle couramment de « serveur Apache ». Du point de vue de l’ingénieur système, cette situation est considérée comme une application qui s’installe sur un serveur d’infrastructure. Du point de vue du chef de projet dont la mission est de mettre en place une nouvelle application métier, le serveur Apache fait partie de l’infrastructure, au même titre qu’un serveur physique. En effet, un serveur physique seul ne lui sert à rien, c’est pourquoi l’infrastructure est vue alors comme un tout.
Les tests permettant de faire cette surveillance technique sont communs à l’ensemble des composants du même type. Ainsi, il n’est pas nécessaire de redévelopper les tests techniques à l’ajout d’un nouveau serveur.
Surveillance des applications Surveillance des applications
La deuxième partie consiste à surveiller la disponibilité des applications, c’est ainsi qu’on vérifie qu’un service applicatif fonctionne correctement, et que les flux métiers fonctionnent entre les systèmes et ceci indépendamment de l’état de l’infrastructure. Ce que l’on nomme service applicatif peut être composé d’une multitude d’applications ou services qui tournent sur un serveur et qui constituent le système d’information. C’est une surveillance métier.
Pour surveiller des applications, cela requiert de définir des cas de tests métiers, qui sont spécifiques à chaque écran de l’application. Un écran accessible avec différents niveaux de responsabilités devra être testé avec autant de scénarios qu’il y a de possibilités.
Évolution du besoin de surveillance
La surveillance est elle un besoin nouveau ?
La surveillance a considérablement évolué ces vingt dernières années. Avant, le système informatique des entreprises reposait sur un mainframe, application monolithique dont l’architecture était composée d’éléments propriétaires. Les postes utilisateurs n’avaient aucune complexité et seule l’unité centrale, contenant les données et les traitements métiers, ainsi que le réseau devaient être surveillés. La surveillance consistait à contrôler les lignes de log qui défilaient à l’écran. Lorsqu’une anomalie survenait, elle était détectée rapidement ou annoncée par les utilisateurs. Car bien souvent une anomalie sur un mainframe impactait un nombre important d’utilisateurs.
L’arrivée du protocole IP a augmenté la complexité des architectures réseaux en entreprise, c’est pourquoi les premiers composants à avoir été surveillés avec un système dédié à la surveillance ont été les éléments réseau. Puis, avec l’arrivée d’Internet, chaque fournisseur d’accès à Internet se devait de surveiller la qualité des services fournis.
A ce jour, l’informatique est un monde distribué, où chaque composant offre une fonctionnalité spécifique. Les composants communiquent entre eux, et si l’un d’eux n’est plus accessible, c’est l’ensemble de l’architecture qui s’en trouve affaiblie. C’est pourquoi le besoin de surveillance est devenu capitale.
Problématique des alertes
Comment lever une alerte qui soit cohérente ? Voici un exemple de cas réel rencontré dans une grande entreprise : lorsqu’une chaine de sauvegardes sur les serveurs hébergeant les bases de données s’interrompt, cela génère une alerte et un ticket d’incident pour chacune des applications métiers faisant référence à ces bases de données, bien que les applications ne soient en réalité pas impactées. Les tickets sont envoyés de manière automatique à l’équipe d’intégration. Comme chaque ticket concerne des applications métiers différentes, il ya de grandes chances que ce soit une personne différente qui reçoive le ticket de panne à traiter. Chacune de ces personnes va prendre le temps d’analyser, contrôler et tester son application pour comprendre le problème. Chacun finit par déduire que c’est la chaine de sauvegardes qui a provoqué cette erreur, et complète l’information du ticket d’incident avec son propre diagnostic et le transfère à l’équipe qui s’occupe de la chaine de sauvegardes. Cette équipe, au bout d’un certain temps, constate que le problème touche plusieurs applications et reçoit en retour chaque ticket de panne envoyé par les différents intégrateurs. Il est possible que la panne de la chaîne de sauvegardes a elle aussi généré une erreur qui a directement été envoyée à la bonne équipe. Cette panne est peut-être déjà corrigée, alors même que les intégrateurs n’ont pas encore fini d’analyser les premiers incidents reçus.
Avec une méta-surveillance qui intègre et fait une synthèse des différents systèmes de surveillance, cette perte de temps et d’argent peut être évitée. Si cela avait été le cas dans notre exemple, l’intégrateur aurait vu immédiatement le statut en erreur de la chaine de sauvegardes. Il pourrait même consulter l’ensemble des applications qui dépendent de cette chaine de sauvegardes, et ainsi être proactif et prévenir ses collègues.
Un autre exemple rencontré dans une entreprise importante : un composant utilisé par deux applications jugées critiques et stratégiques pour l’entreprise est partiellement tombé en panne. C’est-à-dire que certaines fonctionnalités étaient inopérantes. Un intégrateur responsable d’une des applications en lien avec ce composant a vu la panne et s’en est occupé. Voulant bien faire, il a contacté le centre d’assistance afin d’ouvrir un ticket pour avoir une trace de cet incident critique. Comme il s’en occupait, le ticket d’incident lui a été directement envoyé. Ce que cette personne ignorait, c’est que ce composant était également utilisé par une deuxième application. Voulant rétablir le lien entre le composant et son application, il a demandé à ce que l’on redémarre le serveur hébergeant ce composant. Cela a généré des perturbations importantes pour la deuxième application, elle aussi stratégique. Le fait que cette application devienne inactive suite à l’action d’un ingénieur du centre informatique a créé une polémique bien plus importante que le fait d’avoir un composant dont certaines fonctionnalités étaient indisponibles.
S’il y avait eu un dispositif d’alerte centralisé, lié avec une notion de dépendance entre les applications et les composants, cela aurait été découvert immédiatement, et cette erreur d’un ingénieur qui pensait bien faire n’aurait jamais eu lieu. C’est pourquoi il est indispensable que le système de surveillance soit couplé à une CMDB. Certains produits permettent d’avoir une découverte automatique de l’infrastructure soutenant une application. Si l’infrastructure est importante, ce genre de solution peut faire gagner un temps certain.
Un système d’alerte est particulièrement utile lorsqu’une application tombe en panne durant la nuit. L’ingénieur recevant l’alerte a alors théoriquement le temps d’intervenir avant la reprise du travail lematin suivant. Car il n’y a rien de plus désagréable pour un utilisateur que d’avoir son application qui ne soit pas accessible en arrivant de bonne heure le matin au travail, et de devoir attendre que les ingénieurs identifient et corrigent la panne pour commencer à travailler.
Le dernier cas soulevé est celui d’un composant en cluster. Si l’un des clusters tombe en panne, alors on doit pouvoir le rétablir, sans mêmeque l’utilisateur ne le constate. Cela implique de séparer les tests applicatifs des testsinfrastructure, et de lever des alertes pour chaque composant qui pourrait tomber en panne, indépendamment du service applicatif. Un test applicatif seul, il n’aurait jamais détecté qu’un composant en cluster puisse être en panne, puisqu’un autre composant aurait pris la relève.
Gestion des incidents
Un incident est une interruption imprévue du fonctionnement ou une réduction de la qualité de service, celui-ci concerne les applications ou encore un des composants d’une application. En plus de détecter les événements et de trouver le meilleur moyen d’agir, la gestion des incidents doit aussi s’assurer du rétablissement de la fonction normale d’un service, comme défini dans les SLA.
Gestion des problèmes Gestion des problèmes
Un problème est la cause inconnue de la source d’unincident ou d’une série d’incidents.
L’objectif de la gestion des problèmes est de prévenir l’apparition des problèmes et des incidents qui en découlent, d’éliminer les incidents récurrents et de minimiser l’impact des incidents imprévisibles. La surveillance et le contrôle sont des activités primordiales de l’exploitation des services et peuvent grandement aider à détecter la source de certains problèmes.
Accord sur les niveaux de services Accord sur les niveaux de services
Un accord entre un fournisseur de services du centre informatique et un client est appelé un SLA (Service Level Agreement). Le SLA décrit le service des technologies de l’information, documente les objectifs du niveau de services attendu et spécifie les responsabilités du fournisseur de service et du client. Un seul SLA peut couvrir plusieurs services ou plusieurs clients.
Accord sur les niveaux opérationnels Accord sur les niveaux opérationnels
Un accord entre les fournisseurs de services d’un même centre informatique (entre le réseau et les serveurs par exemple) est appelé un OLA (Operational Level Agreement). Un OLA permet de définir le niveau d’exigences entres les services et composants qui vont au final, une fois mis bout à bout, fournir le service attendu par le client. Un SLA ne peut pas être plus exigeant que les OLAs passés entre les services informatiques dont il dépend.
Accord avec les entités externes
Un accord entre un fournisseur de services du centre informatique et une entité externe à l’organisation est appelé un UC (Underpinning Contract). Cela fonctionne selon les mêmes principes qu’un OLA, à l’exception du cadre juridique qui est différent, car il se signe avec des sociétés tierces.
La Méta surveillance
Les enjeux d’une méta surveillance
L’objectif n’est pas de réinventer ce qui existe déjà, ni réimplémenter un système de test complet. Il existe des logiciels qui font ça très bien. Certains, utilisés au CTI, sont présentés dans la section 3.7 – Les scénarios possibles pour une méta-surveillance. Le but est de développer un modèle générique qui permette d’avoir une vue d’ensemble de la
disponibilité des SI, quel que soit le niveau de granularité et quels que soient les types de systèmes informatiques concernés. Ce modèle doit apporter une solution pour améliorer le dialogue entre les équipes du centre informatique, afin d’améliorer la gestion des incidents, et surtout d’ouvrir certains tableaux debord aux utilisateurs.
L’interface utilisateur, un ensemble de tableaux debord
Un utilisateur peut consulter un ensemble de tableaux de bord qui le concerne. C’est-àdire que si l’utilisateur a accès à son applicationmétier, alors il doit pouvoir consulter le statut de la disponibilité de son application. Celapeut se faire de manière automatique, en interfaçant la couche tableaux de bord avec le référentiel de gestion des accès. Les données d’un tableau de bord consistent en un ensemble d’indicateurs et de métriques sur la disponibilité (cf. la section 3.4 – Les tableaux de bord)
L’interface d’une méta-surveillance ne peut qu’être une interface web. À ce jour, le web est arrivé à sa pleine maturité. Il est impensable de développer une solution en client riche pour le projet qui nous intéresse. Un utilisateur doit pouvoir se connecter en tout en temps et en tout lieu, sans avoir besoin d’installer de client. Le web est la seule solution qui apporte autant de confort et de souplesse. À ce jour, il est possible d’y développer des interfaces complexes, incluant notamment des menus contextuels, ou la gestion multi-événements, alors qu’il y a à peine quelques années, ceci n’était réservé qu’aux applications en client riche à installer sur chaque poste utilisateur.
Les écrans des smartphones sont maintenant de 4 pouces et permettent aisément d’avoir une interface web qui soit agréable et utilisable depuis n’importe où. Il est tout à fait concevable de développer des tableaux de bord spécifiques pour le format smartphone.
Dans le cadre d’une méta-surveillance, l’utilisateur navigue dans ses tableaux de bord en partant d’une vue globale, par application ou par typologie de service. On peut imaginer une structure par département ou par service d’états-majors.
Un niveau « Core », pour la collecte et le traitement des données
Le niveau « Core » est la partie centrale et la partie la plus complexe d’une architecture de surveillance. Elle permet de collecter les données, les traiter, les filtrer et les corréler entre elles. Le Core offre également un ensemble de connecteurs pouvant aller chercher l’information dans d’autres systèmes, comme une CMDB ou un autre système de surveillance, ainsi que des APIs pour que d’autres systèmes de surveillance puissent venir y écrire des données.
Cette partie doit retenir la plus grande attention lors de la décision d’achat d’un logiciel de surveillance, car si les tests et les connecteurs ne sont pas compatibles avec l’infrastructure existante, alors le projet est un échec.
Plusieurs types de tests peuvent être effectués pour contrôler le bon fonctionnement d’une application :
• Test technique de composant avec un résultat binaire (ex. : ping, présence d’un fichier dans un dossier)
• Test technique avec un seuil (ex : contrôle du nombre d’entrées dans un serveur LDAP, taille disque restante)
• Test end-user
• Test de performance end-user
Les tests « end-user » sont généralement faits depuis un robot de surveillance placé dans le bâtiment ou même dans les bureaux des utilisateurs. Un test end-user consiste à simuler l’activité de l’utilisateur derrière son écran. Le gros avantage de ce genre de test est de simuler et de constater exactement ce que voit l’utilisateur. Si un élément informatique, spécifique à la localisation géographique des utilisateurs, avait un problème, comme un problème sur un élément réseau, cela se verrait avec un test enduser, alors que chaque élément surveillé séparément depuis la salle des serveurs ne donnerait probablement aucune indication.
Les tests de performance consistent à exécuter un certain nombre de requêtes, toujours les mêmes, et à calculer le temps de réponse de chaque requête. Le temps de réponse est comparé à un seuil qui définit si la performance est jugée satisfaisante.
Un niveau de persistance, pour stocker les données
Le stockage des données permet de générer des rapports avec l’historique de la disponibilité d’un système ou de chaque composant. Il est important de bien définir ce qui doit être conservé, afin de garder l’essentiel des données, sans stocker les informations superflues.
On peut garder durant un cours instant les données pour faire du temps réel. Mais cette manière de faire ne permet pas de consulter un historique après coup.
Le référentiel des test
De nombreux logiciels de tests existent sur le marché. Que cela soit des logiciels open source ou des logiciels propriétaires du marché. Certaines suites logicielles sont dédiées à la surveillance de composants, alors que d’autres sont spécialisées dans les tests applicatifs, simulant le comportement d’un utilisateur. Certains éditeurs logiciels proposent leur propre surveillance spécialisée dans les tests de leurs logiciels. C’est notamment le cas de SAP , Oracle ou encore Windev.
Il existe de nombreux logiciels dont les fonctionnalités se ressemblent beaucoup et qui sont un peu « généralistes ». Leur différentiation réside principalement dans les possibilités de définition de rapports spécifiques ou métiers, ou encore dans la définition des tableaux de bord de statistique. La majorité deces logiciels proposent de faire des découvertes automatiques du parc informatique.
Il est souvent possible d’exécuter des tests depuis un scanner centralisé, mais le plus souvent il faut installer un agent sur le serveur. Un agent est un exécutable qui tourne sous forme de service sur le serveur distant. Un ordonnanceur déclenche le test à intervalle régulier. Tous les logiciels de test ne sont pas nécessairement compatibles avec l’ensemble des systèmes d’exploitation.
Les logiciels de test, ou robots de surveillance, contrôlent principalement la disponibilité d’un serveur, l’accès à Internet, utilisent des scripts pour connaître la température du processus, de la mémoire, ou font des tests réseaux. Cela permet notamment de détecter bien avant que l’utilisateur ne soit impacté toutes les défaillances matérielles ou lorsque l’espace disque arrive à saturation. De nombreux scripts peuvent être développés, soit dans un langage propriétaire du robot de test, ou dans les langages plus courants comme le Python, le Perl ou même PHP.
À la détection d’un événement qui dépasse un seuil prédéfini, cela déclenche une alerte qui peut être :
• Un simple bip ou une boîte de dialogue d’information sur le serveur
• Un email envoyé à l’administrateur du serveur
• Un SMS envoyé à une liste de numéros préenregistrés
• Un message, JMX par exemple, envoyé à une autre application
• Le lancement d’une procédure de test de diagnostic plus complet
• Le lancement d’un programme tiers
Même si une alerte « error » a été envoyée, le robot de surveillance continue à faire son test à intervalle régulier. À moins que cela ait été spécifiquement défini, aucune nouvelle alerte n’est envoyée si le test est toujours en échec. Par contre, lorsque le test donne à nouveau un résultat valide, alors une alerte « OK » est envoyée pour informer les ingénieurs de l’état de disponibilité de la ressource.
Une solution unique ne couvrant en général jamais l’ensemble d’un besoin, il est courant que plusieurs solutions soient mises en commun pour couvrir l’ensemble du besoin. Dans une solution mixte, s’il existe plusieurs moteurs de surveillance qui gère chacun leur stockage des données, l’interface est normalement commune. C’est sur cette base que je propose une solution de modèle de méta-surveillance.
Centre de Service (Helpdesk)
Il arrive qu’un incident soit détecté par l’utilisateur avant que le système de surveillance ne le détecte. Soit parce que le cas de test n’a pas été pensé, soit parce que le système fait un test à une fréquence qui a permis à l’utilisateur d’être plus rapide. Dans ce cas, il est nécessaire que le Centre de Service puisse lui-même changer le statut d’un composant ou une application et le mettre en erreur.
Lorsque le statut est mis à jour manuellement, il ne faut pas que le système de contrôle automatique puisse rechanger le statut. Un statut mis à jour manuellement en erreur, doit être remis à jour manuellement en « OK », soit par le Centre de Service, soit par le surveillant, soit par le concepteur responsable du composant ou de l’application.
Dans un cas idéal, ce n’est pas manuellement que lestatut devrait être mis à jour, mais cela se fait automatiquement à l’ouverture d’un incident. Cela implique que le système de surveillance doit être interfacé avec l’outil de gestion des incidents.
À l’ouverture du ticket, il doit être possible de référencer le composant ou l’application, et son statut mis à jour automatiquement. À la fermeture de l’incident, les tests de l’élément concerné sont lancés automatiquement, afin de remettre à jour son statut.
Concepteur applicatif
Le concepteur applicatif a la charge de définir les tests applicatifs et développer les scénarios end-user. Il doit également définir la dépendance entre les applications et les composants. Ceci se fait en relation avec le CMDB si elle existe.
|
Table des matières
Introduction
1 Définition
2 La surveillance des systèmes d’information
2.1 Faut-il surveiller l’informatique ou l’information ?
2.1.1 Surveillance de l’infrastructure
2.1.2 Surveillance des applications
2.2 Évolution du besoin de surveillance
2.2.1 La surveillance est-elle un besoin nouveau ?
2.2.2 La surveillance s’applique-t-elle à tout le monde ?
2.2.3 Adopter un système de surveillance centralisé
2.3 Problématique des alertes
2.4 Objectif : Haute disponibilité
2.4.1 Calcul de la disponibilité
2.4.2 Cloud Computing, une révolution ? .
2.5 La surveillance applicative en relation avec ITIL
2.5.1 Gestion des incidents
2.5.2 Gestion des problèmes
2.5.3 Métriques de disponibilité
2.5.4 Accord sur les niveaux de services
2.5.5 Accord sur les niveaux opérationnels
2.5.6 Accord avec les entités externes
3 La Méta-surveillance
3.1 Les enjeux d’une méta-surveillance
3.2 Architecture de la surveillance
3.2.1 L’interface utilisateur, un ensemble de tableaux debord
3.2.2 Un niveau « Core », pour la collecte et le traitement des données
3.2.3 Un niveau de persistance, pour stocker les données
3.2.4 Le référentiel de gestion des accès
3.2.5 Le référentiel de services applicatifs et des composants
3.2.6 Le référentiel des tests
3.3 Les rôles
3.3.1 Les cas d’utilisation
3.3.2 Description des rôles de la méta-surveillance
3.3.3 Description des cas d’utilisation
3.4 Les tableaux de bord
3.4.1 Les différentes vues
3.4.2 Les indicateurs
3.4.3 Filtre sur les indicateurs en fonction du rôle
3.4.4 Réflexion sur la pondération d’indicateur
3.5 Le temps réel
3.6 Système d’alertes
3.7 Les scénarios possibles pour une méta-surveillance
3.7.1 Développement complet
3.7.2 Choisir un outil open source ou gratuit
3.7.3 Opter pour une solution commerciale qui couvre l’ensemble du besoin
3.7.4 Adopter une solution intermédiaire qui soit un mixte des trois
4 Réalisation technique d’un POC dans le contexte du CTI
4.1 Le Centre de Technologies de l’Information
4.1.1 Les éléments surveillés au CTI
4.1.2 Le projet ARGOS
4.1.3 Le projet SI-Alert
4.2 POC : Méta-surveillance de l’application « GINA.Manager »
4.2.1 But du POC
4.2.2 Les différentes étapes de la réalisation
4.2.3 Choix des outils de surveillance
4.2.4 Architecture de « Gina.Manager »
4.2.5 Tests applicatifs et tests des composants avec Nagios
4.2.6 Intégration des rôles de base dans Nagvis
4.2.7 Tableaux de bord Utilisateur avec l’extension Nagvis
4.2.8 Tableaux de bord Concepteur, avec l’extension Nagios Business Process
4.2.9 Discussion sur les résultats du POC
Conclusion
Annexe A – Classification des environnements
Bibliographie
Liste des figures
Liste des tableaux
Résumé
