Um grande número de sistemas de registro é apresentado no mercado - aberto e proprietário. Cada um deles tem sua própria funcionalidade, suas próprias vantagens e desvantagens.
Hoje decidimos compartilhar nossa experiência na escolha de um sistema de registro e nos dizer por que paramos na ELK no
1cloud .
/ Pixabay / picupyourphoto / PDTeoria dos minutos
Ao mudar para a produção, os aplicativos se transformam em uma espécie de "caixas pretas". Seu trabalho precisa ser constantemente monitorado para prevenir e responder a possíveis situações de emergência, para detectar gargalos.
Os sistemas de registro são uma ferramenta indispensável que não pode ser evitada nesse processo. Ao realizar uma análise detalhada dos dados coletados, é possível identificar “intrusões” na rede, identificar equipamentos configurados incorretamente e executar ações imediatas. Além disso, o registro é um requisito obrigatório ao passar vários tipos de certificações, como o PCI DSS.
Existem estruturas especiais para automação dos processos de registro: log4j, log4net, Retrace, Logback, Logstash e outros - existem muitos. Suas ferramentas de log têm ferramentas de desenvolvimento separadas, por exemplo, JDK -
existe java.util.logging . Obviamente, a funcionalidade de várias ferramentas de registro é diferente e o conjunto necessário de funções deve ser selecionado com base nos requisitos dos negócios. No entanto, há vários pontos gerais que devem ser observados ao escolher um sistema para analisar logs.
Facilidade de uso e tamanho da comunidade
A simplicidade é um dos principais componentes ao escolher um sistema de registro. Todos os desenvolvedores da equipe trabalham com estruturas de log; portanto, a experiência de usar essa ferramenta deve ser positiva e não transformar a análise de log em um pesadelo. A API da estrutura deve ser intuitiva para que todos que não trabalharam com o sistema antes possam descobrir rapidamente como ele está organizado e configurado.
Se considerarmos o sistema de registro de código aberto, faz sentido avaliar a comunidade que se formou em torno dele. Para fazer isso, você pode estudar com que frequência é mencionado em plataformas especializadas (
Stack Overflow ), bem como em threads especializados,
por exemplo, no Reddit . Como opção, observe a popularidade do projeto no GitHub (o número de estrelas) e veja com que frequência ele é inserido em várias coleções de ferramentas na rede (
como estas ). Obviamente, quanto maior a comunidade, maior a probabilidade de você ser ajudado em caso de dificuldades imprevistas.
Quanto à escolha de sistemas proprietários de registro, vale a pena observar primeiro a velocidade das respostas e a adequação do serviço de suporte da solução selecionada, bem como o seu preço.
A capacidade de coletar logs "diversos"
Nem todas as plataformas de registro são capazes de processar uma grande quantidade de dados e fornecer informações completas sobre os sistemas utilizados.
Antes de escolher uma solução, você deve decidir quais logs planeja coletar: logs HTTP (ajudará a entender o comportamento dos usuários no site), logs da API (possibilitarão avaliar quais serviços são mais solicitados pela API), logs de erros e simplesmente registrar alterações no sistema (indique gargalos, se houver).
Escalabilidade
A ferramenta de log deve coletar logs de cada componente do sistema e fornecer acesso a eles em um único local. Se o sistema não for adequado para escala, a qualidade da análise de log diminuirá.
Inicialmente, no 1cloud, usamos o MS SQL para registro. No entanto, com um aumento no número de clientes e serviços (por exemplo, mais recentemente
implantamos equipamentos no data center de Minsk e
adicionamos suporte ao IPv6 ), desenvolvemos componentes de infraestrutura geograficamente dispersos que não tinham acesso ao banco de dados. E uma de nossas principais tarefas era manter a capacidade de analisar logs de um único local.
Sistema de registro 1cloud
Como já observamos, o MS SQL foi usado para armazenar logs no 1cloud e o log4net foi usado para gravá-los. E isso começou a criar certas dificuldades para nós. Devido a componentes geograficamente dispersos, tornou-se impossível manter a conectividade de rede com o banco de dados e fornecer um ponto único para análise.
Ao mesmo tempo, um grande volume de logs e a incapacidade de criar índices em todos os campos que precisamos procurar resultaram em simplificação excessiva da análise de logs - tivemos que abandonar a funcionalidade por uma questão de desempenho.
Para resolver esse problema e fornecer escalabilidade, introduzimos um novo sistema de registro. No total, estudamos mais de cinquenta soluções diferentes e identificamos quatro que atendiam totalmente aos nossos requisitos:
- local único para armazenar registros;
- escala horizontal do sistema, se necessário;
- processar grandes quantidades de dados;
- poderoso sistema de análise de logs.
Essas quatro soluções são: Fluentd, Graylog, Logalyse e Logstash.
A solução possui 9,2 mil estrelas no
GitHub . O Logstash é licenciado sob a licença Apache 2.0 e faz parte da pilha ELK. Possui um grande número de plugins (
existem cerca de 250 deles no GitHub). Funciona em Windows e Linux e possui alto desempenho, praticamente independente dos volumes de dados.
O sistema
permite que você revise e analise rapidamente eventos de estações de trabalho, firewalls, roteadores e switches. Isso se deve ao fato de não haver necessidade de "normalização" dos eventos.
No entanto, deve-se entender que esse é um mecanismo "vazio", porque não fornece visualizações prontas. Entre outras deficiências, notamos a necessidade de instalar o Java em todos os servidores, pois o Logstash é escrito em Ruby (JRuby).
A solução tem uma comunidade bastante grande: existe um
canal de IRC e um
fórum separado. Existem exemplos na rede para a
configuração de todo o sistema e
API .
As seguintes organizações
usam o Logstash: CERN Control Center, GitHub, SoundCloud.
6,6 mil estrelas no
GitHub . Distribuído sob a licença Apache 2.0 pela
CNCF (Cloud Native Computing Foundation) - foi
fundado pelo Google e pela Linux Foundation para promover a tecnologia de contêineres.
O Fluentd é executado no Linux, Windows e Mac e é escrito em Ruby (CRuby). O Fluentd possui um
sistema de plugins flexível que amplia sua funcionalidade.
A solução possui um formato de registro unificado: O Fluentd tenta converter os dados recebidos no formato JSON. Para garantir uma operação confiável, não são necessárias soluções de terceiros, no entanto, para isso, é necessário realizar configurações adicionais. Também não é recomendável instalá-lo em servidores que geram logs.
A comunidade é grande: há um
canal no Slack e também um
segmento nos Grupos do Google . No site oficial do projeto,
existem exemplos de configurações e
APIs . Empresas como Microsoft, Amazon, change.org e Nintendo usam o Fluentd.
4,3 mil estrelas no
GitHub . Distribuído sob a licença GNU GPL v3. Funciona apenas no Linux. Um
ecossistema centralizado
de plugins e um sistema de buffer personalizado. Por conveniência, ele permite que a palavra-chave combine mensagens recebidas em fluxos e agrupe esses fluxos de hosts diferentes.
O sistema usa as funções do Elasticsearch, mas, apesar das atualizações frequentes do Graylog e da comunidade desenvolvida (há um
fórum , um
canal de IRC ,
há exemplos de configurações e
APIs no site oficial do projeto), a integração das versões atuais do Elasticsearch ao projeto leva muito tempo. Por exemplo, no ano passado surgiu uma situação em que o Graylog 2.2.1 (o último na época)
trabalhava apenas com o Elasticsearch versão 2.4.4, que era considerado obsoleto.
Em seu trabalho, Graylog
usa a Agência Europeia do Meio Ambiente, Dial Once, Stockopedia e outros.
Ele funciona no Linux e Windows. O sistema possui alto desempenho e pode gerar relatórios detalhados sobre palavras-chave. Existe uma desvantagem séria: o LOGalyze coleta os logs em seu banco de dados de arquivos, onde os indexa, ocupando uma quantidade significativa de espaço em disco.
Os desenvolvedores do LOGalyze
têm seu próprio blog e a discussão da solução ocorre nos
grupos do Google . Há um guia
para configuração do sistema e
migração de dados, bem como a
CLI .
Após avaliar essas quatro opções, optamos pelo Logstash e decidimos organizar uma pilha ELK (ElasticSearch, Logstash, Kibana). Destes, o Elasticsearch é um mecanismo de pesquisa, o Logstash é um mecanismo para coletar e analisar logs e o Kibana está envolvido na análise e visualização de dados.
Escolhemos o ELK, já que todos os três componentes são desenvolvidos por um "fabricante", portanto, eles se integram bem. Se necessário, podemos usar cada uma dessas ferramentas individualmente para resolver outros problemas.
Essa abordagem torna o produto flexível e versátil. Tudo isso permitirá um processamento mais eficiente dos volumes de dados existentes e uma implementação mais rápida de novos serviços - será mais fácil conectar-se.
Agora o ambiente de teste está pronto. Ele “cobre” todos os serviços cujos logs iremos analisar. Estamos finalizando os últimos processos de depuração e planejando um lançamento completo da solução em um futuro próximo.
A propósito, apesar de termos analisado várias opções em detalhes e escolhido a melhor para as nossas necessidades, no final, não foi sem uma mosca na pomada. Ao testar a solução, fomos confrontados com uma situação em que o Kibana descartou o Elasticsearch por solicitação - que é considerado um caso extremamente raro e degenerado. Também durante a "montagem" do sistema, surgiram várias perguntas, principalmente relacionadas à segurança. Na versão básica, o Elasticsearch não está protegido por nada - era necessário adaptar o software de terceiros para esses fins.
Após o lançamento, configuraremos sistemas de monitoramento para responder o mais rápido possível às falhas no serviço de log. Esperamos que a nova pilha de tecnologia melhore a experiência do usuário de nossos clientes e desenvolva ainda mais nossos serviços mais rapidamente.
Materiais do nosso blog corporativo: