{"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\/pt\/blog\/administrirovanie\/kak-my-v-tsian-ukroshhali-terabajty-logov","title":{"rendered":"Como n\u00f3s, no CIAN, controlamos terabytes de logs","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Como
\n
\nOl\u00e1 a todos, meu nome \u00e9 Alexandre, trabalho na CIAN como engenheiro e sou respons\u00e1vel pela administra\u00e7\u00e3o de sistemas e automa\u00e7\u00e3o de processos de infraestrutura. Nos coment\u00e1rios de um dos artigos anteriores, fomos solicitados a explicar de onde obtemos 4 TB de logs por dia e o que fazemos com eles. Sim, temos muitos logs, e para process\u00e1-los, criamos um cluster de infraestrutura separado que nos permite resolver problemas de forma r\u00e1pida. Neste artigo, contarei como, ao longo de um ano, adaptamos esse cluster para lidar com o fluxo de dados em constante crescimento.
\n<\/a><\/noindex><\/p>\n

Como come\u00e7amos<\/h3>\n

\n\"Como
\n
\nNos \u00faltimos anos, a carga no cian.ru cresceu muito rapidamente, e no terceiro trimestre de 2018, o site alcan\u00e7ou 11,2 milh\u00f5es de usu\u00e1rios \u00fanicos por m\u00eas. Naquela \u00e9poca, em momentos cr\u00edticos, perd\u00edamos at\u00e9 40% dos logs, o que impedia nossa capacidade de responder rapidamente a incidentes, fazendo com que gast\u00e1ssemos muito tempo e esfor\u00e7o para resolv\u00ea-los. Al\u00e9m disso, muitas vezes n\u00e3o consegu\u00edamos encontrar a causa do problema, e ele se repetia ap\u00f3s algum tempo. Foi um verdadeiro inferno que precisava ser resolvido.<\/p>\n

Naquela \u00e9poca, para armazenar os logs, utiliz\u00e1vamos um cluster de 10 data nodes com ElasticSearch vers\u00e3o 5.5.2 e configura\u00e7\u00f5es de \u00edndice padr\u00e3o. Ele foi implementado h\u00e1 mais de um ano como uma solu\u00e7\u00e3o popular e acess\u00edvel: naquela \u00e9poca, o fluxo de logs n\u00e3o era t\u00e3o grande, e n\u00e3o havia sentido em criar configura\u00e7\u00f5es n\u00e3o convencionais.\u00a0<\/p>\n

O processamento dos logs de entrada era realizado pelo Logstash em diferentes portas em cinco coordenadores do ElasticSearch. Um \u00edndice, independentemente do tamanho, consistia em cinco shards. Havia rota\u00e7\u00e3o hor\u00e1ria e di\u00e1ria, resultando na cria\u00e7\u00e3o de cerca de 100 novos shards a cada hora. Enquanto os logs n\u00e3o eram muito numerosos, o cluster conseguia lidar e ningu\u00e9m prestava aten\u00e7\u00e3o nas suas configura\u00e7\u00f5es.\u00a0<\/p>\n

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

\nO volume de logs gerados cresceu muito rapidamente, pois dois processos se sobrepuseram. Por um lado, o n\u00famero de usu\u00e1rios do servi\u00e7o estava aumentando. Por outro lado, come\u00e7amos a transitar ativamente para uma arquitetura de microservi\u00e7os, dividindo nossos antigos mon\u00f3litos em C# e Python. V\u00e1rios novos microservi\u00e7os, que substitu\u00edam partes do mon\u00f3lito, geravam significativamente mais logs para o cluster de infraestrutura.\u00a0<\/p>\n

A escalabilidade nos levou a um ponto onde o cluster se tornou praticamente incontrol\u00e1vel. Quando os logs come\u00e7aram a chegar a uma taxa de 20 mil mensagens por segundo, a rota\u00e7\u00e3o frequente e in\u00fatil aumentou o n\u00famero de shards para 6 mil, e cada n\u00f3 estava lidando com mais de 600 shards.\u00a0<\/p>\n

Isso causava problemas de aloca\u00e7\u00e3o de mem\u00f3ria, e quando um n\u00f3 falhava, todos os shards se deslocavam simultaneamente, multiplicando o tr\u00e1fego e sobrecarregando os outros n\u00f3s, tornando quase imposs\u00edvel gravar dados no cluster. E durante esse per\u00edodo, ficamos sem logs. E quando havia um problema com servidor<\/a> perd\u00edamos 1\/10 do cluster no geral. A grande quantidade de \u00edndices pequenos tornava as coisas ainda mais complicadas.<\/p>\n

Sem logs, n\u00e3o entend\u00edamos as causas do incidente e pod\u00edamos, cedo ou tarde, cometer os mesmos erros novamente, o que era inaceit\u00e1vel para a nossa equipe, j\u00e1 que todos os mecanismos de trabalho estavam exatamente voltados para o oposto \u2014 nunca repetir os mesmos problemas. Para isso, precis\u00e1vamos de um volume completo de logs e a entrega deles praticamente em tempo real, uma vez que a equipe de engenheiros de plant\u00e3o monitorava alertas n\u00e3o apenas de m\u00e9tricas, mas tamb\u00e9m de logs. Para entender a magnitude do problema \u2014 na \u00e9poca, o volume total de logs era de cerca de 2 TB por dia.\u00a0<\/p>\n

Estabelecemos a meta de eliminar completamente a perda de logs e reduzir o tempo de entrega no cluster ELK para no m\u00e1ximo 15 minutos durante situa\u00e7\u00f5es de emerg\u00eancia (esse n\u00famero se tornou um KPI interno).<\/p>\n

Um novo mecanismo de rota\u00e7\u00e3o e n\u00f3s hot-warm<\/h3>\n

\n\"Como
\n
\nIniciamos a transforma\u00e7\u00e3o do cluster com a atualiza\u00e7\u00e3o da vers\u00e3o do ElasticSearch de 5.5.2 para 6.4.3. Mais uma vez, o cluster da vers\u00e3o 5 caiu, e decidimos deslig\u00e1-lo e atualiz\u00e1-lo completamente \u2014 afinal, n\u00e3o havia logs. Portanto, essa transi\u00e7\u00e3o foi feita em apenas algumas horas.<\/p>\n

A transforma\u00e7\u00e3o mais significativa nesta fase foi a implementa\u00e7\u00e3o em tr\u00eas n\u00f3s com um coordenador atuando como um buffer intermedi\u00e1rio do Apache Kafka. O broker de mensagens nos livrou da perda de logs durante problemas com o ElasticSearch. Ao mesmo tempo, adicionamos 2 n\u00f3s ao cluster e migramos para uma arquitetura hot-warm com tr\u00eas n\u00f3s \"quentes\", distribu\u00eddos em diferentes racks no data center. Neles, redirecionamos os logs que n\u00e3o podiam ser perdidos de jeito nenhum \u2014 nginx, al\u00e9m dos logs de erros das aplica\u00e7\u00f5es. Os outros n\u00f3s receberam logs menores \u2014 debug, warning, etc., e ap\u00f3s 24 horas, os \"logs importantes\" foram transferidos dos n\u00f3s \"quentes\".<\/p>\n

Para n\u00e3o aumentar a quantidade de \u00edndices pequenos, passamos da rota\u00e7\u00e3o por tempo para o mecanismo de rollover. Havia muitas informa\u00e7\u00f5es em f\u00f3runs sobre a confiabilidade insatisfat\u00f3ria da rota\u00e7\u00e3o por tamanho do \u00edndice, por isso decidimos usar a rota\u00e7\u00e3o pelo n\u00famero de documentos no \u00edndice. Analisamos cada \u00edndice e registramos a quantidade de documentos ap\u00f3s a qual a rota\u00e7\u00e3o deve ser acionada. Assim, conseguimos um tamanho de shard otimizado \u2014 n\u00e3o mais que 50 GB.\u00a0<\/p>\n

Otimiza\u00e7\u00e3o do cluster<\/h3>\n

\n\"Como
\n
\nNo entanto, n\u00e3o nos livramos completamente dos problemas. Infelizmente, ainda surgiam pequenos \u00edndices: eles n\u00e3o atingiam o tamanho necess\u00e1rio, n\u00e3o eram rotacionados e eram removidos pela limpeza global dos \u00edndices mais antigos que tr\u00eas dias, pois eliminamos a rota\u00e7\u00e3o por data. Isso resultou na perda de dados, pois o \u00edndice desaparecia completamente do cluster, e a tentativa de grava\u00e7\u00e3o em um \u00edndice inexistente quebrava a l\u00f3gica do curator que utiliz\u00e1vamos para gerenciamento. O alias para grava\u00e7\u00e3o era transformado em \u00edndice e quebrava a l\u00f3gica do rollover, causando um crescimento descontrolado de alguns \u00edndices at\u00e9 600 GB.\u00a0<\/p>\n

Por exemplo, para a configura\u00e7\u00e3o de rota\u00e7\u00e3o:<\/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
Na aus\u00eancia do rollover alias, ocorreu um erro:<\/p>\n
ERROR \u00a0 \u00a0 alias \"nginx_write\" not found.\nERROR \u00a0 \u00a0 Failed to complete action: rollover.\u00a0 : Unable to perform index rollover with alias \"nginx_write\".\n<\/code><\/pre>\n
N\u00f3s deixamos a solu\u00e7\u00e3o desse problema para a pr\u00f3xima itera\u00e7\u00e3o e nos concentramos em outra quest\u00e3o: mudamos para a l\u00f3gica de trabalho pull do Logstash, que lida com o processamento dos logs de entrada (remo\u00e7\u00e3o de informa\u00e7\u00f5es desnecess\u00e1rias e enriquecimento). Colocamos-no em um docker, que iniciamos atrav\u00e9s do docker-compose, e tamb\u00e9m hospedamos o logstash-exporter, que fornece m\u00e9tricas ao Prometheus para monitoramento em tempo real do fluxo de logs. Assim, permitimos a n\u00f3s mesmos mudar suavemente o n\u00famero de inst\u00e2ncias do logstash respons\u00e1veis pelo processamento de cada tipo de log.<\/p>\n
Enquanto aprimor\u00e1vamos o cluster, o tr\u00e1fego do cian.ru cresceu para 12,8 milh\u00f5es de usu\u00e1rios \u00fanicos por m\u00eas. Como resultado, nossas transforma\u00e7\u00f5es acabaram n\u00e3o acompanhando as mudan\u00e7as no ambiente de produ\u00e7\u00e3o, e enfrentamos o problema de que os n\u00f3s 'quentes' n\u00e3o conseguiam lidar com a carga e estavam atrasando toda a entrega dos logs. Receb\u00edamos os dados 'quentes' sem falhas, mas a entrega dos demais exigia interven\u00e7\u00e3o manual para fazer o rollover e distribuir os \u00edndices de forma equilibrada.\u00a0<\/p>\n
Com isso, a escalabilidade e a altera\u00e7\u00e3o das configura\u00e7\u00f5es das inst\u00e2ncias do logstash no cluster tornavam-se complicadas, pois era um docker-compose local, e todas as a\u00e7\u00f5es eram realizadas manualmente (para adicionar novos endpoints, era necess\u00e1rio acessar manualmente todos os servidores e executar docker-compose up -d em cada um deles).<\/p>\n
Redistribui\u00e7\u00e3o dos logs<\/h3>\n
\nEm setembro deste ano, ainda continu\u00e1vamos a desmembrar o mon\u00f3lito, a carga no cluster aumentava, e o fluxo de logs se aproximava de 30 mil mensagens por segundo.\u00a0<\/p>\n
\"Como
\n
\nCome\u00e7amos a pr\u00f3xima itera\u00e7\u00e3o com uma atualiza\u00e7\u00e3o de hardware. Passamos de cinco coordenadores para tr\u00eas, trocamos os n\u00f3s de dados e ganhamos em custo e armazenamento. Para os n\u00f3s, usamos duas configura\u00e7\u00f5es:\u00a0<\/p>\n