Outils pour utilisateurs

Outils du site


monitoring

Différences

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

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision
Révision précédente
Prochaine révisionLes deux révisions suivantes
monitoring [2012/03/25 12:37] – [plugin nagions] c'est nagios gdemonitoring [2012/03/25 13:37] – logs shinken gde
Ligne 32: Ligne 32:
   * **GIT+SSH** : accès aux dépôts git   * **GIT+SSH** : accès aux dépôts git
   * **GIT** : accès aux dépôts git (read-only)   * **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é ===== ===== 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 ///opt/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.
 +
 +
  
  
  
monitoring.txt · Dernière modification : 2019/11/28 08:47 de gde