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/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
