technique:adminsys:monitoring:log

Différences

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

Lien vers cette vue comparative

Prochaine révision		 Révision précédente
technique:adminsys:monitoring:log [2022/09/20 16:44] – créée rdelaagetechnique:adminsys:monitoring:log [2022/09/22 08:58] (Version actuelle) – [Comment query les logs dans Loki ?] rdelaage
Ligne 1: Ligne 1:
 # Collecte et centralisation des logs # Collecte et centralisation des logs
 +
 +Actuellement on a rien de particulier pour gérer nos logs, tout est laissé par défaut et quand on a besoin d'exploiter les logs (debug, investigation, pour des raisons légales, ...) on va chercher à coup de grep quand on est sur du docker ou de journalctl quand c'est un service systemd
 +
 +On aurait besoin de quelque chose qui nous permette de :
 +
 +  * Faire de la rotation
 +  * Définir la politique de rétention des logs pour être OK avec les textes réglementaires
 +  * Faire de l'analyse de nos logs au moins aussi bien qu'avec nos greps
 +  * Cerise sur le gâteau automatiser l'analyse de certains problèmes (ex: rejets sur le serveur mail)
 +
 +Pour le monitoring, notre stack comprend victoriametrics, blackbox, alertmanager, grafana
  
 <bootnote question>C'est quoi ?</bootnote> <bootnote question>C'est quoi ?</bootnote>
Ligne 8: Ligne 19:
  
 <bootnote question>Pourquoi faire ça ?</bootnote> <bootnote question>Pourquoi faire ça ?</bootnote>
 +
 +Sans système de collecte des logs, les logs sont écrits dans des fichiers et faire de l'analyse, gérer la rotation, ... sont des tâches plutôt fastidieuses. La collecte permet de rediriger ses fichiers dans une base de donnée qui gère elle-même la rotation et permet de faire de l'analyse à l'aide de requêtes comme dans une BDD SQL !
 +
 +On peut même configurer des alertes si certains logs arrivent, autrement dit ça fait le café.
  
 <bootnote question>Comment on fait ça concrètement ?</bootnote> <bootnote question>Comment on fait ça concrètement ?</bootnote>
 +
 +On commence par mettre en place la base de données, dans notre cas Loki. Puis on configure des agents sur les différentes machines dont le but est de récupérer les logs des services puis de les renvoyer sur la base de données centralisée (promtail).
 +
 +Enfin on configure Grafana avec comme source d'entrée Loki pour nous afficher les logs et différentes statistiques concernant ces logs.
 +
 +On peut aussi configurer alertmanager afin de nous envoyer des alertes si on voit une activité anormale par exemple.
 +
 +En vrac :
 +  * Docker-compose minimal d'exemple https://wiki.picasoft.net/doku.php?id=technique:adminsys:monitoring:log
 +  * Notre infra est plutôt proche de l'infra cible de Loki
 +  * Loki est la TSDB
 +  * Promtail est l'agent qui envoie les logs vers Loki
 +  * L'analyse des logs se fait via des requêtes en LogQL
 +  * On peut faire des jolis dashboard sur nos logs
 +  * Traitement des logs à posteriori -> meilleures perfs
 +  * utiliser service + host en label pour éviter de faire exploser la cardinalité
 +  * les graphes ne représente qu'une agrégation de logs à des instants t (glissant)
 +  * Loki a tout ce qu'il faut pour gérer sa propre db → config locale
 +  * On peut perdre des logs : par défaut, l'agent conserve ~10min de logs  s'il arrive pas à les envoyer (0.5s pour le premier retry, puis x2, 10fois)
 +  * RTFM https://grafana.com/docs/loki/latest/installation/
 +
  • technique/adminsys/monitoring/log.1663685047.txt.gz
  • de rdelaage