Os logs são uma parte importante do sistema, permitindo que você entenda se ele funciona (ou não funciona) conforme o esperado. Nas condições da arquitetura de microsserviços, trabalhar com logs torna-se uma disciplina separada da Olimpíada Especial. Há muitas questões que precisam ser abordadas:
- como gravar logs do aplicativo;
- onde escrever logs;
- como entregar logs para armazenamento e processamento;
- como processar e armazenar logs.
O uso de tecnologias de conteinerização atualmente populares adiciona areia no topo do ancinho no campo de opções de solução de problemas.
Quase isso é a transcrição do relatório de Yuri Bushmelev "Mapa de um ancinho no campo de coleta e entrega de toras"
Quem se importa, por favor, debaixo do gato.
Meu nome é Yuri Bushmelev. Eu trabalho para Lazada. Hoje vou falar sobre como fizemos nossos logs, como os coletamos e o que escrevemos lá.
De onde somos? Quem somos nós? A Lazada é a varejista on-line nº 1 em seis países do Sudeste Asiático. Todos esses países estão distribuídos entre data centers. Existem agora 4 centros de dados no total. Por que isso é importante? Porque algumas decisões se deram pelo fato de haver um elo muito fraco entre os centros. Temos uma arquitetura de microsserviços. Fiquei surpreso ao descobrir que já temos 80 microsserviços. Quando comecei a tarefa com logs, eram apenas 20. Além disso, há um legado bastante grande do PHP, com o qual também tenho que conviver e tolerar. Tudo isso gera para nós no momento mais de 6 milhões de mensagens por minuto para o sistema como um todo. Além disso, mostrarei como estamos tentando viver com isso e por que isso acontece.
Você tem que viver com essas 6 milhões de mensagens de alguma forma. O que devemos fazer com eles? 6 milhões de mensagens necessárias:
- enviar do aplicativo
- aceitar para entrega
- entregar para análise e armazenamento.
- para analisar
- armazenar de alguma forma.
Quando havia três milhões de mensagens, eu tinha a mesma aparência. Porque começamos com alguns centavos. É claro que os logs do aplicativo são gravados lá. Por exemplo, não foi possível conectar ao banco de dados, foi possível conectar ao banco de dados, mas não foi possível ler algo. Mas, além disso, cada um de nossos microsserviços também grava um log de acesso. Cada requisição que chega ao microsserviço cai no log. Por que estamos fazendo isso? Os desenvolvedores querem poder rastrear. Cada log de acesso contém o campo traceid, de acordo com o qual uma interface especial desenrola toda a cadeia e exibe lindamente o rastreamento. O rastreamento mostra como foi a solicitação e isso ajuda nossos desenvolvedores a lidar com qualquer lixo desconhecido mais rapidamente.
Como viver com isso? Agora descreverei brevemente o campo de opções - como esse problema geralmente é resolvido. Como resolver o problema de coleta, transferência e armazenamento de logs.
Como escrever a partir do aplicativo? É claro que existem maneiras diferentes. Em particular, existe a melhor prática, como nos dizem os camaradas da moda. Existem dois tipos de old school, como diziam os avôs. Existem outras maneiras.
Com a coleta de logs, a situação é aproximadamente a mesma. Não há tantas opções para resolver esta parte específica. Há mais deles, mas ainda não tantos.
Mas com a entrega e posterior análise, o número de variações começa a explodir. Não vou descrever cada opção agora. Acho que as principais opções são bem conhecidas de todos que se interessaram pelo tema.
Vou te mostrar como fizemos na Lazada e como tudo começou.
Há um ano, vim para Lazada e fui enviado para o projeto de toras. Foi assim lá. O log do aplicativo foi gravado em stdout e stderr. Tudo foi feito de maneira elegante. Mas então os desenvolvedores o jogaram fora dos fluxos padrão e os especialistas em infraestrutura descobrirão de alguma forma. Entre os especialistas em infraestrutura e desenvolvedores, também há lançadores que disseram: "uh ... bem, vamos apenas envolvê-los em um arquivo com um shell e pronto." E como tudo isso está em um container, eles embrulharam direto no próprio container, mapearam o diretório dentro e colocaram lá. Acho que é bastante óbvio para todos o que aconteceu.
Vamos olhar um pouco mais. Como entregamos esses logs. Alguém escolheu td-agent, que na verdade é fluente, mas não totalmente fluente. Ainda não entendo a relação desses dois projetos, mas parecem ser sobre a mesma coisa. E este fluentd, escrito em Ruby, lia arquivos de log, os analisava em JSON usando algumas expressões regulares. Então eles foram enviados para Kafka. Além disso, no Kafka, tínhamos 4 tópicos separados para cada API. Por que 4? Porque existe ao vivo, existe encenação e porque existe stdout e stderr. Os desenvolvedores os produzem e os trabalhadores da infraestrutura devem criá-los no Kafka. Além disso, Kafka era controlado por outro departamento. Portanto, foi necessário criar um ticket para que criassem 4 tópicos lá para cada api. Todo mundo se esqueceu disso. Em geral, era lixo e desperdício.
O que fizemos a seguir com isso? Enviamos para kafka. Além de Kafka, metade dos logs voou para Logstash. A outra metade dos logs foi compartilhada. Alguns voaram para um Graylog, alguns para outro Graylog. Como resultado, tudo isso voou para um cluster do Elasticsearch. Ou seja, toda essa bagunça caiu no final aí. Você não precisa fazer isso!
Isto é o que parece quando visto de cima. Você não precisa fazer isso! Aqui, as áreas problemáticas são imediatamente marcadas com números. Na verdade, existem mais, mas 6 são realmente problemáticos, com os quais algo precisa ser feito. Vou contar sobre eles separadamente agora.
Aqui (1,2,3) escrevemos arquivos e, portanto, há três ancinhos aqui ao mesmo tempo.
O primeiro (1) é que precisamos escrevê-los em algum lugar. Nem sempre é desejável dar a uma API a capacidade de gravar diretamente em um arquivo. É desejável que a API seja isolada em um container, e melhor ainda, que seja somente leitura. Sou um administrador de sistema, então tenho uma visão ligeiramente alternativa dessas coisas.
O segundo ponto (2,3) é que temos muitas requisições chegando à API. A API grava muitos dados em um arquivo. Os arquivos estão crescendo. Precisamos girá-los. Porque, caso contrário, você não poderá salvar nenhum disco lá. Rodá-los é ruim porque eles são redirecionados por meio do shell para um diretório. Não há como girá-lo. Você não pode dizer ao aplicativo para reabrir os identificadores. Porque os desenvolvedores vão olhar para você como um tolo: “Que descritores? Geralmente escrevemos para stdout. Os frameworks feitos copytruncate em logrotate, que apenas faz uma cópia do arquivo e trunks o original. Conseqüentemente, entre esses processos de cópia, o espaço em disco geralmente acaba.
(4) Tínhamos diferentes formatos em diferentes APIs. Eles eram um pouco diferentes, mas o regexp tinha que ser escrito de maneira diferente. Como tudo era gerenciado pelo Puppet, havia um monte de classes com suas próprias baratas. Além disso, td-agent na maioria das vezes pode comer memória, ser estúpido, ele pode apenas fingir que está trabalhando e não fazer nada. Externamente, era impossível entender que ele não estava fazendo nada. Na melhor das hipóteses, ele cairá e alguém o levantará mais tarde. Mais precisamente, um alerta chegará e alguém o levantará com as mãos.
(6) E o máximo de lixo e desperdício - era a busca elástica. Porque era uma versão antiga. Porque não tínhamos mestres dedicados naquela época. Tínhamos logs heterogêneos cujos campos podiam se sobrepor. Logs diferentes de aplicativos diferentes podem ser gravados com os mesmos nomes de campo, mas ao mesmo tempo podem conter dados diferentes. Ou seja, um log vem com um Integer em um campo, por exemplo, nível. Outro log vem com uma String no campo de nível. Na ausência de mapeamento estático, uma coisa tão maravilhosa acontece. Se, após a rotação do índice, uma mensagem com uma string chegar primeiro no elasticsearch, viveremos normalmente. E se a primeira chegou com Integer, todas as mensagens subseqüentes que chegaram com String são simplesmente descartadas. Porque o tipo de campo não corresponde.
Começamos a fazer essas perguntas. Decidimos não procurar os culpados.
Mas algo precisa ser feito! O óbvio é que precisamos estabelecer padrões. Já tínhamos alguns padrões. Alguns nós trouxemos um pouco mais tarde. Felizmente, um único formato de log para todas as APIs já foi aprovado naquele momento. Está escrito diretamente nos padrões de interação do serviço. Assim, aqueles que desejam receber logs devem escrevê-los neste formato. Se alguém não escrever logs neste formato, não garantimos nada.
Além disso, gostaria de ter um padrão único para os métodos de registro, entrega e coleta de logs. Na verdade, onde escrevê-los e como entregá-los. A situação ideal é quando os projetos usam a mesma biblioteca. Existe uma biblioteca de registro separada para Go, existe uma biblioteca separada para PHP. Todos nós temos, todos deveriam usá-los. No momento, eu diria que estamos obtendo 80% de sucesso. Mas alguns continuam a comer cactos.
E aí (no slide) mal começa a aparecer o “SLA para entrega de logs”. Ainda não está lá, mas estamos trabalhando nisso. Porque é muito conveniente quando infra diz que se você escrever em tal e tal formato para tal e tal lugar e não mais do que N mensagens por segundo, provavelmente iremos entregá-lo lá. Tira muita dor de cabeça. Se houver um SLA, ótimo!
Como começamos a resolver o problema? O rake principal foi com td-agent. Não ficou claro para onde vão nossos logs. Eles são entregues? Eles estão indo? Onde eles estão afinal? Portanto, decidiu-se substituir td-agent pelo primeiro item. Opções para substituí-lo, descrevi brevemente aqui.
fluente Em primeiro lugar, encontrei-o em um emprego anterior, e ele também caía periodicamente lá. Em segundo lugar, é o mesmo, apenas de perfil.
filebeat. Como foi bom para nós? O fato dele estar no Go, e nós termos uma grande expertise em Go. Conseqüentemente, se houver alguma coisa, poderíamos de alguma forma adicioná-la a nós mesmos. Por isso não pegamos. Para que não houvesse nem mesmo a tentação de começar a reescrever você mesmo.
A solução óbvia para o administrador do sistema são todos os tipos de syslogs nessa quantidade (syslog-ng/rsyslog/nxlog).
Ou escreva algo de sua autoria, mas descartamos, assim como filebeat. Se você escreve algo, é melhor escrever algo útil para os negócios. Para entregar logs, é melhor levar algo pronto.
Portanto, a escolha na verdade se resumia a uma escolha entre syslog-ng e rsyslog. Eu me inclinei para o rsyslog simplesmente porque já tínhamos classes para rsyslog no Puppet e não encontrei uma diferença óbvia entre eles. O que é syslog, o que é syslog. Sim, algumas documentações são piores, outras melhores. Ele conhece esse caminho e o faz de maneira diferente.
E um pouco sobre rsyslog. Primeiro, é legal porque tem muitos módulos. Possui um RainerScript (linguagem de configuração moderna) legível por humanos. Um bônus incrível é que pudemos emular o comportamento do td-agent com suas ferramentas padrão e nada mudou para os aplicativos. Ou seja, mudamos td-agent para rsyslog e não tocamos em todo o resto ainda. E imediatamente recebemos uma entrega em funcionamento. Em seguida, mmnormalize é o legal do rsyslog. Ele permite que você analise logs, mas não com Grok e regexp. Faz uma árvore de sintaxe abstrata. Ele analisa os logs da mesma maneira que um compilador analisa as fontes. Isso permite que você trabalhe muito rápido, coma pouca CPU e, em geral, é uma coisa muito legal. Há um monte de outros bônus. Eu não vou me debruçar sobre eles.
rsyslog tem muito mais desvantagens. Eles são quase iguais aos bônus. Os principais problemas são que você precisa saber cozinhá-lo e selecionar uma versão.
Decidimos que escreveríamos logs em um soquete unix. E não em /dev/log, porque lá temos uma bagunça de logs do sistema, tem journald nesse pipeline. Então, vamos escrever em um soquete personalizado. Vamos anexá-lo a um conjunto de regras separado. Não vamos interferir em nada. Tudo será transparente e compreensível. Então nós realmente fizemos. O diretório com esses sockets é padronizado e encaminhado para todos os containers. Os contêineres podem ver o soquete de que precisam, abrir e gravar nele.
Por que não um arquivo? Porque todo mundo leu , que tentou encaminhar o arquivo para o docker e descobriu que, após reiniciar o rsyslog, o descritor do arquivo muda e o docker perde esse arquivo. Ele mantém aberto outra coisa, mas não o mesmo soquete onde eles escrevem. Decidimos que contornaríamos esse problema e, ao mesmo tempo, contornaríamos o problema de bloqueio.
O Rsyslog executa as ações indicadas no slide e envia logs para retransmissão ou Kafka. Kafka segue o caminho antigo. Rayleigh - tentei usar rsyslog puro para entregar logs. Sem fila de mensagens, usando ferramentas rsyslog padrão. Basicamente, funciona.
Mas há nuances sobre como enchê-los posteriormente nesta parte (Logstash/Graylog/ES). Esta parte (rsyslog-rsyslog) é usada entre datacenters. Aqui está um link tcp compactado, que permite economizar largura de banda e, consequentemente, aumentar de alguma forma a probabilidade de recebermos alguns logs de outro data center quando o canal estiver cheio. Porque temos a Indonésia, onde tudo é ruim. É aí que reside o problema constante.
Pensamos em como realmente monitoramos, com que probabilidade os logs que registramos do aplicativo chegam a esse fim? Decidimos começar as métricas. O Rsyslog possui seu próprio módulo de coleta de estatísticas, que possui algum tipo de contador. Por exemplo, pode mostrar o tamanho da fila ou quantas mensagens chegaram para tal e tal ação. Você já pode tirar algo deles. Além disso, conta com contadores customizados que você pode configurar, e te mostrará, por exemplo, a quantidade de mensagens que alguma API registrou. Em seguida, escrevi rsyslog_exporter em Python e enviamos tudo para o Prometheus e plotamos. Queríamos muito as métricas do Graylog, mas até agora não tivemos tempo de configurá-las.
Quais são os problemas? O problema surgiu com o fato de que descobrimos (DE REPENTE!) que nossas Live APIs gravam 50 mil mensagens por segundo. Esta é apenas a API ao vivo sem preparação. E o Graylog só nos mostra 12 mil mensagens por segundo. E surgiu uma pergunta razoável: onde estão os remanescentes? Do que concluímos que Graylog simplesmente não consegue lidar. Procuramos e, de fato, o Graylog com Elasticsearch não dominou esse fluxo.
A seguir, outras descobertas que fizemos ao longo do caminho.
As gravações no soquete estão bloqueadas. Como isso aconteceu? Quando usei o rsyslog para entrega, em algum momento quebramos o canal entre os data centers. A entrega subiu em um lugar, a entrega subiu em outro lugar. Tudo isso se resumiu a uma máquina com APIs que gravam no soquete rsyslog. Havia uma fila. Em seguida, a fila de gravação no soquete unix foi preenchida, que por padrão é de 128 pacotes. E o próximo write() nos blocos de aplicativos. Quando olhamos para a biblioteca que usamos nos aplicativos Go, foi escrito lá que a gravação no soquete ocorre no modo sem bloqueio. Tínhamos certeza de que nada estava bloqueado. Porque nós lemos quem escreveu sobre isso. Mas há um momento. Havia também um loop infinito em torno dessa chamada, na qual havia uma tentativa constante de enviar uma mensagem para o soquete. Nós não o notamos. Eu tive que reescrever a biblioteca. Desde então, mudou várias vezes, mas agora nos livramos dos bloqueios em todos os subsistemas. Portanto, você pode parar o rsyslog e nada cairá.
É preciso monitorar o tamanho das filas, o que ajuda a não pisar nesse ancinho. Primeiro, podemos monitorar quando começamos a perder mensagens. Em segundo lugar, podemos monitorar que basicamente temos problemas com a entrega.
E outro momento desagradável - a amplificação em 10 vezes em uma arquitetura de microsserviço é muito fácil. Não temos tantos pedidos recebidos, mas pelo gráfico ao longo do qual essas mensagens correm mais, por causa dos logs de acesso, na verdade aumentamos a carga nos logs em cerca de dez vezes. Infelizmente, não tive tempo de calcular os números exatos, mas os microsserviços são o que são. Isso deve ser mantido em mente. Acontece que no momento o subsistema de coleta de logs é o mais carregado no Lazada.
Como resolver o problema elasticsearch? Se você precisar obter logs rapidamente em um só lugar, para não correr em todas as máquinas e coletá-los lá, use o armazenamento de arquivos. Isso é garantido para funcionar. É feito de qualquer servidor. Você só precisa colocar discos lá e colocar syslog. Depois disso, você tem a garantia de ter todos os logs em um só lugar. Então será possível configurar lentamente elasticsearch, graylog ou qualquer outra coisa. Mas você já terá todos os logs e, além disso, poderá armazená-los, desde que haja matrizes de disco suficientes.
Na época do meu relatório, o esquema começou a ficar assim. Praticamente paramos de gravar no arquivo. Agora, provavelmente, desligaremos os remanescentes. Em máquinas locais que executam a API, pararemos de gravar nos arquivos. Primeiro, há o armazenamento de arquivos, que funciona muito bem. Em segundo lugar, essas máquinas estão constantemente ficando sem espaço, você precisa monitorá-las constantemente.
Esta parte com Logstash e Graylog, realmente sobe. Portanto, você precisa se livrar dele. Você tem que escolher um.
Decidimos abandonar Logstash e Kibana. Porque temos um departamento de segurança. Qual é a conexão? A conexão é que Kibana sem X-Pack e sem Shield não permite diferenciar direitos de acesso aos logs. Portanto, eles levaram Graylog. Tem tudo. Não gosto, mas funciona. Compramos um novo hardware, instalamos um Graylog novo lá e movemos todos os logs com formatos estritos para um Graylog separado. Resolvemos o problema com diferentes tipos dos mesmos campos organizacionalmente.
O que exatamente está incluído no novo Graylog. Acabamos de escrever tudo na janela de encaixe. Pegamos vários servidores, implementamos três instâncias Kafka, 7 servidores Graylog versão 2.3 (porque eu queria o Elasticsearch versão 5). Tudo isso foi levantado em ataques do HDD. Vimos uma taxa de indexação de até 100 mil mensagens por segundo. Vimos a figura de 140 terabytes de dados por semana.
E novamente um ancinho! Temos duas vendas chegando. Ultrapassamos os 6 milhões de postagens. Nós Graylog não temos tempo para mastigar. De alguma forma você tem que sobreviver novamente.
Foi assim que sobrevivemos. Adicionado mais alguns servidores e SSDs. No momento vivemos assim. Agora já estamos mastigando 160 mil mensagens por segundo. Ainda não atingimos o limite, então não está claro o quanto podemos realmente tirar disso.
Estes são os nossos planos para o futuro. Destes, realmente, o mais importante é provavelmente a alta disponibilidade. Ainda não temos. Vários carros são configurados da mesma maneira, mas até agora tudo está passando por um carro. É necessário gastar tempo para configurar um failover entre eles.
Colete métricas do Graylog.
Faça um limite de taxa para que tenhamos uma API maluca que não nos mate largura de banda e tudo mais.
E, finalmente, assinar algum tipo de SLA com os desenvolvedores para que possamos atender a isso. Se você escrever mais, desculpe.
E escrever documentação.
Resumidamente, os resultados de tudo o que vivemos. Primeiro, os padrões. Em segundo lugar, o syslog é um bolo. Em terceiro lugar, o rsyslog funciona exatamente como está escrito no slide. E vamos às perguntas.
perguntas.
pergunta: Por que eles decidiram não levar ... (filebeat?)
resposta: Precisa gravar em um arquivo. Eu realmente não queria. Quando sua API grava milhares de mensagens por segundo, mesmo que você alterne uma vez por hora, isso ainda não é uma opção. Você pode escrever para pipe. Ao que os desenvolvedores me perguntaram: “O que acontecerá se o processo em que escrevemos cair”? Só não achei o que responder, e disse: "Bem, ok, não vamos fazer isso."
pergunta: Por que você simplesmente não grava logs no HDFS?
respostaR: Esta é a próxima etapa. Pensamos nisso logo no início, mas como não há recursos para lidar com isso no momento, fica parado em nossa solução de longo prazo.
pergunta: um formato de coluna seria mais adequado.
resposta: Eu entendo. Somos "a favor" com as duas mãos.
pergunta: Você escreve para rsyslog. Ambos TCP e UDP estão disponíveis lá. Mas se UDP, então como você garante a entrega?
respostaR: Existem dois pontos. Em primeiro lugar, digo imediatamente a todos que não garantimos a entrega das toras. Porque quando os desenvolvedores vêm e dizem: “Vamos começar a escrever dados financeiros lá, e você vai colocar em algum lugar para nós caso algo aconteça”, nós respondemos: “Ótimo! Vamos começar a bloquear a gravação no soquete e fazer isso nas transações, para que você tenha a garantia de colocá-lo no soquete para nós e tenha certeza de que o recebemos do outro lado. E neste momento, todos imediatamente se tornam desnecessários. E se não, que perguntas temos? Se você não deseja garantir uma gravação no soquete, por que garantiríamos a entrega? Estamos fazendo o melhor esforço. Nós realmente tentamos entregar o máximo e o melhor possível, mas não damos 100% de garantia. Portanto, você não precisa gravar dados financeiros lá. Existem bancos de dados transacionais para isso.
pergunta: Quando a API gera alguma mensagem para o log e transfere o controle para os microsserviços, você já se deparou com o problema de mensagens de diferentes microsserviços chegarem na ordem errada? Por causa disso, surge a confusão.
respostaR: É normal que venham em uma ordem diferente. Você tem que estar pronto para isso. Porque qualquer entrega de rede não garante o pedido para você, ou você precisa gastar recursos especiais nisso. Se fizermos armazenamentos de arquivos, cada API salvará os logs em seu próprio arquivo. Em vez disso, o rsyslog os decompõe em diretórios lá. Cada API tem seus próprios logs lá, onde você pode ir e olhar, e então você pode compará-los usando o carimbo de data/hora neste log. Se eles procurarem no Graylog, eles serão classificados por timestamp. Tudo ficará bem lá.
pergunta: O timestamp pode variar em milissegundos.
resposta: O timestamp é gerado pela própria API. Este, de fato, é o ponto principal. Temos NTP. A API gera um timestamp já na própria mensagem. Não é adicionado pelo rsyslog.
pergunta: A interação entre data centers não é muito clara. Dentro da estrutura do data center, fica claro como os logs foram coletados e processados. Como é a interação entre os datacenters? Ou cada data center vive sua própria vida?
resposta: Quase. Temos cada país localizado em um data center. No momento, não temos espalhamento, de modo que um país é colocado em diferentes data centers. Portanto, não há necessidade de combiná-los. Dentro de cada centro existe um Log Relay. Este é um servidor Rsyslog. Na verdade, duas máquinas de gerenciamento. Eles são configurados da mesma maneira. Mas, por enquanto, o tráfego passa apenas por um deles. Ela registra tudo agregado. Tem uma fila de disco apenas no caso. Ela pressiona os logs e os envia para o data center central (Cingapura), onde ainda estão envenenados no Graylog. E cada centro de dados tem seu próprio armazenamento de arquivos. Caso tenhamos perdido a conexão, temos todos os logs lá. Eles vão ficar lá. Eles serão armazenados lá.
pergunta: Você obtém logs de lá durante situações anormais?
resposta: Você pode ir lá (para o armazenamento de arquivos) e olhar.
pergunta: Como você monitora para não perder logs?
resposta: Na verdade, estamos perdendo-os e estamos monitorando isso. O monitoramento começou há um mês. A biblioteca que as APIs Go usam tem métricas. Ela pode contar quantas vezes falhou ao escrever no soquete. No momento, há uma heurística complicada. Há um buffer lá. Ele tenta escrever uma mensagem dele para o soquete. Se o buffer estourar, ele começa a descartá-los. E ele conta quantos deixou cair. Se os contadores começarem a transbordar lá, saberemos disso. Agora eles também estão chegando ao prometheus, e você pode ver os gráficos no Grafana. Você pode configurar alertas. Mas ainda não está claro para quem enviá-los.
pergunta: No elasticsearch, você armazena logs com redundância. Quantas réplicas você tem?
resposta: Uma réplica.
pergunta: É apenas uma linha?
resposta: Este é o mestre e a réplica. Os dados são armazenados em duplicata.
pergunta: Você ajustou o tamanho do buffer rsyslog de alguma forma?
resposta: escrevemos datagramas em um soquete unix personalizado. Isso nos impõe imediatamente uma limitação de 128 kilobytes. Não podemos escrever mais nele. Nós escrevemos isso no padrão. Quem quer entrar no armazenamento, escreve 128 kilobytes. As bibliotecas, aliás, cortam e colocam uma bandeira de que a mensagem está cortada. Temos um campo especial no próprio padrão da mensagem, que mostra se ela foi cortada durante a gravação ou não. Então temos a oportunidade de acompanhar esse momento.
Pergunta: Você escreve JSON quebrado?
resposta: O JSON quebrado será descartado durante a retransmissão porque o pacote é muito grande. Ou o Graylog será descartado, porque não será capaz de analisar o JSON. Mas há nuances aqui que precisam ser corrigidas e estão principalmente ligadas ao rsyslog. Eu já preenchi algumas questões lá, que ainda precisam ser trabalhadas.
Pergunta: Por que Kafka? Você já experimentou o RabbitMQ? Graylog não se soma a tais cargas?
resposta: Não funciona com Graylog. E o Graylog está tomando forma. É realmente problemático para ele. Ele é uma coisa. E, de fato, não é necessário. Prefiro escrever de rsyslog diretamente para elasticsearch e depois assistir Kibana. Mas precisamos resolver o problema com os guardas de segurança. Esta é uma variante possível do nosso desenvolvimento quando descartamos o Graylog e usamos o Kibana. Logstash não fará sentido. Porque posso fazer o mesmo com rsyslog. E tem um módulo para escrever em elasticsearch. Com Graylog estamos tentando viver de alguma forma. Nós até ajustamos um pouco. Mas ainda há espaço para melhorias.
Sobre Kafka. Foi assim que aconteceu historicamente. Quando cheguei, já estava lá e os logs já estavam sendo gravados nele. Acabamos de criar nosso cluster e mover logs para ele. Nós o controlamos, sabemos como ele se sente. Quanto ao RabbitMQ... estamos tendo problemas com o RabbitMQ. E o RabbitMQ está desenvolvendo para nós. Nós o temos em produção e houve problemas com ele. Agora, antes da venda, ele seria xamanizado e começaria a trabalhar normalmente. Mas antes disso, eu não estava pronto para lançá-lo em produção. Tem mais uma coisa. O Graylog pode ler a versão AMQP 0.9 e o rsyslog pode gravar a versão AMQP 1.0. E não há uma solução única que possa fazer as duas coisas no meio. Existe um ou outro. Então, por enquanto, apenas Kafka. Mas também há nuances. Porque omkafka da versão do rsyslog que usamos pode perder todo o buffer de mensagens que ele pegou do rsyslog. Desde que aguentemos.
Pergunta: Você está usando Kafka porque você tinha? Não é usado para qualquer outra finalidade?
resposta: Kafka, que foi usado pela equipe de Data Science. Este é um projeto completamente separado, sobre o qual, infelizmente, não posso dizer nada. Não sei. Ela era dirigida pela equipe de ciência de dados. Quando os logs começaram, eles decidiram usá-lo, para não colocar os seus. Agora atualizamos o Graylog e perdemos a compatibilidade, porque existe uma versão antiga do Kafka. Tivemos que fazer o nosso. Ao mesmo tempo, eliminamos esses quatro tópicos para cada API. Fizemos um top largo para todos os shows, um top largo para todas as encenações e filmamos tudo lá. Graylog analisa tudo isso em paralelo.
Pergunta: Por que precisamos desse xamanismo com soquetes? Você já tentou usar o driver de log syslog para contêineres.
resposta: Na época em que fizemos essa pergunta, tínhamos relações tensas com o estivador. Era docker 1.0 ou 0.9. O próprio Docker era estranho. Em segundo lugar, se você também inserir logs nele ... Tenho uma suspeita não verificada de que ele passa todos os logs por si mesmo, por meio do daemon do docker. Se tivermos uma API enlouquecendo, o restante das APIs se deparará com o fato de que não podem enviar stdout e stderr. Não sei aonde isso vai levar. Tenho uma suspeita ao nível de sentir que não é necessário usar o driver docker syslog neste local. Nosso departamento de testes funcionais possui seu próprio cluster Graylog com logs. Eles usam drivers de log do docker e tudo parece estar bem lá. Mas eles imediatamente escrevem GELF para Graylog. No momento em que começamos tudo isso, precisávamos que funcionasse. Talvez mais tarde, quando alguém vier e disser que está funcionando normalmente há cem anos, tentemos.
Pergunta: Você entrega entre centros de dados usando rsyslog. Por que não em Kafka?
resposta: Nós fazemos isso, e é assim que realmente é. Por duas razões. Se o canal estiver completamente morto, todos os nossos logs, mesmo em um formato compactado, não passarão por ele. E kafka permite que eles simplesmente percam no processo. Desta forma, nos livramos da aderência dessas toras. Estamos apenas usando Kafka neste caso diretamente. Se tivermos um bom canal e quisermos liberá-lo, usaremos o rsyslog deles. Mas, na verdade, você pode configurá-lo para que ele abandone o que não passou. No momento, estamos apenas usando a entrega rsyslog diretamente em algum lugar, em algum lugar Kafka.
Fonte: habr.com