Table des matières
Ceci est une ancienne révision du document !
Monitoring & Métrologie
Shinken a été choisi comme outils de monitoring. Pour la métrologie, nous avons décidé de reposer sur une interface à rrdtool. Nous nous baserons sur pnp4nagios
plugin
Nous utiliserons les plugins qui viennent par défaut avec shinken, ou les plugin nagios.
nagios-plugin
pour installer tous les plugins déjà créé par la communauté, il suffit de faire :
/usr/local/shinken/install -p nagios-plugins
PNP4nagios
Pour faire nos graph, nous allons reposer sur pnp4nagios. Voici comment l'installer avec shinken
/usr/local/shinken/install -p pnp4nagios
la configuration est quasiment faites. Les hosts et les services seront automatiquement installé.
Configuration
La configuration consiste surtout à intégrer les graphs de pnp4nagios dans la webUI de shinken.
pour se faire il faut éditer le fichier /usr/local/shinken/etc/shinken-specific.cfg :
# Use PNP graphs in the WebUI define module{ module_name PNP_UI module_type pnp_webui uri http://shinken.faimaison.net/pnp4nagios/ }
Configuration
commun
Chaque serveur Faimaison est monitoré sur les points suivant :
services
Services à monitorer :
- SSH : vérifier la disponibilitée du port 22
unique pour les hosts
methyl_box
- HTTP : pour le site (test port 80 + parse page index)
- DNS : résolution de nom de faimaison.net
- Postgresql : vérifier le port 5432 ?
chomsky
- GIT : accès aux dépôts git (read-only)
zorun_box
- GIT : accès aux dépôts git (read-only)
Active et Passive checks
Différent type de récupération des données peuvent être faites. nous pouvons sois demander au serveur monitoré d'envoyer de lui-même ces propre tests sur un intervalle défini (passive checks) ou alors shinken peut interroger le serveur à intervalle régulier (active checks).
Il existe plusieurs méthode pour réaliser des active checks.
type de check | description |
---|---|
check_by_ssh | execute une commande distante par ssh |
nrpe | protocole particulier qui va interroger le serveur avec un agent |
check_mk | comme nrpe mais en plus efficace |
De manière générale, il faut éviter les connexion inutile. Le principe de check passif est interessant mais demande à mettre à jour chaque serveurs si une modification commune doit être faite. nrpe et check_mk centralise la chose sur le serveur shinken, et pourrait être plus simple à gérer dans le cadre de l'association.
Haute Disponibilité
En cas d'indisponibilité du serveur principal, un spare peut prendre le relais. Mais ceci reste à définir.
Backup
Shinken dispose de son propre système de backup. Ce qui est sauvegardé n'est que les fichiers plat de configuration. Pour cela faire la commande suivante :
/usr/local/shinken/install -b
Par défaut, les sauvegardes sont faites dans le répertoire /opt/backup. Pour l'isoler d'autre backup nous préciserons le le mettre dans /home/backup/shinken
lister le backup
pour voir toutes les backup faites :
/usr/local/shinken/install -l
logs
shinken s'occupe lui-même de la rotation de ses logs. Celle-ci sont programmé pour se faire tous les jours par défaut.