{"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\/es\/blog\/administrirovanie\/kak-my-v-tsian-ukroshhali-terabajty-logov","title":{"rendered":"C\u00f3mo en CIAN controlamos terabytes de registros","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"C\u00f3mo
\n
\nHola a todos, me llamo Alexander, trabajo en CIAN como ingeniero y me encargo de la administraci\u00f3n de sistemas y la automatizaci\u00f3n de procesos de infraestructura. En los comentarios de uno de los art\u00edculos anteriores, nos pidieron que explic\u00e1ramos de d\u00f3nde obtenemos 4 TB de registros al d\u00eda y qu\u00e9 hacemos con ellos. S\u00ed, tenemos muchos registros, y para su procesamiento hemos creado un cl\u00faster de infraestructura separado que nos permite resolver problemas de manera eficiente. En este art\u00edculo, contar\u00e9 c\u00f3mo hemos adaptado este sistema en un a\u00f1o para trabajar con un flujo de datos en constante crecimiento.
\n<\/a><\/noindex><\/p>\n

Por d\u00f3nde empezamos<\/h3>\n

\n\"C\u00f3mo
\n
\nEn los \u00faltimos a\u00f1os, la carga en cian.ru ha crecido muy r\u00e1pidamente, y para el tercer trimestre de 2018, la asistencia al sitio alcanz\u00f3 los 11.2 millones de usuarios \u00fanicos al mes. En esos momentos cr\u00edticos, perd\u00edamos hasta el 40% de los registros, lo que nos imped\u00eda abordar incidentes de forma r\u00e1pida y dedic\u00e1bamos mucho tiempo y esfuerzo a resolverlos. A menudo, no pod\u00edamos encontrar la causa del problema, y este se repet\u00eda despu\u00e9s de un tiempo. Era un verdadero caos, y hab\u00eda que hacer algo al respecto.<\/p>\n

En ese momento, utiliz\u00e1bamos un cl\u00faster de 10 nodos de datos con ElasticSearch versi\u00f3n 5.5.2 y configuraciones est\u00e1ndar para el almacenamiento de registros. Se implement\u00f3 hace m\u00e1s de un a\u00f1o como una soluci\u00f3n popular y accesible: entonces, el flujo de registros no era tan grande, y no ten\u00eda sentido idear configuraciones no est\u00e1ndar.\u00a0<\/p>\n

El procesamiento de los registros entrantes se realizaba mediante Logstash en diferentes puertos en cinco coordinadores de ElasticSearch. Un \u00edndice, independientemente de su tama\u00f1o, consist\u00eda en cinco fragmentos. Se organiz\u00f3 una rotaci\u00f3n horaria y diaria, lo que resultaba en aproximadamente 100 nuevos fragmentos en el cl\u00faster cada hora. Mientras hab\u00eda pocos registros, el cl\u00faster funcionaba adecuadamente y nadie prestaba atenci\u00f3n a su configuraci\u00f3n.\u00a0<\/p>\n

Problemas de r\u00e1pido crecimiento<\/h3>\n

\nEl volumen de registros generados crec\u00eda muy r\u00e1pido, ya que se superpusieron dos procesos. Por un lado, la cantidad de usuarios del servicio aumentaba. Por otro lado, comenzamos a adoptar activamente una arquitectura de microservicios, descomponiendo nuestros antiguos monolitos en C# y Python. Varios docenas de nuevos microservicios, que reemplazaban partes del monolito, generaban significativamente m\u00e1s registros para el cl\u00faster de infraestructura.\u00a0<\/p>\n

La escalabilidad fue precisamente lo que llev\u00f3 a que el cl\u00faster se volviera pr\u00e1cticamente incontrolable. Cuando los registros comenzaron a llegar a una velocidad de 20,000 mensajes por segundo, la rotaci\u00f3n frecuente e innecesaria increment\u00f3 el n\u00famero de shards a 6,000, y cada nodo manejaba m\u00e1s de 600 shards.\u00a0<\/p>\n

Esto ocasion\u00f3 problemas con la asignaci\u00f3n de memoria, y al caer un nodo comenzaba la migraci\u00f3n simult\u00e1nea de todos los shards, multiplicando el tr\u00e1fico y sobrecargando los dem\u00e1s nodos, lo que hac\u00eda pr\u00e1cticamente imposible la escritura de datos en el cl\u00faster. Durante este periodo, estuvimos sin registros. Y ante el problema con el servidor<\/a> perd\u00edamos 1\/10 del cl\u00faster en principio. La gran cantidad de \u00edndices peque\u00f1os complicaba a\u00fan m\u00e1s la situaci\u00f3n.<\/p>\n

Sin registros no entend\u00edamos las causas del incidente y, tarde o temprano, podr\u00edamos caer en los mismos errores de nuevo, lo cual es inaceptable para nuestra ideolog\u00eda de equipo, ya que todos nuestros mecanismos de trabajo est\u00e1n dise\u00f1ados precisamente para lo contrario: nunca repetir los mismos problemas. Para ello necesit\u00e1bamos un volumen completo de registros y su entrega casi en tiempo real, ya que el equipo de ingenieros de guardia monitorizaba alertas no solo de m\u00e9tricas, sino tambi\u00e9n de logs. Para entender la magnitud del problema, en ese momento el volumen total de registros era de aproximadamente 2 TB por d\u00eda.\u00a0<\/p>\n

Nos propusimos la tarea de eliminar completamente la p\u00e9rdida de registros y reducir el tiempo de entrega al cl\u00faster ELK a un m\u00e1ximo de 15 minutos durante situaciones de emergencia (esa cifra se convirti\u00f3 en nuestro KPI interno).<\/p>\n

Nuevo mecanismo de rotaci\u00f3n y nodos hot-warm.<\/h3>\n

\n\"C\u00f3mo
\n
\nComenzamos la transformaci\u00f3n del cl\u00faster actualizando la versi\u00f3n de ElasticSearch de 5.5.2 a 6.4.3. Nuevamente experimentamos la ca\u00edda del cl\u00faster de la versi\u00f3n 5, y decidimos desactivarlo y actualizarlo completamente, ya que de todos modos no ten\u00edamos registros. As\u00ed que esta transici\u00f3n la realizamos en solo unas pocas horas.<\/p>\n

La transformaci\u00f3n m\u00e1s significativa en esta etapa fue la implementaci\u00f3n de tres nodos con un coordinador como un buffer intermedio utilizando Apache Kafka. El broker de mensajes nos liber\u00f3 de la p\u00e9rdida de registros durante problemas con ElasticSearch. Al mismo tiempo, agregamos 2 nodos al cl\u00faster y cambiamos a una arquitectura hot-warm con tres nodos 'calientes', ubicados en diferentes racks en el centro de datos. En ellos, redirigimos los registros que no pod\u00edan perderse bajo ninguna circunstancia: nginx, as\u00ed como los registros de errores de las aplicaciones. A los otros nodos se les enviaron registros menores: debug, warning, etc., y despu\u00e9s de 24 horas, los 'importantes' registros se trasladaron desde los nodos 'calientes'.<\/p>\n

Para no aumentar la cantidad de \u00edndices peque\u00f1os, cambiamos de rotaci\u00f3n temporal a un mecanismo de rollover. En los foros hab\u00eda mucha informaci\u00f3n sobre que la rotaci\u00f3n por tama\u00f1o de \u00edndice es muy poco confiable, por lo que decidimos utilizar la rotaci\u00f3n por n\u00famero de documentos en el \u00edndice. Analizamos cada \u00edndice y registramos la cantidad de documentos despu\u00e9s de la cual deb\u00eda activarse la rotaci\u00f3n. De esta manera, logramos un tama\u00f1o \u00f3ptimo de shard: no m\u00e1s de 50 GB.\u00a0<\/p>\n

Optimizaci\u00f3n del cl\u00faster<\/h3>\n

\n\"C\u00f3mo
\n
\nSin embargo, no nos libramos completamente de los problemas. Desafortunadamente, a\u00fan aparec\u00edan \u00edndices peque\u00f1os: no alcanzaban el volumen requerido, no rotaban y se eliminaban con la limpieza global de \u00edndices que ten\u00edan m\u00e1s de tres d\u00edas, ya que eliminamos la rotaci\u00f3n por fecha. Esto provocaba p\u00e9rdida de datos debido a que el \u00edndice desaparec\u00eda completamente del cl\u00faster, y el intento de escritura en un \u00edndice inexistente romp\u00eda la l\u00f3gica del curator que utilizamos para la gesti\u00f3n. El alias para la escritura se convert\u00eda en un \u00edndice y romp\u00eda la l\u00f3gica del rollover, causando un crecimiento descontrolado de algunos \u00edndices hasta 600 GB.\u00a0<\/p>\n

Por ejemplo, para la configuraci\u00f3n de rotaci\u00f3n:<\/p>\n

curator-elk-rollover.yaml\n\n---\nactions:\n  1:\n    action: rollover\n    options:\n      name: \"nginx_write\"\n      conditions:\n        max_docs: 100000000\n  2:\n    action: rollover\n    options:\n      name: \"python_error_write\"\n      conditions:\n        max_docs: 10000000\n<\/code><\/pre>\n
En ausencia de rollover, el alias generaba un error:<\/p>\n
ERROR     alias \"nginx_write\" not found.\nERROR     Failed to complete action: rollover.  : Unable to perform index rollover with alias \"nginx_write\".\n<\/code><\/pre>\n
Dejamos la soluci\u00f3n de este problema para la siguiente iteraci\u00f3n y nos ocupamos de otro asunto: pasamos a la l\u00f3gica de trabajo de pull en Logstash, que se encarga del procesamiento de los registros entrantes (eliminaci\u00f3n de informaci\u00f3n innecesaria y enriquecimiento). Lo colocamos en docker, que ejecutamos a trav\u00e9s de docker-compose, y tambi\u00e9n colocamos logstash-exporter, que proporciona m\u00e9tricas a Prometheus para el monitoreo operativo del flujo de registros. As\u00ed nos dimos la posibilidad de cambiar gradualmente el n\u00famero de instancias de logstash responsables del procesamiento de cada tipo de registros.<\/p>\n
Mientras perfeccion\u00e1bamos el cl\u00faster, la asistencia en cian.ru creci\u00f3 hasta 12,8 millones de usuarios \u00fanicos al mes. Como resultado, nuestras transformaciones se quedaron un poco atr\u00e1s de los cambios en producci\u00f3n, y nos encontramos con que los nodos 'fr\u00edos' no pod\u00edan manejar la carga, lo que ralentizaba toda la entrega de registros. Los datos 'calientes' los recib\u00edamos sin problemas, pero en la entrega de los restantes ten\u00edamos que intervenir y hacer un rollover manual para distribuir uniformemente los \u00edndices.\u00a0<\/p>\n
Sin embargo, la escalabilidad y el cambio de configuraciones de las instancias de logstash en el cl\u00faster se complicaban porque era un docker-compose local, y todas las acciones se realizaban manualmente (para agregar nuevos finales, era necesario recorrer todos los servidores manualmente y ejecutar docker-compose up -d en cada uno).<\/p>\n
Redistribuci\u00f3n de registros<\/h3>\n
\nEn septiembre de este a\u00f1o, todav\u00eda continu\u00e1bamos descomponiendo el monolito, la carga en el cl\u00faster aumentaba y el flujo de registros se acercaba a 30 mil mensajes por segundo.\u00a0<\/p>\n
\"C\u00f3mo
\n
\nComenzamos la siguiente iteraci\u00f3n con una actualizaci\u00f3n del hardware. Pasamos de cinco coordinadores a tres, reemplazamos los nodos de datos y ganamos tanto en dinero como en capacidad de almacenamiento. Para los nodos usamos dos configuraciones:\u00a0<\/p>\n