Articles

livre blanc

Une analyse des coûts de la supervision [partie 3]

Cet article clos notre analyse des coûts de la supervision sur un exemple… instructif.

Exemple

Une petite démonstration valant plus qu’un long discours, voici un petit exemple qui je l’espère vous permettra de vous mettre les idées plus au clair. Vous pouvez vous même remplacer les hypothèses prises par les informations réelles de votre entreprise, afin de vous faire un ordre d’idée de ce fameux coût réel de la supervision.

Hypothèse

Nous allons prendre le cas de la DSI d’un grand compte. Cette DSI héberge 2000 serveurs, pour la plupart virtualisés, pour environ 100 applications.

Cette DSI a fait le choix d’une solution de supervision propriétaire, et a mis en place de la supervision et de l’hypervision, ce qui représente un coût important, mais les attentes de ses clients lui demandent tout un tas de garanties qui font qu’elle a préféré s’appuyer sur un éditeur pour avoir une garantie de support.

Elle a aussi fait le choix de mettre en place des scénarios de supervision applicative sur 10 de ses applications critiques, en passant aussi par la solution d’un éditeur.

Les équipes de supervision de cette DSI sont constituées de 5 personnes à temps plein, deux assurant le récurrent, un travaillant sur la partie robots, un responsable de l’équipe qui tient aussi le rôle de pilote de l’amélioration continue et un profil d’architecte qui gère aussi l’hyperviseur.

Les experts quant à eux sont composés de 4 experts réseaux (Deux sites et une DMZ), de 5 experts système (pour supporter les souches unix et windows), et de 4 experts middleware (dont 2 pour oracle, et 2 pour les solutions Web). La DSI n’a pas fait le choix de SAP.

Les applications sont réparties par groupe représentant des clients. 4 équipes gèrent la totalité, et on compte en tout 8 pilotes d’applications.

Le pilotage fait du 3*8 et est composé de 7 personnes, qui ont en charge la gestion des incidents (outils de ticketing) et le suivi de la supervision.

Voilà qui définit le contexte de notre client imaginaire.

Passons maintenant au détail de l’analyse financière.

Coûts de licences

L’entreprise a pris une solution de supervision propriétaire

Coût d’acquisition 100 K€, 20K€ de maintenance par an

Elle a aussi investi dans les solutions d’hypervision de cet éditeur

Coût d’acquisition 250 K€, 50K€ de maintenance par an

Elle a fait l’acquisition de robots pour superviser ses applications critiques

Couts d’acquisition 100K€, maintenance 20 K€ /an

Coûts de l’équipe de supervision

L’équipe est présente toute l’année. Les profils sont trois profils consultants, un profil consultant sénior, un profil chef de projet.

Le coût d’un consultant standard est évalué à 100 K€ par an. Celui d’un architecte et d’un chef de projet à 150 K€.

Coût par an des ressources supervision : 600K€.

Coût des équipes d’exploitation

Sur les 7 ressources affectées au pilotage, 5 d’entre elles ont la supervision comme outil de travail quotidien.

Une ressource de pilotage est estimée à 80 K€ par an.

Coût par an des ressources d’exploitation : 400K€

Coût des infrastructures de supervision

L’infrastructure qui permet de réaliser la supervision est composée de 5 VM hébergeant du Linux ; l’hypervision rajoute une VM supplémentaire. Les robots quand a eux occupent 5 VM différentes.

L’infrastructure globale de supervision occupe donc 11 VMs[1].

Le coût d’hébergement estimé d’une VM est de 1500€/mois[2].

Coût par an de l’infrastructure : 200 K€

Coût de la charge transverse

Les diverses demandes de mise en supervision, les suivis de nouvelles corrections et les évolutions de scénarios suite à des mises à jour entraînent une charge équivalente à un ETP dans les équipes applicatives.

La définition des alarmes, les dérangements suite à alarmes non maîtrisées, le maintien d’un catalogue et les évolutions suite aux évolutions des solutions des éditeurs entraînent un équivalent de charge d’un ETP côté experts système et côté experts middleware.

Soit un coût de 110K€+180K€*2= 470 K€

coût par an de la charge transverse : 470 K€

Bilan

Un simple graphe devrait donc permettre de comprendre ou se situent les coûts réels de la supervision :

cout annee 1

Coût total année 1 : 2,1 M€

Sur la première année, les licences représentent 21% du coût, et les charges humaines 57%.

Dès la seconde année, l’écart s’aggrave :

cout annee 2

Coût total année 2 : 1,7 M€

Le volet humain représente 68% de la charge, alors que celui des licences ne représente plus que 5%.

Un dernier mot pour finir cette section ;

Il est amusant de voir que dans beaucoup d’organisations, les seuls coûts de licences et de ressources supervision seront pris en compte quand on tentera d’évaluer le coût de la supervision.

On aura donc un coût évalué en année 1 de 1,05 M€ et un coût évalué ensuite de 0,69 M€, soit une estimation fausse à chaque fois qui prend en compte à chaque fois moins de la moitié  du coût réel.

Pensez-vous toujours que les licences, si elles sont un levier d’économies, sont réellement le cœur du problème ? Peut être que l’optimisation des ressources en améliorant la qualité de la supervision aura un impact bien supérieur…


[1] Cette infrastructure correspond à ce que j’ai pu voir, au fil des audits, chez plusieurs clients.

[2] J’ai conservé d’un ancien poste une matrice devis qui donnait ce chiffre, en ajoutant les coûts d’hébergement, d’exploitation, de licences et de renouvellement de l’infrastructure.

livre blanc

Une analyse des coûts de la supervision [partie 2]

Voici la seconde partie de notre article, qui présente cette fois le détail des coûts.

Quels gains pour quelle supervision ?

Nous allons aborder plus loin la question du coût réel de la supervision. Mais avant cela, pour poursuivre sur le point précédent, je pense qu’il est important de détailler plus avant les bonnes questions à se poser lorsque l’on décide de mettre en place une solution de supervision pour garantir l’application d’un client. Parce qu’à l’heure où tout le monde resserre les budgets, il serait malavisé de définir une solution « unique » pour toutes les applications. Cela permettrait sans doute de baisser le coût à l’application, mais cela aurait un impact évident sur le coût global.

Voici la méthodologie que je propose, qui repose sur plusieurs points.

La plateforme de supervision modulaire

Il existe différents outils, et tous ne s’appliquent pas à tous les besoins clients. Si la plateforme de supervision « standard » présente un intérêt à être mise en œuvre pour tous les clients, il n’en va pas de même pour tous les outils qui l’entourent.

Définissez donc votre supervision comme suit :

  • Une supervision standard pour toutes les applications (système, middleware, réseau…)
  • Une supervision applicative pour les applications qui demandent une investigation plus pointue,
  • Des robots réservés aux clients ou il y a soit un besoin « d’étalon », soit un besoin de réactivité, soit une demande express client
  • Des analyseurs de performance pour les applications critiques qui le nécessitent.

A quel besoin client répondre ?

Le client souhaitera par nature la meilleure des supervisions pour le coût le moins élevé possible. Il n’est un secret pour personne que lors des spécifications, pour un client tout est nécessaire, et lorsqu’on passe à la facture, en général on se rend compte que certains besoins ont été surévalués. Pour vous aider dans votre choix, voici une liste de questions à vous poser à chaque fois qu’une application doit être mise en supervision :

  • Quel est le coût réel d’une indisponibilité de l’application ?
  • A partir de combien de temps d’indisponibilité la solution mise en place sera-t-elle rentabilisée ?
  • Quelle est l’importance de l’application pour le client ?
  • L’application fait-elle partie d’une chaîne ayant un engagement de service restrictif ?
  • L’indisponibilité de l’application peut-elle être néfaste à l’image du client ?
  • Sur quel niveau d’engagement le client est prêt à investir pour cette application ?
  • Ce niveau d’engagement est-il justifié ? (surqualité / prise de risque)
  • Le client a-t-il besoin d’un « juge de paix » sur les temps de réactivité de son application ?
  • La stabilité de l’application justifie-t-elle de mettre en place des outils de mesure de la performance ?
  • La fréquence des mises en production et les surcoûts engendrés peuvent ils entraîner la mise en place d’outils de mesure de la performance ?
  • Que suis-je prêt à partager avec le client en retour de son investissement (consoles…)
  • Les outils dans lesquels le client me demande d’investir me permettent-ils de mesurer les SLA demandés et de garantir la disponibilité de l’application ?

Toutes ces questions devraient permettre de renseigner suffisamment une application pour choisir les outils de supervision adaptés au contexte, et éviter les dépenses inutiles.

Les différents coûts de la supervision

Il n’y a pas un coût de la supervision, mais des coûts de supervision. Je vais aborder ci-après un à un les postes de coûts de la supervision en vous les détaillant. On retrouve :

  • Les licences, le support
  • Les ressources des équipes supervision
  • Les ressources des équipes d’exploitation
  • Les infrastructures de supervision
  • La charge générées dans les autres équipes d’exploitation (experts, équipes applicatives,…)

Licences et support

Je suis presque sûr que quand on aborde avec vous le thème des coûts de la supervision, dès lors que vous avez des solutions propriétaires, ce qui vous vient en premier à l’esprit c’est le poste « licences ».

Les licences de supervision des éditeurs sont coûteuses, leur mode  de licencing change régulièrement, et les produits évoluant et se dirigeant vers la « fin de vie », vous vous retrouvez souvent contraints de racheter des licences qui incluent des fonctionnalités supplémentaires, dont vous pensez ne pas avoir le besoin, mais qui sont obligatoires si vous souhaitez continuer à bénéficier du support. Ce mode « captif » des clients a tendance à accroître cette image négative de la supervision, d’autant plus depuis que sur les couches dites « basses », les solutions libres offrent une alternative convaincante aux solutions propriétaires, pour un coût de licence moindre.

Un second point à analyser, et le fait que, même sans parler du libre, selon le service rendu, les coûts de licences sont vraiment différents. Certains outils atteignent des coûts de licences « démentiels », je veux parler des outils d’introspection ou d’analyse de trames réseau, qui peuvent atteindre jusqu’à des millions d’euros d’acquisition.

Mais, une fois de plus, il faut mettre le coût du produit en face du besoin. Si vous gagnez des centaines de millions d’euros sur une application, et qu’une indisponibilité peut entraîner une perte sévère, alors le coût somme toute élevé, sera à mettre en face d’une éventuelle indisponibilité, et du manque à gagner généré.

Équipes de supervision

Un second coût qui est mis en avant et bien souvent celui des équipes supervision. Les produits étant souvent complexes d’utilisation, on se retrouve rapidement à des équipes d’administration, d’architectes et de support avec des coûts par ressource de l’ordre de 100 K€ à l’année. Le fait est que les produits du marché sont livrés bruts de fonderie, et qu’il faut beaucoup de monde pour parvenir aujourd’hui à en réaliser un usage correct. Par exemple, lorsque vous prenez une solution du marché de supervision de base, vous avez à définir vous même quels paramètres superviser (ou ne pas superviser), toute la documentation qui va avec la supervision, toute l’organisation de la supervision, et pour peu que vous ayez un hyperviseur, il y a aussi le travail de corrélation des remontées à réaliser, qui lui est encore plus complexe ! Les solutions de supervisions ne sont que des outils, plus ou moins aboutis, et qui nécessitent donc beaucoup de travail pour s’adapter à votre organisation.

Je profite d’ailleurs de cette section pour présenter un autre fait avéré qui n’est malheureusement que rarement pris en compte dans les entreprises :

Le libre coûte beaucoup plus cher qu’on le pense.

Les solutions libres sont en général plus ouvertes, donc nécessitent plus de ressources pour les administrer, et surtout des ressources qui savent ce qu’elles veulent faire ! Le support n’est pas fourni par un éditeur, ce qui sous entend des investissements supérieurs pour corriger des problèmes, et le fait de dépendre d’une communauté, certes active, mais pas dédiée à résoudre VOTRE problème. Par conséquent, si on reprend mon échelle de 100 k€ la ressource, on se rend vite compte que le fait de partir sur du libre de manière non réfléchie peut s’avérer plus coûteux que de prendre des solutions propriétaires.

Les équipes d’exploitation

Le troisième coût représentatif est celui porté par les équipes d’exploitation. Ce coût est rarement associé au coût de supervision, et pourtant, à mon sens, il lui est directement lié :

  • Si vous avez plusieurs outils de supervision, cela vous donne à traiter plusieurs consoles et donc multiplier les ressources pour assurer  leur suivi
  • Si votre supervision n’est pas mature, cela entraîne plus d’alarmes et donc plus de ressources pour les traiter
  • Si votre supervision n’est pas industrialisée, vous avez beaucoup de gestes manuels à accomplir qui vont eux aussi nécessiter beaucoup de ressources pour les traiter.

Ainsi les coûts d’équipes d’exploitation sont directement liés à la maturité de la solution de supervision et aux investissements réalisés au préalable afin d’optimiser. Comme je le disais, vous devez entrer vos coûts d’équipes d’exploitation dans le calcul global du coût de votre supervision, tout du moins sur la partie sur laquelle ils sont amenés à intervenir.

Infrastructure

Les coûts d’infrastructures de supervision sont bien souvent négligés, et c’est un tort. L’infrastructure des outils de supervision est bien souvent complexe, s’appuyant sur des relais, stockant les informations dans des bases de données, ayant besoin de portails web…

Selon l’importance que l’on accorde à l’infrastructure, il peut aussi y avoir de la redondance, ainsi que des capacités de bascule entre sites. Si le SI est composé de plusieurs DMZ, c’est autant de serveurs passerelles qui devront être installés afin de relayer l’information de supervision sans porter atteinte aux contraintes de sécurité.

Toujours dans la liste des coûts, même si dernièrement les éditeurs ont commencé à prendre le tournant linux, historiquement, les plateformes étaient avant tout composées de plateformes propriétaires (SUN et IBM) qui revenaient très cher à l’achat et à la maintenance.

Impacts d’autres équipes

Dernier coût mais pas des moindres, celui de l’impact des autres équipes d’exploitation dans le coût de la supervision. La supervision n’est pas magique. Il ne suffit pas de dire « mettez moi en place la supervision » pour avoir un résultat de qualité qui satisfera autant les responsables des applications que les clients. Les équipes supervision ne sont pas dans le contexte du client, et ne peuvent pas de fait inventer les supervisions à mettre en œuvre. Elles peuvent aussi se baser sur des templates, mais il faut que ces templates aient été créés par des personnes maîtrisant le sujet.

Que se passe-t-il quand on laisse des personnes qui ne maîtrisent pas le domaine mettre en œuvre la supervision sans les accompagner ? Deux choses bien souvent :

  • Soit on a une plateforme de supervision qui est trop « light », et des clients qui se plaignent que les incidents se produisent et que personne ne les remarque.
  • Soit on a une plateforme de supervision noyée sous les incidents, dans laquelle les équipes reçoivent des messages « polluants » qu’elles ne savent pas traiter. La console reste alors en permanence avec une centaine d’incidents pas importants, ce qui empêche toute réactivité sur incident.

Comme on peut le voir, l’équilibre n’est pas simple à mettre en œuvre, et seul un engagement des différentes équipes concernées ou l’appui de sociétés externes ayant de la maturité sur le sujet (et quand je parle de maturité, je ne parle pas de personnes qui se limitent à vous vendre la formation de leurs équipes, mais de réelles sociétés vous apportant de la valeur ajoutée avec des installations pré-packagées par exemple) vous permettra d’avoir un résultat de qualité.

Les équipes autres impactées sont donc nombreuses. Selon l’organisation, on peut citer : les personnes en charge des applications, les experts système, les experts réseau, les experts middleware…

(à suivre …. exemple)

livre blanc

Une analyse des coûts de la supervision [Partie 1]

Au travers de ce retour, nous lançons notre section de retours « à forte valeur ajoutée » pour nos clients. N’hésitez pas à nous faire part de vos remarques, elles sont bienvenues.

Définition: la supervision informatique

La « supervision informatique » pouvant désigner bien des choses, je pense qu’il est judicieux de préciser ce que j’entends par « supervision informatique » avant d’aller plus loin. Dans le cadre de cet article, La supervision informatique est traitée au sens large, incluant les diverses couches pouvant être supervisées, les différents outils pouvant être utilisés, l’hypervision et le reporting. Le schéma ci-dessous précise mon propos :

supervision global

Vue de la supervision au sens large

Donc quand je vous parle de supervision informatique, en terme d’outillage et de couverture, je fais référence au périmètre précisé ci-dessus. Mais là encore, ça n’est pas tout. Parler de supervision informatique, c’est aussi parler de processus, d’organisation, de ressources, et de prise en compte du contexte.

 supervision_perimetre

Périmètre de la supervision

Mon propos portera donc sur la globalité de ce périmètre, et vous apportera un éclairage selon l’angle que je jugerais pertinent à sa compréhension.

Coût de la Supervision

La supervision, ça coûte cher!

Cette phrase, j’ai dû l’entendre au moins une fois chez chacun des clients pour qui la supervision avait de l’importance.

Je mets de côté les entreprises où la disponibilité des applications n’est pas au cœur de l’activité, parce que bien souvent dans celles-ci la supervision est réalisée sur un coin de bureau (avec aucune ressource dédiée), avec un Nagios paramétré pour assurer le service minimum (et qui répond aux attentes). Je parle ici des entreprises où la supervision est un enjeu, quelle qu’en soit la raison :

  • La société rend un service à des clients exigeants,
  • La société doit rendre des comptes sur sa disponibilité à un organisme tiers,
  • L’indisponibilité de l’outil informatique a un impact direct sur le chiffre d’affaire de la société,

La supervision dans le cadre défini ci-dessus est évidemment un enjeu d’importance, mais elle est bien souvent perçue comme très/trop coûteuse. Le fait est qu’il est difficile d’évaluer le ratio apports/coûts de la supervision. Le but de cet article est de lister les « coûts/apports » de la supervision afin de vous aider à en maîtriser les enjeux.

Apports de la supervision

La supervision n’est pas un organe critique de la chaîne applicative de l’entreprise.

L’indisponibilité de la supervision n’entraîne pas de facto l’indisponibilité des applications. Elle est par contre un élément majeur de l’exploitation. Si l’on prend la définition de wikipedia : « L’exploitation informatique est l’activité qui consiste à maintenir opérationnel de manière stable, sûre et sécurisée un outil informatique dans un environnement de développement, de qualification, de formation, ou de production, dans ses parties matérielles et logicielles. »

Or comment peut-on imaginer maintenir un outil informatique si l’on n’est pas en capacité de connaître son état ? C’est là le rôle essentiel de la supervision. Et ce rôle essentiel est perçu différemment selon les attentes que portent les applications supervisées ; si l’indisponibilité de votre application, comme pour le cas d’un site marchand par exemple, entraîne une perte financière directe, vous avez tout intérêt à être réactif dans la résolution d’un incident afin de minimiser la perte. Ce ne sera pas forcément la même chose pour une application qui est utilisée 1 mois par an et qui ne présente pas d’impact financier.

Peut-on alors considérer cette « économie » comme un « gain » ?

Il y a peu encore, un responsable d’exploitation me disait : « mon meilleur outil de détection d’incidents, c’est mon client. Il sera toujours plus réactif que les outils de supervision à détecter un problème, parce que lui est en 24/7 devant sa console et qu’il m’avertit directement du moindre dysfonctionnement. » J’avoue que sur le moment sa remarque m’avait choqué, sans que j’ai le temps de lui formuler une réponse correcte afin de lui prouver ses torts. Et pourtant, la réponse était évidente ! bien sûr, le client est le premier à pouvoir détecter un incident, mais ça n’est pas suffisant, car ce qui intéresse réellement ce n’est pas de détecter un problème, mais c’est d’être en mesure d’en connaître la cause rapidement, afin de limiter l’indisponibilité. Au vu de la complexité des applications d’aujourd’hui, bâties sur de nombreuses couches et reposant sur des progiciels qui se complexifient d’année en année, rien n’est moins simple.

C’est la qu’intervient la supervision, qui non seulement est capable d’alerter sur un incident, mais permet aussi d’aller directement au cœur du problème, de pouvoir mobiliser au plus vite les bons intervenants et de limiter ainsi les temps d’indisponibilité.

La supervision, parce qu’elle permet d’identifier un incident de manière claire et précise permet donc de facto de réaliser des économies conséquentes sur les temps d’indisponibilité des applications.

Ces économies sont à mettre en face des besoins, car c’est là bien souvent qu’il y a mélange des genres. Bien que ce ne soit que rarement le message porté par les éditeurs (qui préfèreraient évidemment que vous investissiez dans toute leur suite sur tout votre périmètre), il n’existe pas une seule supervision mais bien des usages de la supervision, et tout comme vous n’apportez pas le même niveau d’engagement pour une production que pour une intégration, il n’y a pas de raison que vous apportiez le même niveau de supervision pour toutes vos applications. La supervision doit être elle aussi adaptable au contexte, aux besoins, aux impératifs clients.

La supervision est un ensemble de briques qu’il est possible de choisir et de paramétrer selon ses besoins. L’homogénéisation des supervisions mise en place est une contrainte plus souvent apportée par l’organisation interne et le souci d’industrialisation que par les solutions fournies par les éditeurs.

Les outils de supervision peuvent d’ailleurs aller très loin. Lorsque vous souhaitez définir des SLA pour une application, aujourd’hui, vous pouvez avec justesse faire reposer ces SLA sur des outils de type « robots » (ip-label newtest, BMC TMART, sikuli, …) plutôt que sur la capacité du client à remonter les indisponibilités (en mettant de côté celles qu’il aurait pu ne pas voir), ce qui met en avant un autre rôle dans la maîtrise du SI apporté par la supervision :

Elle permet de garantir un terrain neutre d’analyse de la disponibilité des applications entre les clients et l’exploitation informatique (rôle de « tiers de confiance »).

Donc, pour conclure cette section, la supervision peut être vectrice de gains financiers si elle est bien réalisée, elle doit être adaptée au besoin, et elle permet d’assurer un pont « neutre » entre l’exploitation et les clients.

(suite: coût de la supervision)

shinken_logo

Etude Shinken / Centreon

Dans le cadre d’une mission, j’ai souhaité mettre en avant un produit innovant afin de sortir du couple Nagios / Centreon. En effet, Out Of the Box, Les performances sur environnements virtualisés (VMWare) sont assez médiocres … (1500 checks / 5 min) avec une forte accumulation de maintenance.
J’ai donc déployé Shinken / Centreon avec les problèmes de compatibilité que cela allait supposer et qui étaient connus au moment de la décision.
Shinken est une ré-implémentation de Nagios en Python qui garde la rétro compatibilité avec Nagios, tout en introduisant un certain nombre de fonctionnalités, comme la découverte d’objets, des règles business, etc…

Avant le déploiement voici la liste des pour et des contre :

Les pour :

  • Équilibrage de charge
  • Haute disponibilité
  • Performant
  • Scalable
  • Rétro compatible Nagios
  • Fonctionne bien en environnement virtualisé
  • Codé en langage moderne (Python)

Les contre :

  • Compatibilité moyenne avec Centreon
  • Nécessite beaucoup de dépendances
  • Consomme de la mémoire

Maquette :

Le projet de migration d’un autre produit vers Shinken / Centreon (version 1.2.2) validé, j’ai entrepris de créer une maquette avec les cinq applications les plus importantes afin de me faire une idée concrète.
Globalement l’installation est simple et sans accroc grâce à un script complet qui installe l’ensemble des composants et des dépendances (très nombreuses et qui requièrent les droits root pour yum).
J’ai donc installé et configuré les serveurs suivants :

  • Centreon (8 Go de RAM) : Centreon ; Shinken- Arbiter ; Shinken-Scheduler ; Shinken-Broker ; Shinken-Receiver ; Shinken-Reactionner.
  • DB (8 Go de RAM): MySQL ; MongoDB (pour la rétention des états et la configuration de la WebUI de Shinken).
  • Poller1 (4 Go de RAM) : Shinken-Scheduler ; Shinken-Poller.
  • Poller2 (4 Go de RAM) : Shinken-Scheduler ; Shinken-Poller.

Premier point délicat, l’interfaçage avec Centreon. En effet, lorsque l’on vérifie la configuration, cela échoue car Shinken ne renvoie pas la bonne ligne à la fin de cette vérification. J’ai donc patché et mis en forme la sortie pour la rendre plus lisible.
Un second patch a été réalisé pour pouvoir utiliser les règles Business (autre avantage de Shinken) comme celles de Nagios BPA mais en plus évolué.

Montée en charge et problèmes rencontrés :

Au fur et à mesure de l’avancement du déploiement, je constate une forte montée en RAM due à une forte consommation de Shinken-Broker. Ce rôle étant primordial pour la visibilité (Logs, Livestatus, NDO, Gra- phiques, etc…), le fait que le processus soit tué par un manque de mémoire est relativement gênant.
De plus, deux versions bugfixes sont venues corriger des bugs importants (pour la génération de log et l’ordonnancement ainsi que pour les downtime) et en apporter d’autres.
Au niveau comportement des Pollers, l’utilisation d’agentless consomme beaucoup de ressources au niveau CPU et peu au niveau RAM.
La compatibilité entre Centreon et Shinken est aussi un facteur bloquant car il empêche de distribuer la charge sur plusieurs serveurs car dans la vision Centreon, un Poller représente les rôles d’Arbiter, Scheduler et Broker au minimum et comme ce dernier est le plus important pour dialoguer avec Centreon, il peut difficilement être séparé des autres.

Conclusion et direction prise :

La maquette a été réalisée sur un nombre peu important de services (env. 2300) et la consommation de mémoire était trop importante pour monter au delà. De plus, les deux versions bugfixes ont été sorties avec très peu de temps entre les deux car la 1.2.3 introduisait un bug critique.
Cette situation devenant plus que gênante, j’ai migré la maquette vers Nagios (avec sa RAM divisée par 2) et optimisé ma configuration et mon architecture pour supporter l’utilisation en environnement virtualisé avec les éléments suivants:

  • Utilisation de RAMDISKs.
  • Mettre en mémoire certaines tables NDO.
  • Utilisation de mod_gearman pour déléguer les exécutions des checks à des workers dédiés.

Au passage j’ai rajouté un Poller pour absorber la charge d’exécution et j’ai les indicateurs suivants:

  • Nombre d’hôtes: 630.
  • Nombre de services: 5069.
  • Latence: 0,4s.

Les serveurs Centreon et Nagios sont très peu chargés et avec des workers supplémentaires bien dimensionnés, il peuvent accueillir une charge bien plus grande.
G. LE BRIS