Différences

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

--- monitoring [2012/03/24 17:23] – quelques liens ajouté pour du load gde
+++ monitoring [2012/03/25 13:22] – [Passive checks] ajout bla bla sur active checks gde
@@ Ligne 4: / Ligne 4: @@
 Pour la métrologie, nous avons décidé de reposer sur une interface à rrdtool, [[http://www.pnp4nagios.org/|pnp4nagios]] peut être un bon candidat
-===== plugin nagions =====
+===== plugin nagios =====
 afin de garder une consistence entre chacun de nos outils, et mieux maitriser notre techno. nous allons developpez nos propre plugin nagios.
-Sur le choix de la technologie employé, nos allons resté sur du python.
+Sur le choix de la technologie employé, nos allons resté sur du python quand on doit les écrire. Autrement, nous utiliserons les plugins qui viennent par défaut avec shinken
 ===== Configuration =====
@@ Ligne 32: / Ligne 32: @@
   * **GIT+SSH** : accès aux dépôts git
   * **GIT** : accès aux dépôts git (read-only)
-==== Passive checks ====
+==== Active et Passive checks ====
-On évitera d'utiliser des test actifs (actives checks). On installera donc sur chaque machine un démon NSCA qui s'occupera de récupérer chaque mesure et d'envoyer les résultat au serveur Shinken.
+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).
-Celui-ci s'occupera d'analyser les résultats et de stocker les données de performances grâce à RRDtool.
+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.
+===== 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 ///opt/backup/shinken//
+==== lister le backup ====
+pour voir toutes les backup faites :
+<code>
+/usr/local/shinken/install -l
+</code>