technique:adminsys:monitoring:start

Monitoring de l'infrastructure

Dans le but de surveiller l’activité de l’infrastructure, il a été décidé de mettre en place une infrastructure de monitoring. Il existe plusieurs manières de faire du monitoring :

  • collecter des informations sur l’état des serveurs (Est-ce que les machine sont connectées au réseau ? Le CPU est il surchargé ?, etc.)
  • collecter des informations sur les services (temps de réponse d’une application par exemple)
  • collecter des données sur l’utilisation des services (nombre de comptes, personnes connectées, etc.)
  • collecter des données sur les erreurs qui surviennent sur les machines (messages de logs système)
  • collecter des données sur les erreurs qui surviennent dans l’exécution des services (messages de logs des services)

Note:

Cette section détaille le fonctionnement de tous les outils utilisés pour le monitoring, mais les pages n’ont pas beaucoup d’intérêt sans vision d’ensemble. Voir cette page qui récapitule l’infrastructure mise en place chez Picasoft.

Bien entendu, tout ceci est complémentaire. Chaque type de données listé ici permet de fournir des informations d’un type particulier sur l’infrastructure. C’est la combinaison de tout ou partie de ces données qui forme le monitoring.

Comme ces données sont de types différents, les manières de les collecter, analyser et restituer sont différentes.

Note:

À ce jour, de nombreux essais (en particulier des TX en P17 et P20) de mettre en place une solution de logging ont été menés à Picasoft. Cependant aucune solution n’a pour le moment été réellement déployée et mise en utilisation.

La métrologie consiste à mesurer l’infrastructure. Tout ce qui joue le rôle de sonde et qui permet d’enregistrer les mesures effectuées rentre dans la catégorie « métrologie ».

L’alerting, ou supervision, est la partie du monitoring qui se charge d’évaluer des règles à intervalles réguliers pour détecter des situations que l’on considère comme problématiques (disque plein, CPU trop élevé, trop de code d’erreurs HTTP, etc). Quand une règle est évaluée positivement, le système d’alerte décide que faire. En général, il s’agit de transmettre l’information à l’équipe technique en étant le plus parcimonieux possible pour ne pas surcharger. Le détail est proposé dans la section dédiée.

  • technique/adminsys/monitoring/start.txt
  • de qduchemi