Saudações a todos! Trabalho como engenheiro de sistemas na
Onlanta . Em um de nossos projetos, participei da implementação e manutenção do Elastic Stack. Passamos da coleta de logs virtualmente à mão para um processo automatizado e centralizado. Há dois anos, praticamente não mudamos a arquitetura da solução e planejamos usar uma ferramenta conveniente em outros projetos. Compartilho com vocês nossa história de sua implementação, bem como alguns pontos fortes e fracos deste post.
FonteNo início de 2016, os logs de nossos administradores e desenvolvedores eram, por assim dizer, "ao seu alcance", ou seja, um engenheiro para trabalhar com eles conectados via SSH ao host em que o serviço em que ele estava interessado, descobriu o conjunto universal de tail / grep / sed / awk e esperava que fosse possível encontrar os dados necessários nesse host.
FonteTambém tínhamos um servidor separado, no qual todos os diretórios com logs de todos os servidores eram montados via NFS, e às vezes se pensava por um longo tempo sobre o que todos queriam fazer com os logs contidos nele. Bem, o tmux com vários painéis em execução em alguns logs atualizados ativamente parecia muito impressionante para pessoas de fora em um monitor grande e criou uma emocionante atmosfera de envolvimento nos sacramentos da produção.
Tudo isso até funcionou, mas exatamente até que fosse necessário processar rapidamente uma grande quantidade de dados, e isso era frequentemente necessário nos momentos em que algo caíra no prod.
Às vezes, levava um tempo indecente para investigar incidentes. Uma parte significativa foi gasta na agregação manual de logs, lançando
muletas de vários scripts no Bash e Python, aguardando o upload de logs em algum lugar para análise, etc.
Em uma palavra, tudo isso foi muito lento, inspirado no desânimo e inequivocamente sugeriu que era hora de cuidar do armazenamento centralizado de logs.
Para ser sincero, não houve um processo complicado de seleção de candidatos para o papel da pilha tecnológica que nos proporcionaria isso: o pacote ELK já era popular na época, possuía boa documentação, havia um grande número de artigos na Internet para todos os componentes. A decisão foi imediata: você precisa tentar.
FonteA primeira instalação da pilha foi feita após assistir ao webinar “Logstash: 0-60 in 60” em três máquinas virtuais, cada uma das quais lançou uma instância do Elasticsearch, Logstash e Kibana.
Além disso, encontramos alguns problemas com a entrega de logs de hosts finais para servidores Logstash. O fato é que, naquela época, o Filebeat (uma solução de pilha padrão para entrega de logs de arquivos de texto) funcionava muito pior com arquivos grandes e atualizados rapidamente, vazava regularmente na RAM e, no nosso caso, como um todo, não podia lidar com sua tarefa.
A isso foi adicionada a necessidade de encontrar uma maneira de entregar logs do servidor de aplicativos a partir de máquinas executando o IBM AIX: a maior parte de nossos aplicativos foi então lançada no WebSphere Application Server, que funcionava especificamente sob este SO. O Filebeat está escrito em Go, não havia um compilador Go mais ou menos eficiente para o AIX em 2016 e eu realmente não queria usar o Logstash como um agente para entrega.
Testamos vários agentes de entrega de log: Filebeat, logstash-forwarder-java,
log-courier , python-beaver e NXLog. Dos agentes, esperávamos alto desempenho, baixo consumo de recursos do sistema, fácil integração com o Logstash e a capacidade de executar manipulações básicas de dados com as forças do agente (por exemplo, a montagem de eventos de várias linhas).
Sobre a montagem de eventos multilinhas, vale a pena mencionar separadamente. Efetivamente, ele só pode ser executado no lado do agente que lê um arquivo específico. Apesar do Logstash ter um filtro de múltiplas linhas e agora ter um codec de várias linhas, todas as nossas tentativas de combinar o balanceamento de eventos entre vários servidores Logstash com o processamento de várias linhas falharam. Essa configuração torna quase impossível o balanceamento eficiente de eventos; portanto, para nós, o fator mais importante na escolha de agentes foi o suporte a várias linhas.
Os vencedores foram os seguintes: log-courier para máquinas com Linux, NXLog para máquinas com AIX. Com essa configuração, vivemos quase um ano sem problemas: os logs foram entregues, os agentes não caíram (bem, quase), todos ficaram felizes.
Em outubro de 2016, a quinta versão dos componentes do Elastic Stack foi lançada, incluindo o Beats 5.0. Muito trabalho foi feito em todos os agentes da Beats nesta versão e pudemos substituir o correio de correio (que naquela época tinha seus próprios problemas) pelo Filebeat, que ainda usamos.
Ao migrar para a versão 5.0, começamos a coletar não apenas logs, mas também algumas métricas: o Packetbeat começou a ser usado aqui e ali como uma alternativa para gravar logs de solicitações HTTP em arquivos e o Metricbeat coletou métricas e métricas do sistema de alguns serviços.
Nesse momento, o trabalho de nossos engenheiros com logs ficou muito mais simples: agora não havia necessidade de saber em qual servidor ir para ver o log em que você estava interessado, a troca de informações encontrada foi simplificada para simplesmente transferir o link para o Kibana em salas de bate-papo ou correio e relatórios que foram criados anteriormente em poucas horas, começou a ser criado em alguns segundos. Não se pode dizer que se tratava apenas de uma questão de conforto: notamos mudanças na qualidade do nosso trabalho, na quantidade e qualidade das tarefas fechadas, na velocidade de resposta a problemas em nossos estandes.
Em algum momento, começamos a usar o utilitário ElastAlert do Yelp para enviar alertas aos engenheiros. E então pensamos: por que não integrá-lo ao nosso Zabbix para que todos os alertas tenham um formato padrão e sejam enviados centralmente? A solução foi encontrada rapidamente: o ElastAlert permite executar qualquer comando em vez de enviar alertas, que usamos.
Agora, nossas regras ElastAlert, quando acionadas, executam um script bash em várias linhas, para as quais os dados necessários são passados nos argumentos do evento que acionou a regra, e o zabbix_sender é chamado a partir do script, que envia os dados ao Zabbix para o nó desejado.
Como todas as informações sobre quem gerou o evento e onde estão sempre disponíveis no Elasticsearch, não houve dificuldades com a integração. Por exemplo, anteriormente tínhamos um mecanismo para detectar automaticamente servidores de aplicativos WAS e, nos eventos que eles geram, o nome do servidor, cluster, célula etc. sempre é gravado. Isso nos permitiu usar a opção query_key nas regras do ElastAlert, para que as condições das regras fossem processadas para cada servidor separadamente. O script com zabbix_sender obtém as "coordenadas" exatas do servidor e os dados são enviados ao Zabbix para o nó correspondente.
Outra solução que realmente gostamos e que foi possível graças à coleção centralizada de logs é um script para a criação automática de logs de tarefas no JIRA: uma vez por dia, ele pega todos os erros dos logs e, se ainda não houver, os inicia. Ao mesmo tempo, de diferentes índices por um ID de solicitação exclusivo, todas as informações que podem ser úteis na investigação são inseridas na tarefa. O resultado é um tipo de peça de trabalho padrão com as informações mínimas necessárias, que os engenheiros podem complementar se necessário.
Obviamente, fomos confrontados com a questão de monitorar a própria pilha. Isso é parcialmente implementado usando o Zabbix, parcialmente usando o mesmo ElastAlert, e obtemos as principais métricas de desempenho do Elasticsearch, Logstash e Kibana usando o monitoramento padrão incorporado na pilha (o componente Monitoramento no X-Pack). Além disso, nos servidores com os próprios serviços de pilha, instalamos o
netdata do Firehol. É útil quando você precisa ver o que acontece com um nó específico agora, em tempo real e com alta resolução.
Era uma vez, o módulo de monitoramento Elasticsearch estava um pouco quebrado, encontramos, corrigimos, adicionamos todos os tipos de métricas úteis e fizemos uma solicitação de recebimento. Portanto, agora o netdata pode monitorar as versões mais recentes do Elasticsearch, incluindo métricas básicas da JVM, indexação, indicadores de desempenho de pesquisa, estatísticas do log de transações, segmentos de índice e assim por diante. Gostamos do Netdata e estamos satisfeitos por termos conseguido dar uma pequena contribuição a ele.
Hoje, depois de quase três anos, nosso Elastic Stack se parece com isso:
Os engenheiros trabalham com a pilha de três maneiras principais:
- visualizando e analisando logs e métricas no Kibana;
- painéis em Grafana e Kibana;
- consultas diretas ao Elasticsearch usando SQL ou a consulta interna DSL.
No total, todos esses recursos são alocados: 146 CPU, 484 GB de RAM e 17 TB são alocados para o armazém de dados do Elasticsearch.
No total, temos 13 máquinas virtuais trabalhando como parte do Elastic Stack: 4 máquinas para nós Elasticsearch “quentes”, 4 para nós “quentes”, 4 máquinas com Logstash e uma máquina de balanceamento. Em cada nó ativo, o Elasticsearch executa uma instância do Kibana. Isso aconteceu desde o início, e até agora não tivemos que mudar o Kibana para separar carros.
Mas a decisão de levar o Logstash para máquinas separadas acabou sendo uma das mais corretas e eficazes durante a operação de empilhamento: a alta competição pelo tempo do processador entre a JVM Elasticsearch e o Logstash levou a efeitos especiais não muito agradáveis durante explosões de carga. Os coletores de lixo sofreram mais.
FonteArmazenamos dados dos últimos 30 dias no cluster: agora são cerca de 12 bilhões de eventos. Diariamente, os nós quentes gravam no disco de 400 a 500 GB novos dados com uma taxa de compactação máxima (incluindo dados de réplicas de fragmentos). Nosso cluster do Elasticsearch possui uma arquitetura quente / quente, mas passamos a usá-lo relativamente recentemente; portanto, menos dados ainda são armazenados nos nós "quentes" do que nos "quentes".
Nossa carga de trabalho típica:
- indexação - em média 13.000 rps com picos de até 30.000 (excluindo a indexação em fragmentos de réplica);
- Pesquisa - 5200 rps.
Tentamos manter uma margem de CPU de 40 a 50% nos nós quentes do Elasticsearch, para que possamos experimentar facilmente picos repentinos no número de eventos indexados e solicitações pesadas da Kibana / Grafana ou sistemas de monitoramento externos. Aproximadamente 50% da RAM em hosts com nós do Elasticsearch está sempre disponível para o cache da página e as necessidades fora da pilha da JVM.
Durante o tempo decorrido desde o lançamento do primeiro cluster, conseguimos identificar alguns dos lados positivos e negativos do Elastic Stack como um meio de agregar logs e uma plataforma de pesquisa e analítica.
O que mais gostamos na pilha:- Um único ecossistema de produtos bem integrado entre si, com quase tudo o que você precisa. Os Beats não eram muito bons, mas agora não temos queixas.
- O Logstash, com toda a sua monstruosidade, é um pré-processador muito flexível e poderoso e permite fazer muito com dados brutos (e se algo não permitir, você sempre pode escrever um trecho em Ruby).
- O Elasticsearch com plug-ins (e mais recentemente pronto para uso) oferece suporte ao SQL como uma linguagem de consulta, o que simplifica sua integração com outros softwares e pessoas que estão mais próximas do SQL como uma linguagem de consulta.
- Documentação de alta qualidade que permite introduzir rapidamente novos funcionários no projeto. A operação da pilha, portanto, não se torna negócio de uma pessoa que tenha alguma experiência específica e "conhecimento secreto".
- Não é necessário saber muito sobre a estrutura dos dados recebidos para começar a coletá-los: você pode começar a agregar os eventos como eles são e, depois de entender quais informações úteis você pode extrair deles, altere a abordagem para processá-los sem perder a "compatibilidade com versões anteriores". Existem muitas ferramentas convenientes na pilha para isso: aliases de campo em índices, campos com script etc.
- Os componentes do X-Pack são distribuídos apenas de acordo com o modelo de assinatura e nada mais: se, por exemplo, o Gold oferecer suporte apenas a relatórios RBAC ou PDF, será necessário pagar por tudo o que o Gold possui. Isso é especialmente frustrante quando, por exemplo, apenas o Graph é necessário da Platinum e o Machine Learning e outro pacote de outras funcionalidades que você pode não precisar estão disponíveis para compra. Nossas tentativas de comunicação com o departamento de vendas da Elastic sobre o licenciamento de componentes individuais do X-Pack há cerca de um ano atrás não levaram a nada, mas talvez algo tenha mudado desde então.
- Versões bastante freqüentes em que de alguma forma (sempre que novas) quebram a compatibilidade com versões anteriores. Você deve ler o registro de alterações com muito cuidado e se preparar para atualizações com antecedência. Cada vez que você precisa escolher: fique na versão antiga, que funciona de forma estável, ou tente atualizar para obter novos recursos e ganhos de desempenho.
Em geral, estamos muito satisfeitos com nossa escolha feita em 2016 e planejamos transferir a experiência de operação do Elastic Stack para nossos outros projetos: as ferramentas fornecidas pelo stack são muito bem integradas ao nosso fluxo de trabalho e seria muito difícil recusá-las agora.
E também em nossa empresa, várias vagas estão abertas.