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.
Exploitation
emplacements
de manière générale, pour la configuration tous ce trouve dans /usr/local/shinken/etc/ .
Et pour les plugin il faut aller dans /usr/local/shinken/libexec . C'est à cette endroit qu'en définit
nom | chemin absolu | commentaires |
---|---|---|
définition des hosts | /usr/local/shinken/etc/hosts/ | créer un fichier par machines |
déclaration des services | /usr/local/shinken/etc/services.cfg | |
emplacements des templates pour hosts | /usr/local/shinken/etc/packs/ |
ajout d'un host
Pour ajouter un host :
define host{ use generic-host, dns, smtp, ssh, http contact_groups admins host_name <nom host pour interface> address <adresse ip ou dns> icon_set server }
- use : permet d'utiliser des templates d'hosts
- contact_groups : permet de définir les groupes de contacts tels définit
- host_name : nom à faire apparaitre (pour l'interface web surtout)
- address : indispensable pour joindre la machine.
- icon_set : l'icon a utiliser pour l'interface web
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.