go right here xhamster
look at this web-sitebrowap.info

LMP : Maitriser la latence de ses satellites, en environnement distribué

Bonjour à tous,

Maitriser la latence de ses satellites Nagios peut vite devenir ardu, surtout lorsqu’on est amené à évoluer au sein de grosses implantations.

Pourtant, tout administrateur système se doit de la contenir, car une latence trop importante dégrade considérablement l’efficacité de la plateforme de supervision entière.

Je ne vais pas entrer ici dans les détails des impacts résultant d’une latence trop importante. Tout, ou presque, a déjà été écrit sur le sujet.

Néanmoins, en préambule, je me permettrais de dire ceci : bien (trop) souvent, je lis ici où là sur la toile des pseudos-analyses/expertises sur le meilleur moyen de combattre cette latence, qui ne correspondent pas à la réalité.

Alors … OUI, implémenter une solution de supervision à base de machines virtuelles peut poser problème (gestion des VCPUs, synchro ntp hasardeuse, …) …

OUI, l’utilisation du couple Nagios/NDOUtils est probablement moins performante que des forks tels que Shinken, Centreon Engine, etc …

Pour autant, il est tout a fait possible de mettre en oeuvre une architecture Centreon/Nagios distribuée de grande envergure, sans aucun problème.

Si je prends l’exemple du client Overmon chez qui j’évolue aujourd’hui (Télintrans, fournisseur du SI de Coliposte et Chronopost), Overmon fait tourner sans aucune latence plus de 10.000 services. Et pourtant, avec plus de 30% de sondes tournant en remote SSH vers des sites disposant d’un réseau faible, je vous assure que le contexte n’est pas simple … ;o)

Overmon_30102013_173523_006

L’architecture en place :

  • 1 OVS : 2 CPUs et 3 Go de RAM
  • 2 OVP : 4 CPUs et 8 Go de RAM

[hr]

Ce préambule étant terminé, rentrons dans le vif du sujet …

Pour maitriser la latence de sa plateforme, il est nécessaire de disposer :

  1. D’un indicateur fiable
  2. D’une méthode rigoureuse

Ceci est particulièrement important en environnement distribué, car une action donnant de bons résultat sur un poller peut très bien conduire à un écroulement des performances sur les autres pollers.

Autrement dit : autant il est aisé de disposer d’indicateurs fiables pour un simple poller, via des outils comme nagiostats, autant cela devient plus long à suivre, lorsqu’on a des dizaines de pollers à gérer.

Pour cette raison, Overmon dispose maintenant d’un indicateur cross-plateformes : le LMP (Latence Moyenne Pondérée)

Quézako ?

Le LMP est un indicateur permettant d’appréhender la latence globale de votre système, quelque soit le nombre de pollers (OVP)

Pour la latence des services actifs, par exemple, la formule utilisée est :

{ [ ( NbServicesPoller1 * AvgServiceLatencyPoller1 ) + ( NbHostsPoller1 * AvgHostsLatencyPoller1 )
    / ( NbServicesPoller1 + NbHostsPoller1 ) / 1000 ] + 
  [ ( NbServicesPoller2 * AvgServiceLatencyPoller2 ) + ( NbHostsPoller2 * AvgHostsLatencyPoller2 ) 
    / ( NbServicesPoller2 + NbHostsPoller2 ) / 1000 ] + 
  [ ( NbServicesPollerN * AvgServiceLatencyPollerN ) + ( NbHostsPollerN * AvgHostsLatencyPollerN ) 
    / ( NbServicesPollerN + NbHostsPollerN ) / 1000 ] / N }

Il est dorénavant inclus en standard dans les checks de l’OVS, et permet de suivre aisément la latence globale de sa plateforme :

Overmon_30102013_174626_007

Au moment ou j’ai pris ce screenshot, nous avions un problème de latence, situé au niveau de l’un des pollers (OVP2).

Et c’est là où ca devient intéressant : à partir du moment où nous disposons d’un tel indicateur, il est possible de mesurer à tout moment l’impact d’une modification de configuration de l’un des pollers, et ce, de facon globale.

Comment ? Tout simplement en notant au fur et à mesure les valeurs du LMP avant, et après chaque modification.

Il est évident que dans ce cadre, il faut s’interdire de mener deux modifications en parallèles, sans quoi, on ne sait plus quelle modification à entraine un changement de la valeur du LMP …

Concrètement, dans le cadre de ma mission actuelle, il m’a suffit de dérouler le plan d’action suivant :

Overmon_30102013_175144_008

pour arriver désormais à un LMP de 0.5 !!!

Overmon_30102013_175441_010

Cette fonctionnalité sera publiée dans la v8.2 de Overmon, prévue dans 1 mois.

Nous demanderons alors à l’ensemble de nos clients d’utiliser cet indicateur lorsqu’ils nous soumettrons des éventuels problèmes de performance.

A bientôt,

Sébastien SANCHEZ-GALLARDO

[br] [br] [hr]

 

Author: Sébastien Sanchez

Après avoir passé 20 ans dans des directions informatiques de groupes internationaux (Generali, Altadis, Chronopost) à exercer des fonctions variées (Manager de services IT, chef de projet MOE, Ingénieur systèmes, DBA, analyste programmeur, etc ...), j'ai créé Overmon. Overmon se propose de fournir à ses utilisateurs une solution complète de gestion de production IT, incluant une multitude de fonctionnalités telles que : supervision, inventaire, gestion d'incidents, et bien d'autres. Basé sur un socle open-source éprouvé (Nagios/Centreon/Glpi/FusionInventory/Mediawiki,...), Overmon permet de réduire considérablement la charge induite par certaines phases, telles que : Déploiement des agents de supervision et d'inventaire, déploiement/administration des satellites Nagios, développement de sondes spécifiques, supervision de bases de données et de sites web.

Share This Post On