Différences

Ci-dessous, les différences entre deux révisions de la page.

--- monitoring [2012/03/12 12:13] – [commun] cthuluh
+++ monitoring [2012/04/21 16:18] – [services] précision sur plusieur hosts gde
@@ Ligne 2: / Ligne 2: @@
 [[http://www.shinken-monitoring.org/|Shinken]] a été choisi comme outils de monitoring.
-Pour la métrologie, nous avons décider de reposer sur une interface à rrdtool, [[http://www.pnp4nagios.org/|pnp4nagios]] peut être un bon candidat
+Pour la métrologie, nous avons décidé de reposer sur une interface à rrdtool. Nous nous baserons sur [[http://www.pnp4nagios.org/|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 :
+<code>
+/usr/local/shinken/install -p nagios-plugins
+</code>
+===== PNP4nagios =====
+Pour faire nos graph, nous allons reposer sur pnp4nagios. Voici comment l'installer avec shinken
+<code>
+/usr/local/shinken/install -p pnp4nagios
+</code>
+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// :
+<code>
+# Use PNP graphs in the WebUI
+define module{
+  module_name    PNP_UI
+  module_type    pnp_webui
+  uri            http://shinken.faimaison.net/pnp4nagios/
+}
+</code>
 ===== Configuration =====
@@ Ligne 10: / Ligne 52: @@
 Chaque serveur Faimaison est monitoré sur les points suivant :
-  * **load** : load average
+  * **[[monitoring/load|load]]** : load average
-  * **CPU** : utilisation cpu (tout ce qui est non-idle)
+  * **[[monitoring/cpu|CPU]]** : récupération des différents état d'un cpu (idle, user, iowait, etc)
-  * **réseau** : débit des interfaces
+  * **[[monitoring/reseau|réseau]]** : débit des interfaces
   * **ram** & **swap** : utilisation de la ram et swap
-  * **disk** : espace disque de chaque partition
+  * **[[monitoring/disk|disk]]** : espace disque de chaque partition
+  * **ntp** : vérifie décalage par rapport à un server ntp donné
 ==== services ====
-En dehors du commun, de manière spécifique nous monitorerons quelques services :
+Services à monitorer :
-  * **http** : pour le site
+  * **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 ?
-==== Passive checks ====
+===== chomsky =====
-On évite d'utiliser les actives checks. On install donc sur chaque machine un daemon NSCA qui s'occupe de récupérer chaque mesure et de l'envoyer les résultat au serveur shinken.
+  * **GIT** : accès aux dépôts git (read-only)
-Celui-ci s'occupera d'analyser les résultats et de les stocker dans les rrd correspondant
+===== 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 **FIXME**|
+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.
+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 :
+<code>
+/usr/local/shinken/install -b
+</code>
+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 :
+<code>
+/usr/local/shinken/install -l
+</code>
+===== 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.