Bonjour. Je suis un peu étonné de vos différentes conclusions sur Prometheus. Je gère actuellement un architecture Prometheus de 10 serveurs prometheus (2 par DC + 2 Fédération). Cette stack collecte plus de 500k métriques chaque minutes et garde un historique de 90 jours. Les métriques proviennent de environs 230 instances AWS EC2, 2 cluster K8S, Cloudwatch et un certains nombre de service (Mysql, Mongo, Redis, etc..)
[image: Capture d’écran 2020-06-10 à 12.27.30.jpg] - Chaque API / APP fournit des métriques - A chaque déploiement les dev peuvent mettre à jour leurs métriques métier - L'alerting est aux petits oignons avec un CI/CD dédié permettant au dev de créer leur propre alerte sûr leur métrique métier. - L'alerting comporte des règles sur le business (drop de vente, nb de panier abandonnés, baisse de recherche dans le moteur etc) - Chaque squad reçois les alertes sur son channel slack - L'infra et le business ont en plus des alerts pager duty Pour l'archivage ou la rétention longue duré il existe différente solution que nous n'utilisons pas. La solution qui monte est https://thanos.io Nous pensons créé un service d'extraction de quelques métriques via l'API prometheus afin d'archivage sous forme de fichier csv (github est pleins de piste pour cela) Bref pour l'aspect monitoring Prometheus me semble un outil adapté. Karles https://twitter.com/Karlesnine Le mer. 10 juin 2020 à 11:27, Wallace <wall...@morkitu.org> a écrit : > Merci Philippe et Raphael, je pense en effet que le KISS du syslog à > l'ancienne me parait une bonne solution notamment pour l'archivage > légal, j'avais pas pensé à renvoyé une autre fois vers un autre > composant, ça me parait évident maintenant. > > Le stockage de prometheus clairement non, au delà de 24h pour 25 > machines de test c'est déjà des centaines de gigas, aucun mécanisme de > compression et réduction disponible, c'est pas envisageable. > > On a essayé Victoria et on part pour le moment dessus car ils promettent > la réduction sous peu mais ça ne tiendra pas la prod en l'état c'est > évident. > > A mon avis on va simplifier la première version de la nouvelle > supervision, se limiter à 48h max, garder les logs syslog centralisés et > tester en second palier toutes les bases de stockage et leurs évolutions. > > Dernières questions car du coup si je reste sur du syslog faut que je > redescende une problématique que devait régler la nouvelle supervision. > > Comment vous rendez vos syslog hautement disponible pour parer à une > coupure réseau d'un cloud par exemple? Vous envoyez chaque source sur > deux syslogs sur deux réseaux différents (donc double stockage) ou y a > des astuces pour faire une sorte de cluster actif actif? > > Et n'ayant pas regarder on peut scaler horizontalement derrière des LB > des syslogs en tcp tout en écrivant dans les mêmes fichiers (peut être > avec du sticky)? > > Encore merci > > > _______________________________________________ > Liste de diffusion du FRsAG > http://www.frsag.org/ > -- Charles-Christian Croix
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
