Bonjour, Retour intéressant, quel poids pèse tes métriques stockées sur Prometheus?
Tu les stockes localement sur les edges ou sur ceux fédérant? Merci Le 10/06/2020 à 12:39, Charles-Christian Croix a écrit : > > 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..) > > 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 > <mailto: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/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
