[FRsAG] Syslog et Prometheus

Wallace wallace at morkitu.org
Mer 10 Juin 15:01:25 CEST 2020


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 <wallace at morkitu.org
> <mailto:wallace at 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/
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://www.frsag.org/pipermail/frsag/attachments/20200610/4bf62760/attachment-0001.htm>
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: Capture d?e?cran 2020-06-10 a? 12.27.30.jpg
Type: image/jpeg
Taille: 17091 octets
Desc: non disponible
URL: <http://www.frsag.org/pipermail/frsag/attachments/20200610/4bf62760/attachment-0001.jpg>


Plus d'informations sur la liste de diffusion FRsAG