Différences

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

--- sysadmin [2020/01/31 17:07] – [Surveillance système] lpieri
+++ sysadmin [2020/01/31 17:36] – lpieri
@@ Ligne 12: / Ligne 12: @@
   * Modifier/Créer le fichier **.ssh/authorized_keys** depuis le répertoire personnel du nouvel utilisateur et ajouter une clé ssh publique pour pouvoir se connecter en tant que ce nouvel utilisateur.
-Plusieurs clés peuvent être ajoutées dans le fichier authorized_keys, il suffit des les ajouter à la fin du fichier.
+Plusieurs clés peuvent être ajoutées dans le fichier authorized_keys, il suffit de les ajouter à la fin du fichier.
 ====== Surveillance système ======
@@ Ligne 18: / Ligne 18: @@
 La surveillance système est un processus qui consiste en la vérification périodique du bon fonctionnement de tous les composants des serveurs hébergeant les différents applicatifs logiciels.
-Ce processus a été mise en place à la suite d'un erreur liée à l'espace disque insuffisant qui a entraîné un interruption de plusieurs minutes du serveur de développement. Pour prévoir les futures erreurs, nous avions besoin d'une solution capable de surveiller le serveur (charge du système, espace disque restant...) et d'alarmes qui déclencheraient des notifications en cas dépassement de seuils pré-configurés.
+Ce processus a été mis en place à la suite d'une erreur liée à l'espace disque insuffisant qui a entraîné une interruption de plusieurs minutes du serveur de développement. Pour prévoir les futures erreurs, nous avions besoin d'une solution capable de surveiller le serveur (charge du système, espace disque restant...) et d'alarmes qui déclencheraient des notifications en cas dépassement de seuils pré-configurés.
-La surveillance système est composé de trois outils complémentaires :
+La surveillance système est composée de trois outils complémentaires :
   * L'outil qui va chercher les données du serveur
   * L'outil qui va formater les données et le rendre disponible
@@ Ligne 31: / Ligne 31: @@
 **Une Time Series DataBase est une base de données optimisée pour le stockage de données horodatées**
-C'est l'outil qui va stocker les information que l'on souhaite récolter à propos du serveur et les mettre à disposition pour d'autres outils.
+C'est l'outil qui va stocker les informations que l'on souhaite récolter à propos du serveur et les mettre à disposition pour d'autres outils.
 {{:what-does-prometheus-do-1024x610.png?800|}}
@@ Ligne 87: / Ligne 87: @@
 ===== Gestion des utilisateurs =====
-Lors de l'installation de Grafana, par sécurité, l'inscription d'utilisateurs externes a été désactivée. Seuls les administrateur peuvent ajouter de nouveaux utilisateurs. Et seuls des utilisateurs inscrit peuvent accéder à Grafana.
+Lors de l'installation de Grafana, par sécurité, l'inscription d'utilisateurs externes a été désactivée. Seuls les administrateurs peuvent ajouter de nouveaux utilisateurs. Et seuls des utilisateurs inscrit peuvent accéder à Grafana.
 L'administration au sein de Grafana est construite de la manière suivante :
@@ Ligne 100: / Ligne 100: @@
   * Les permissions qui lui sont attribuées directement
   * Toutes les permissions si il est **Grafana Admin**
+===== Gestion des alarmes =====
+Comme expliqué plus haut, les alarmes sont gérées par AlertManager.
+AlertManager récupère les alertes remontées par Prometheus et les dispatche aux personnes concernées. Il est aussi capable de mettre en silence certaines alertes et d'en regrouper d'autres pour ne pas inonder les boites de réception. Par exemple : l’hébergeur subit une coupure d’électricité, toutes les instances ne fonctionnent plus. Si une alerte doit être déclenchée à chaque fois qu'une instance n'est plus accessible, alors Alermanager n'enverra qu'un e-mail indiquant toutes les instances inaccessibles.
+[[https://blog.debugo.fr/tuto-monitoring-prometheus-partie-4-alertmanager/|Installation et configuration d'AlertManager]]
+Le fichier de configuration global d'AlertManager se trouve **/etc/alertmanager/alertmabager.yml**, il contient :
+  * les informations de connexions au serveur smtp
+  * la liste des destinataires des alertes
+  * la configuration du silence et du regroupement des alertes
+La configuration des alertes en elle-mêmes est rédigée dans le dossier **/etc/prometheus/alerting_rules/*_rule.yml**. La convention veut que les fichiers des règles portent le nom du groupe auxquels ils appartiennent puis **_rule.yml**.
+Dans ces fichiers sera décrit :
+  * le groupe
+  * le nom de l'alerte
+  * la requête prometheus qui va identifier le comportement déclenchant l'alerte
+  * le temps avant que l'alerte soit déclenchée
+  * un label pour identifier la sévérité de l'alerte (page, warning, high, critical...)
+  * un sommaire et une description : c'est ce qu'on retrouvera dans la notification
+Plusieurs alertes peuvent-être configurées dans un même fichier, à condition qu'elles fassent partie du même groupe.
+alertes ont déjà été configurées :
+  * une alerte si le serveur dev n'est plus accessible pendant plus d'une minute.
+  * une alerte si le disque du serveur dev possède moins de 5% de capacité libre pendant plus de une minute.
+**Attention !** A chaque de fois qu'un fichier d'alerte est créé, il faut vérifier :
+  * que les droits du fichier sont prometheus:prometheus
+  * que le fichier est correctement construit avec la commande **promtool check rules path/to/the/rule**
+  * relancer prometheus avec **sudo systemctl restart prometheus**