{"id":53590,"date":"2019-12-05T00:00:00","date_gmt":"2019-12-04T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/kak-my-v-tsian-ukroshhali-terabajty-logov"},"modified":"2020-02-18T14:01:30","modified_gmt":"2020-02-18T11:01:30","slug":"kak-my-v-tsian-ukroshhali-terabajty-logov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/kak-my-v-tsian-ukroshhali-terabajty-logov","title":{"rendered":"Comment nous, \u00e0 CIAN, avons apprivois\u00e9 des t\u00e9raoctets de logs","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Comment
\n
\nBonjour \u00e0 tous, je m'appelle Alexandre, je travaille chez CIAN en tant qu'ing\u00e9nieur et je m'occupe de l'administration syst\u00e8me et de l'automatisation des processus d'infrastructure. Dans les commentaires d'un de nos anciens articles, on nous a demand\u00e9 de parler de l'origine des 4 To de logs que nous g\u00e9n\u00e9rons chaque jour et de leur traitement. Oui, nous avons beaucoup de logs, et un cluster d'infrastructure sp\u00e9cifique a \u00e9t\u00e9 mis en place pour les traiter, ce qui nous permet de r\u00e9soudre rapidement les probl\u00e8mes. Dans cet article, je vais expliquer comment, en un an, nous avons adapt\u00e9 ce syst\u00e8me pour g\u00e9rer un flux de donn\u00e9es en constante augmentation.
\n<\/a><\/noindex><\/p>\n

Par quoi nous avons commenc\u00e9<\/h3>\n

\n\"Comment
\n
\nAu cours des derni\u00e8res ann\u00e9es, la charge sur cian.ru a augment\u00e9 tr\u00e8s rapidement, et au troisi\u00e8me trimestre 2018, le site a atteint 11,2 millions d'utilisateurs uniques par mois. \u00c0 cette \u00e9poque, lors des moments critiques, nous perdions jusqu'\u00e0 40 % des logs, ce qui nous emp\u00eachait de r\u00e9soudre rapidement les incidents et nous faisait perdre beaucoup de temps et d'efforts pour y faire face. Nous avions \u00e9galement souvent du mal \u00e0 identifier la cause des probl\u00e8mes, qui r\u00e9apparaissait apr\u00e8s un certain temps. C'\u00e9tait l'enfer, et il fallait faire quelque chose.<\/p>\n

\u00c0 ce moment-l\u00e0, nous utilisions un cluster de 10 n\u0153uds de donn\u00e9es avec ElasticSearch version 5.5.2 avec des param\u00e8tres d'indexation standards pour le stockage des logs. Il a \u00e9t\u00e9 mis en place il y a plus d'un an en tant que solution populaire et accessible : \u00e0 l'\u00e9poque, le flux de logs n'\u00e9tait pas si important, il n'y avait pas de raison d'inventer des configurations non standard.\u00a0<\/p>\n

Le traitement des logs entrants \u00e9tait assur\u00e9 par Logstash sur diff\u00e9rents ports sur cinq coordinateurs ElasticSearch. Un index, quelle que soit sa taille, se composait de cinq shards. Une rotation horaire et quotidienne a \u00e9t\u00e9 organis\u00e9e, r\u00e9sultant en environ 100 nouveaux shards dans le cluster chaque heure. Tant que le volume de logs n'\u00e9tait pas trop important, le cluster fonctionnait bien et personne ne se pr\u00e9occupait de ses param\u00e8tres.\u00a0<\/p>\n

Probl\u00e8mes de croissance rapide<\/h3>\n

\nLe volume de logs g\u00e9n\u00e9r\u00e9s a connu une croissance tr\u00e8s rapide, car deux processus se chevauchaient. D'une part, le nombre d'utilisateurs du service augmentait. D'autre part, nous avons commenc\u00e9 \u00e0 adopter activement une architecture microservices, en d\u00e9composant nos anciens monolithes en C# et Python. Plusieurs dizaines de nouveaux microservices rempla\u00e7ant des parties du monolithe g\u00e9n\u00e9raient beaucoup plus de logs pour le cluster d'infrastructure.\u00a0<\/p>\n

C'est pr\u00e9cis\u00e9ment l'\u00e9chelle qui nous a amen\u00e9s \u00e0 rendre le cluster pratiquement ing\u00e9rable. Lorsque les logs ont commenc\u00e9 \u00e0 arriver \u00e0 un rythme de 20 000 messages par seconde, une rotation fr\u00e9quente et inutile a augment\u00e9 le nombre de shards \u00e0 6 000, et il y avait plus de 600 shards pour un n\u0153ud.\u00a0<\/p>\n

Cela a entra\u00een\u00e9 des probl\u00e8mes de m\u00e9moire vive, et lors de la chute d'un n\u0153ud, le d\u00e9placement simultan\u00e9 de tous les shards a multipli\u00e9 le trafic et charg\u00e9 les autres n\u0153uds, rendant pratiquement impossible l'enregistrement des donn\u00e9es dans le cluster. Pendant cette p\u00e9riode, nous \u00e9tions sans logs. En cas de probl\u00e8me avec serveur<\/a> nous perdions en fait 1\/10 du cluster. Un grand nombre d'index de petite taille compliquait encore les choses.<\/p>\n

Sans logs, nous ne comprenions pas les causes de l'incident et risquions de tomber \u00e0 nouveau dans les m\u00eames pi\u00e8ges, ce qui \u00e9tait inacceptable selon l'id\u00e9ologie de notre \u00e9quipe, car tous nos m\u00e9canismes de travail visent pr\u00e9cis\u00e9ment \u00e0 \u00e9viter de r\u00e9p\u00e9ter les m\u00eames probl\u00e8mes. Pour cela, nous avions besoin d'un acc\u00e8s complet aux logs et de leur livraison pratiquement en temps r\u00e9el, car l'\u00e9quipe d'ing\u00e9nieurs de garde surveillait les alertes non seulement des m\u00e9triques, mais aussi des logs. Pour comprendre l'ampleur du probl\u00e8me, \u00e0 l'\u00e9poque, le volume total des logs \u00e9tait d'environ 2 To par jour.\u00a0<\/p>\n

Nous avons d\u00e9fini comme objectif d'\u00e9liminer compl\u00e8tement la perte de logs et de r\u00e9duire le temps de leur livraison vers le cluster ELK \u00e0 un maximum de 15 minutes en cas d'urgence (cette valeur est par la suite devenue notre KPI interne).<\/p>\n

Un nouveau m\u00e9canisme de rotation et des n\u0153uds hot-warm<\/h3>\n

\n\"Comment
\n
\nNous avons commenc\u00e9 la transformation du cluster par la mise \u00e0 jour de la version d'ElasticSearch de 5.5.2 \u00e0 6.4.3. Notre cluster en version 5 est tomb\u00e9 \u00e0 nouveau, et nous avons d\u00e9cid\u00e9 de l'\u00e9teindre et de le mettre \u00e0 jour compl\u00e8tement \u2014 puisqu'il n'y avait de toute fa\u00e7on pas de logs. Nous avons donc r\u00e9alis\u00e9 cette transition en seulement quelques heures.<\/p>\n

La transformation la plus importante \u00e0 ce stade a \u00e9t\u00e9 l'impl\u00e9mentation sur trois n\u0153uds avec un coordinateur comme tampon interm\u00e9diaire d'Apache Kafka. Le courtier de messages nous a lib\u00e9r\u00e9s de la perte de journaux lors de probl\u00e8mes avec ElasticSearch. En m\u00eame temps, nous avons ajout\u00e9 2 n\u0153uds au cluster et sommes pass\u00e9s \u00e0 une architecture hot-warm avec trois n\u0153uds \u00ab chauds \u00bb, dispos\u00e9s dans diff\u00e9rentes baies du centre de donn\u00e9es. Sur ceux-ci, nous avons redirig\u00e9 selon le masque des journaux qui ne devaient en aucun cas \u00eatre perdus \u2014 nginx, ainsi que les journaux d'erreurs des applications. Les autres n\u0153uds recevaient des journaux mineurs \u2014 debug, warning, etc., et apr\u00e8s 24 heures, des journaux \u00ab importants \u00bb des n\u0153uds \u00ab chauds \u00bb \u00e9taient transf\u00e9r\u00e9s.<\/p>\n

Pour ne pas augmenter le nombre d'index de petite taille, nous sommes pass\u00e9s d'une rotation par temps \u00e0 un m\u00e9canisme de rollover. Les forums contenaient beaucoup d'informations indiquant que la rotation par taille d'index \u00e9tait tr\u00e8s peu fiable, c'est pourquoi nous avons d\u00e9cid\u00e9 d'utiliser la rotation bas\u00e9e sur le nombre de documents dans l'index. Nous avons analys\u00e9 chaque index et not\u00e9 le nombre de documents apr\u00e8s lequel la rotation devait \u00eatre d\u00e9clench\u00e9e. Ainsi, nous avons atteint une taille de shard optimale \u2014 pas plus de 50 Go.\u00a0<\/p>\n

Optimisation du cluster<\/h3>\n

\n\"Comment
\n
\nCependant, nous n'avons pas compl\u00e8tement \u00e9limin\u00e9 les probl\u00e8mes. Malheureusement, de petits index apparaissaient toujours : ils n'atteignaient pas le volume requis, ne rotativaient pas et \u00e9taient supprim\u00e9s par un nettoyage global des index de plus de trois jours, car nous avions supprim\u00e9 la rotation par date. Cela entra\u00eenait des pertes de donn\u00e9es, car l'index disparaissait compl\u00e8tement du cluster, et la tentative d'enregistrement dans un index inexistant brisait la logique de curator que nous utilisions pour la gestion. L'alias pour l'\u00e9criture se transformait en index et perturbait la logique de rollover, provoquant une croissance incontr\u00f4l\u00e9e de certains index jusqu'\u00e0 600 Go.\u00a0<\/p>\n

Par exemple, pour la configuration de rotation :<\/p>\n

curator-elk-rollover.yaml\n\n---\nactions:\n\u00a0\u00a01:\n\u00a0\u00a0\u00a0\u00a0action: rollover\n\u00a0\u00a0\u00a0\u00a0options:\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0name: \"nginx_write\"\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0conditions:\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0max_docs: 100000000\n\u00a0\u00a02:\n\u00a0\u00a0\u00a0\u00a0action: rollover\n\u00a0\u00a0\u00a0\u00a0options:\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0name: \"python_error_write\"\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0conditions:\n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0max_docs: 10000000\n<\/code><\/pre>\n
En l'absence d'alias de rollover, une erreur est survenue :<\/p>\n
ERROR \u00a0 \u00a0 alias \"nginx_write\" not found.\nERROR \u00a0 \u00a0 Failed to complete action: rollover.\u00a0 <type 'exceptions.ValueError'>: Unable to perform index rollover with alias \"nginx_write\".\n<\/code><\/pre>\n
Nous avons laiss\u00e9 la r\u00e9solution de ce probl\u00e8me pour une prochaine it\u00e9ration et nous nous sommes concentr\u00e9s sur une autre question : nous sommes pass\u00e9s \u00e0 une logique de travail par pull pour Logstash, g\u00e9rant le traitement des logs entrants (suppression des informations superflues et enrichissement). Nous l'avons plac\u00e9 dans Docker, que nous lan\u00e7ons via docker-compose, et y avons \u00e9galement d\u00e9ploy\u00e9 logstash-exporter, qui envoie des m\u00e9triques \u00e0 Prometheus pour un suivi op\u00e9rationnel du flux de logs. Cela nous a permis de modifier progressivement le nombre d'instances de Logstash responsables du traitement de chaque type de logs.<\/p>\n
Pendant que nous perfectionnions le cluster, le trafic sur cian.ru a augment\u00e9 jusqu'\u00e0 12,8 millions d'utilisateurs uniques par mois. En cons\u00e9quence, nos transformations ont l\u00e9g\u00e8rement pris du retard par rapport aux changements en production, et nous avons constat\u00e9 que les n\u0153uds \u00ab ti\u00e8des \u00bb ne parvenaient pas \u00e0 g\u00e9rer la charge, ralentissant ainsi toute la livraison des logs. Les donn\u00e9es \u00ab chaudes \u00bb arrivaient sans interruptions, mais il fallait intervenir manuellement sur la livraison des autres et effectuer des rollovers manuels pour r\u00e9partir uniform\u00e9ment les index.\u00a0<\/p>\n
Cependant, la mise \u00e0 l'\u00e9chelle et les changements de configuration des instances de Logstash dans le cluster \u00e9taient compliqu\u00e9s par le fait qu'il s'agissait d'un docker-compose local, et toutes les actions \u00e9taient effectu\u00e9es \u00e0 la main (pour ajouter de nouveaux endpoints, il fallait manuellement passer par tous les serveurs et ex\u00e9cuter docker-compose up -d partout).<\/p>\n
R\u00e9partition des logs<\/h3>\n
\nEn septembre de cette ann\u00e9e, nous continuions encore \u00e0 d\u00e9composer le monolithe, la charge sur le cluster augmentait, et le flux de logs approchait les 30 000 messages par seconde.\u00a0<\/p>\n
\"Comment
\n
\nNous avons commenc\u00e9 la prochaine it\u00e9ration par une mise \u00e0 jour du mat\u00e9riel. Nous sommes pass\u00e9s de cinq coordonnateurs \u00e0 trois, avons remplac\u00e9 les n\u0153uds de donn\u00e9es, et avons r\u00e9alis\u00e9 des \u00e9conomies tant financi\u00e8res qu\u2019en capacit\u00e9 de stockage. Pour les n\u0153uds, nous utilisons deux configurations :\u00a0<\/p>\n