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/
