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

Question:

C’est quoi ?

Les services qui tournent sur les différentes machines génèrent des logs. Ce sont des messages expliquant ce que le service fait, ce qui tourne mal ou certaines opérations spéciales.

La collecte des logs permet de récupérer ces différents messages puis de les stocker dans une base de donnée centralisée permettant le traitement de ceux-ci.

Question:

Pourquoi faire ça ?

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é.

Question:

Comment on fait ça concrètement ?

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 :

  • 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)
  • technique/adminsys/monitoring/log.txt
  • de rdelaage