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’écran 2020-06-10 à 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 <wallace@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/