Revisão de código - prática de engenharia em termos de uma metodologia de desenvolvimento flexível. Esta é uma análise (inspeção) do código para identificar erros, deficiências, discrepâncias no estilo de escrever código e entender se o código resolve a tarefa.

Hoje vou falar sobre como organizamos o processo de revisão para monitorar a configuração no Zabbix. Este artigo será útil para quem trabalha com o sistema de monitoramento Zabbix, em uma equipe grande e sozinho, mesmo se você tiver "dez hosts, o que há para revisar".

Que problemas resolvemos

Para monitorar nossos serviços internos e criar infraestrutura, usamos o Zabbix. Temos convenções de nomenclatura - convenção de nome ( usamos um modelo com destaque de função, modelos de perfil para monitoramento), mas não há uma equipe de monitoramento dedicada (há engenheiros seniores que “comeram o cachorro” em assuntos de monitoramento), existem engenheiros e engenheiros juniores, ~ 500 hosts, ~ 150 modelos (infraestrutura pequena, mas muito dinâmica).

Essa infraestrutura é usada para apoiar e automatizar processos de desenvolvimento na empresa , além de seu suporte, também desenvolvemos ferramentas de automação e integração, portanto, temos pouca experiência e entendimento dos processos de desenvolvimento por dentro.

Com o aumento do número de funcionários e as alterações introduzidas no sistema de monitoramento, começaram a ocorrer mais e mais erros típicos que eram difíceis de rastrear:

1. Item de ligação, acionado diretamente para hosts, fora dos modelos (e alguns hosts permanecem não monitorados).
2. Valor incorreto dos gatilhos (meio que concordamos com um espaço disponível de 3 GB, mas um erro de digitação, temos um gatilho que nunca funciona de 34 GB).
3. Falha no cumprimento da convenção de nome - e obtemos o gatilho com falha do nome incompreensível do script (embora isso signifique que o sistema de entrega de atualizações não funciona) ou o modelo de modelos do Gitlab (monitoramento de qual servidor ou agente?).
4. Desativando um gatilho, temporário, para testes. Como resultado, perdemos o aviso na infraestrutura e nos levantamos.

No mundo dos programadores, todos esses problemas são resolvidos de maneira bem simples: linter, codeereview. Então, por que não seguir essas práticas recomendadas para uma revisão da configuração do Zabbix? Pegue!

Já escrevemos anteriormente sobre os profissionais e exemplos de revisão de código: Implementando inspeções de código no processo de desenvolvimento , Um exemplo prático de implementação de inspeção de código, Inspeção de código . Sumário

Por que você pode precisar de uma revisão das configurações do Zabbix:

• Verifique se os hosts e modelos são nomeados conforme aceitos no comando ( convenção de nomes ).
• Treine novos funcionários e verifique se eles executaram a tarefa conforme discutido.
• Transferir conhecimento entre funcionários experientes.
• O aviso é acionado acidentalmente ou temporariamente.
• Observe valores incorretos no item ou gatilho - último (0) em vez de min (5m) .

Adicione seus problemas nos comentários, tente descobrir juntos como resolvê-los com revisão.

Como o Zabbix com rastreamento de alterações

O Zabbix possui um subsistema de auditoria , com sua ajuda, examinamos quem fez as alterações na configuração. Sua desvantagem significativa é o grande número de eventos salvos, pois salva cada evento do usuário.

Imagine que qualquer alteração no código permaneça no histórico do git, você tentou pegar o nome da variável por uma hora, tentou 40 opções e agora todas são salvas, cada alteração é uma confirmação separada e, em seguida, envia o histórico dessas confirmações para a revisão, sem a capacidade de comparar o início e o final versão. Horrível, certo?

E no Zabbix Audit, isso mesmo. Ele pode ser usado para rastrear alterações, mas não permite que você veja rapidamente a diferença (diff) entre os dois estados do sistema (no início da semana e no final). Além disso, todas as suas ações são divididas por tipo: adicionar, alterar, excluir devem ser visualizadas em janelas diferentes. Um exemplo pode ser encontrado no seu Zabbix na guia Auditoria (ou veja a captura de tela). É difícil entender qual estado é inicial, o que é atual, quais foram as mudanças durante a semana. A situação é complicada quando temos dezenas de alterações por semana.

Eu quero um mecanismo que permita:

1. Uma vez por semana ou após concluir a tarefa de alterar a lógica de monitoramento, faça uma conversão do status do sistema.
2. Compare o nugget de configuração atual com o nugget anterior (diff).
3. Verifique automaticamente a convenção de nomes.
4. Verifique a qualidade da tarefa, dê recomendações, conselhos, discuta soluções.
5. Verifique se as alterações são legítimas - todas são feitas de acordo com a tarefa.
6. Use ferramentas familiares para desenvolvedores - git, diff, mergerequest.
7. Reverta para algum estado do sistema, mas não perca dados (portanto, o backup não é adequado).
8. Controle as entidades do Zabbix - host, modelos, ação, macros, tela, mapa.

Agora vamos falar sobre como implementamos o mecanismo e como ele pode ser útil para sua infraestrutura Zabbix.

Fazendo uma revisão da configuração do Zabbix

Para armazenar a configuração do Zabbix, usamos os seguintes formatos:

1. XML original - exportado usando o Zabbix Export original. Use para host, modelo, objetos de tela. Existem recursos:
   
   • XML é difícil de ler e visualizar alterações;
   • conter todos os campos, incluindo os vazios;
   • contenha a data do campo - a data da exportação, cortamos.
2. JSON bruto - alguns tipos de objetos que o Zabbix não sabe exportar (ações, tipos de mídia), mas são importantes e eu quero ver as alterações. Portanto, pegamos os dados brutos do ZabbixAPI e salvamos no JSON.
3. YAML legível - processamos o XML exportado e o JSON bruto e o salvamos em YAML de fácil leitura, conveniente e fácil de usar. Com isso, é fácil lidar com grandes volumes de mudança com seus olhos. Adicione um pequeno processamento lá:
   
   • A remoção de campos sem valores é um ponto discutível, portanto, podemos pular um campo vazio, embora deva ser preenchido, por exemplo, um campo com uma descrição do problema no gatilho (trigger.description). Após a discussão, foi decidido que seria melhor remover os campos vazios, existem muitos deles. Se desejar, você pode colocar uma exceção em alguns campos vazios e não excluí-los.
   • Excluímos datas - elas mudam sempre e quando as solicitações de mesclagem são mostradas como alterações para cada host.
   • Como opção, você pode adicionar outras operações para o preenchimento de informações - o ID do usuário é gravado em ação, em vez dos usuários, por exemplo.

Nós distinguimos três repositórios git (usamos o gitlab para armazenamento, mas qualquer VCS o fará):

1. zabbix-review-export - isso armazenará o código de exportação (scripts Python) e os parâmetros para tarefas do gitlab-ci.
2. zabbix-xml - armazenamos XML + JSON, tudo em um único ramo. A revisão deste negócio é difícil e demorada. Usado para restaurar o status da configuração do Zabbix por um tempo específico.
3. O zabbix-yaml é o nosso repositório principal. Aqui, mesclamos solicitações, vemos as alterações, discutimos as decisões tomadas, mesclamos no master se não houver comentários.

Nesses repositórios, salvamos os dados de configuração, as regras são as seguintes:

• agrupamento por tipo de objeto por pasta - lista completa: https://gitlab.com/devopshq/zabbix-review-export#supported-objects
• um objeto - um arquivo.

Agora vemos claramente que tipo de objeto mudou e está claro qual objeto mudou; No exemplo abaixo, o modelo de perfil foi alterado . Scmdev. FlusContinuousTest .

Mostrar em exemplos

Para visualizar as alterações, usamos o mecanismo de solicitação de mesclagem no gitlab.

O modelo de perfil foi alterado . DevOps. Teste - alterou a expressão do acionador. Modelo, como está na pasta de modelos :

A expressão foi alterada no gatilho e na prioridade:

Link para um modelo outro:

A ação foi alterada - adicionada uma nova linha ao final do texto por padrão:

Um exemplo de discussões nas solicitações de mesclagem (tudo é parecido com os programadores!) - pode-se ver que eles conectaram o modelo padrão diretamente ao host, mas vale a pena destacar um papel separado para o futuro. Captura de tela da revisão antiga e ainda usando a representação XML da configuração.

Em geral, tudo é simples:

1. Adicionado um novo host ou outro objeto - um novo arquivo foi criado.
2. Mudou o host ou outro objeto - parecia diff.
3. Excluído - o arquivo foi excluído.

Suponha que você tenha concluído uma tarefa e queira pedir a um colega para ver se você esqueceu alguma coisa. Solicitamos uma revisão: para isso, no repositório zabbix-review-export , execute o trabalho gitlab-ci com um início manual.

Atribuímos uma solicitação de mesclagem a um colega que analisa, discute e corrige a infraestrutura de monitoramento de código.

Uma vez por semana, uma nova revisão é lançada para rastrear pequenas alterações. Para isso, de acordo com o cronograma ( Agenda ), a configuração é exportada e salva no repositório git (com uma nova confirmação) e o guru de monitoramento revisa as alterações.

Você se espalha gentilmente, mas precisa tentar

Agora, mostraremos como configurar esse sistema para a revisão da configuração do Zabbix ( adoramos o código aberto e tentamos compartilhar nossas melhores práticas com a comunidade).

Existem dois usos possíveis:

1. Basta executar o script de exportação manualmente - execute o script, veja as alterações, faça o git add * && git commit && git push . Essa opção é adequada para alterações raras ou quando você estiver trabalhando apenas com um sistema de monitoramento.
2. Use o gitlab-ci para automação - basta clicar no botão Iniciar (veja a captura de tela acima). A opção é mais adequada para grandes preguiçoso equipes ou com mudanças frequentes.

Ambas as opções são descritas no repositório https://gitlab.com/devopshq/zabbix-review-export , tudo o que você precisa é armazenado lá - configurações de scripts, gitlab-ci e README.md, como colocar em sua infraestrutura.

Primeiro, tente a primeira opção (ou se você não possui a infraestrutura gitlab-ci): use o modo manual - execute o script zabbix-export.py para exportar (fazer backup) da configuração, git add * && git commit && git push em sua máquina de trabalho. Quando estiver cansado, vá para a segunda opção - automatize a automação!

Problemas e possíveis melhorias

Agora as alterações são despersonalizadas e para descobrir quem fez as alterações, você precisa usar o sistema de auditoria , que causa dor e sofrimento. Mas nem tudo é tão assustador, e a auditoria raramente é necessária; geralmente, uma mensagem no bate-papo da equipe é suficiente para encontrar o funcionário certo.

Outro problema: quando um host ou item é alterado em um host, ele não está contido no XML. Ou seja, podemos desativar todos os gatilhos em um host específico ou alterar sua prioridade para um menor - e ninguém saberá sobre isso e nos corrigirá! Estamos aguardando uma correção para isso em https://support.zabbix.com/browse/ZBX-15175

Até que eles inventaram um mecanismo para recuperação automática. Suponhamos que um modelo ou host tenha sido fortemente alterado, entendemos que as alterações estão incorretas e você precisa retornar tudo como estava. Agora, estamos procurando o XML necessário para o host correspondente, importando-o manualmente para a interface do usuário, mas gostaríamos de clicar no botão "Reverter o modelo TemplateName para o estado de confirmação de commit-hash".

Você pode implementar a sincronização bidirecional - quando são feitas alterações na configuração do Zabbix quando são feitas no YAML, não é necessário acessar a interface da web do sistema Zabbix. No github, encontramos um projeto semelhante, mas de alguma forma ele desapareceu rapidamente e a comunidade não aceitou a idéia; aparentemente, não é tão fácil implementar no YAML o que você pode clicar com o mouse na interface da web. Portanto, decidimos pela interação unidirecional.

A opção ideal é incorporar esse sistema para salvar a configuração como código, mesmo que apenas no formato XML, no Zabbix. Como isso é feito no servidor TeamCity CI : as configurações configuradas pela interface do usuário confirmam em nome do usuário que alterou a configuração. Ele é uma ferramenta muito conveniente para visualizar alterações e também elimina o problema de despersonalizar alterações.

Experimente

Comece a exportar sua configuração do Zabbix, confirme em um repositório (local o suficiente), aguarde uma semana e execute novamente. Agora as mudanças estão sob seu controle! https://gitlab.com/devopshq/zabbix-review-export

Quem estaria interessado nessa funcionalidade na caixa do Zabbix - vote no problema https://support.zabbix.com/browse/ZBXNEXT-4862

Todo o tempo de atividade 100%!