[FRsAG] Syslog et Prometheus

Raphael Mazelier raph at futomaki.net
Mer 10 Juin 10:27:15 CEST 2020


Bonjour;

Gros sujet.

Coté métriques le couple prometheus/grafana semble avoir gagné 
temporairement la partie.  Ceci étant cela ne vient pas sans challenge.

Prometheus est très efficace mais il ne gère pas le downsampling et le 
stockage long terme out of the box.

Il existe plein de solutions pour palier ces défauts : voir coté cortex, 
victoriaMetrics, etc... Il est donc maintenant possible d'avoir une 
rétention longue (voir par exemple l'article d'un ex collègue sur la 
question : 
https://medium.com/@IG1.com/sismology-iguana-solutions-monitoring-system-f46e4170447f 
.

L'alerting basé sur Prometheus est aussi assez tricky à mettre en place 
(long sujet aussi).

Coté log je partirais sur une approche mixte. Loki semble très 
intéressant pour corréler les logs avec prometheus. Je choisirais donc 
un shipper générique (fluentbit, rsyslog) qui enverrait vers un 
plateforme centrale d'ingestion de logs (avec buffering, kafka ou 
autre), et un processeur de log qui pourrait envoyer vers diverses 
destinations : loki, E(L)K (ou graylog) et une plateforme d'archivage flat.

En revanche il ne faut pas se leurrer une architecture de métriques et 
de logs coûte cher, mais ce n'est pas la dessus que je ferais des économies.

--

Raphael Mazelier


On 09/06/2020 18:49, Wallace wrote:
> Bonjour à tous,
>
> On arrive pas à se décider sur le choix de stockage de logs et de
> métrique dans le cadre de la centralisation de logs syslog et des
> métriques récupérée par Prometheus.
>
> Le contexte est plusieurs centaines de systèmes (99% Debian, 1% autre
> (BSD, appliance).
>
> Jusqu'à présent on avait un serveur syslog qui enregistrait pour
> l'archivage légal et décentralisé les logs des serveurs avec rotation et
> tout ce qui va bien.
>
> Dans le cadre de la mise en place de Prometheus comme nouvelle
> supervision, on voit clairement l'intérêt de venir chercher des éléments
> dans les logs pour faire de la remontée de métrique additionnel en plus
> des exporters.
>
> L'idée est d'aller vers un Prometheus, Grafana et Loki mais en ayant
> testé différentes bases de stockage métrique et logs on se rend compte
> que la place occupée et les ressources pour gérer tout cela sont plus
> que conséquentes.
>
> On s'oriente vers un découpage pour les logs et métrique long terme et
> ceux à exploiter sur une période < 1 semaine mais ça parait lourd comme
> organisation et loin du KISS avec les risques de perte de donnée.
>
> Ce que j'aimerais dans l'idéal :
>
> - partie log exploitation non compressée sur une période de quelques
> jours pour corréler avec les métriques, par la suite c'est compressé et
> archivé avec éventuellement la possibilité d'aller revoir un évènement
> en arrière
>
> - partie métrique avoir toutes les métriques sur quelques heures, 24h
> max, puis façon rrdtool supprimer les métriques en faisant une moyenne
> et/ou min/max sur des périodes de 5 min puis 15 ... Là pas de retour
> arrière ce qui est supprimé est définitif.
>
> En mode métrologie si on détecte à postériori un changement de tendance
> même sur une moyenne, pouvoir réouvrir les logs associés à cet espace de
> temps nous parait important.
>
> Et vous vous utilisez quoi comme base de donnée de stockage pour les
> métriques Prometheus et pour l'exploitation des logs sans faire exploser
> les serveurs avec des To de données?
>
> Bonne fin de journée
>
>
> _______________________________________________
> Liste de diffusion du FRsAG
> http://www.frsag.org/


Plus d'informations sur la liste de diffusion FRsAG