Arrêt de nos frontaux lié au logging Fluentd
Le symptôme est simple : plusieurs fois par jour depuis jeudi, nos serveurs tombent, avec tous leurs services. D'abord joke à plusieurs reprises, nous avons donc migré les services cruciaux sur helvet. Puis helvet aujourd'hui ainsi que joke, excluant le défaut matériel et le lien avec un service qui fait défaut en particulier.
Côté administration, il semble d'abord impossible d'utiliser le démon Docker : redémarrer notre frontal timeout.
docker-compose restart traefik
Restarting front_traefik_1 ...
ERROR: for front_traefik_1 UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=70)
ERROR: An HTTP request took too long to complete. Retry with --verbose to obtain debug information.
If you encounter this issue regularly because of slow network conditions, consider setting COMPOSE_HTTP_TIMEOUT to a higher value (current value: 60).
Toute opération sur ce conteneur timeout. Une analyse un peu plus fine montre que seul ce conteneur est impacté dans les cas étudiés. Rapidement, les statistiques montrent que les heures de plantage correspondent à d'importants volumes de logs :
De même, les transferts réseau des conteneurs fluentd de l'hôte impacté et Loki explosent au moment du plantage :
Contexte : cette semaine, pour améliorer la qualité de notre journalisation, en particulier pour pré-parser les logs et externaliser une copie de certains logs pour la traçabilité des actions d'administration, nous avons déployé une infrastructure basée sur Fluentd.
Le concept est le suivant : (Docker || logs système) => (fluentd local) => (fichiers exportés || Loki pour consultation).
Conclusion pour le moment : un processus génère une quantité importante de journaux, fluentd est saturé, le démon Docker ne peut plus écrire sur son socket (unix) et bloque le conteneur. L'interprétation devient vague à ce stade, une piste : ne pouvant plus enregistrer les logs, le démon bloque les appels d'écriture fichier sur les fd de sortie du processus traefik, qui refuse alors de fonctionner (à confirmer) ; en parallèle, le démon Docker ne traite plus aucune requête pour le conteneur en question.