Pensamos em criar um sistema de monitoramento na fase de formação das equipes de produto. Ficou claro que o nosso negócio – a exploração – não se enquadra nessas equipes. Por que é que?
O fato é que todas as nossas equipes são construídas em torno de sistemas de informação, microsserviços e frentes individuais, de modo que as equipes não veem a saúde geral de todo o sistema como um todo. Por exemplo, eles podem não saber como uma pequena parte no back-end profundo afeta o front-end. O seu âmbito de interesse é limitado aos sistemas com os quais o seu sistema está integrado. Se uma equipe e seu serviço A quase não têm conexão com o serviço B, então tal serviço é quase invisível para a equipe.
Nossa equipe, por sua vez, trabalha com sistemas fortemente integrados entre si: há muitas conexões entre eles, é uma infraestrutura muito grande. E o funcionamento da loja online depende de todos estes sistemas (dos quais temos, aliás, um grande número).
Acontece que nosso departamento não pertence a nenhuma equipe, mas está um pouco afastado. Em toda essa história, nossa tarefa é entender de forma abrangente como funcionam os sistemas de informação, suas funcionalidades, integrações, software, rede, hardware e como tudo isso está conectado entre si.
A plataforma em que operam nossas lojas online é assim:
- frente
- escritorio do meio
- back-office
Por mais que queiramos, não acontece que todos os sistemas funcionem de maneira suave e perfeita. A questão, novamente, é a quantidade de sistemas e integrações – com algo como o nosso, alguns incidentes são inevitáveis, apesar da qualidade dos testes. Além disso, tanto dentro de um sistema separado como em termos de sua integração. E você precisa monitorar o estado de toda a plataforma de forma abrangente, e não apenas de qualquer parte individual dela.
Idealmente, o monitoramento da integridade de toda a plataforma deve ser automatizado. E chegamos ao monitoramento como uma parte inevitável desse processo. Inicialmente, ele foi construído apenas para a linha de frente, enquanto especialistas em redes, administradores de software e hardware tinham e ainda têm seus próprios sistemas de monitoramento camada por camada. Todas essas pessoas seguiram o monitoramento apenas no seu próprio nível; ninguém tinha uma compreensão abrangente também.
Por exemplo, se uma máquina virtual travar, na maioria dos casos apenas o administrador responsável pelo hardware e pela máquina virtual saberá disso. Nesses casos, a equipe da linha de frente viu o próprio fato da falha do aplicativo, mas não tinha dados sobre a falha da máquina virtual. E o administrador pode saber quem é o cliente e ter uma ideia aproximada do que está rodando atualmente nessa máquina virtual, desde que seja algum tipo de projeto grande. Ele provavelmente não sabe sobre os pequenos. De qualquer forma, o administrador precisa ir até o proprietário e perguntar o que havia nesta máquina, o que precisa ser restaurado e o que precisa ser alterado. E se algo realmente sério falhasse, eles começavam a andar em círculos - porque ninguém via o sistema como um todo.
Em última análise, essas histórias díspares afetam todo o frontend, os usuários e nossa função principal de negócios – vendas online. Como não fazemos parte de uma equipa, mas estamos envolvidos no funcionamento de todas as aplicações de comércio eletrónico no âmbito de uma loja online, assumimos a tarefa de criar um sistema de monitorização abrangente para a plataforma de comércio eletrónico.
Estrutura e pilha do sistema
Começamos identificando diversas camadas de monitoramento para nossos sistemas, dentro das quais precisaríamos coletar métricas. E tudo isso precisava ser combinado, que foi o que fizemos na primeira etapa. Agora, nesta fase, estamos finalizando a coleta de métricas da mais alta qualidade em todas as nossas camadas, a fim de construir uma correlação e compreender como os sistemas influenciam uns aos outros.
A falta de um monitoramento abrangente nas fases iniciais de lançamento do aplicativo (desde que começamos a construí-lo quando a maioria dos sistemas estava em produção) fez com que tivéssemos um débito técnico significativo para configurar o monitoramento de toda a plataforma. Não podíamos dar-nos ao luxo de nos concentrarmos na criação de monitorização para um SI e no trabalho detalhado de monitorização do mesmo, uma vez que os restantes sistemas ficariam sem monitorização durante algum tempo. Para resolver este problema, identificamos uma lista das métricas mais necessárias para avaliar o estado do sistema de informação por camada e começamos a implementá-la.
Portanto, eles decidiram comer o elefante em partes.
Nosso sistema consiste em:
- hardware;
- sistema operacional;
- software;
- Partes de UI no aplicativo de monitoramento;
- métricas de negócios;
- aplicações de integração;
- segurança da informação;
- redes;
- balanceador de tráfego.
No centro deste sistema está o próprio monitoramento. Para entender de maneira geral o estado de todo o sistema, você precisa saber o que está acontecendo com os aplicativos em todas essas camadas e em todo o conjunto de aplicativos.
Então, sobre a pilha.
Usamos software de código aberto. No centro temos o Zabbix, que usamos principalmente como sistema de alerta. Todos sabem que é ideal para monitoramento de infraestrutura. O que isto significa? Exatamente aquelas métricas de baixo nível que toda empresa que mantém seu próprio data center possui (e a Sportmaster tem seus próprios data centers) - temperatura do servidor, status da memória, raid, métricas de dispositivos de rede.
Integramos o Zabbix com o Telegram Messenger e o Microsoft Teams, que são usados ativamente em equipes. O Zabbix cobre a camada da rede real, hardware e alguns softwares, mas não é uma panacéia. Enriquecemos esses dados com alguns outros serviços. Por exemplo, no nível do hardware, nos conectamos diretamente via API ao nosso sistema de virtualização e coletamos dados.
O que mais. Além do Zabbix, utilizamos o Prometheus, que nos permite monitorar métricas em um ambiente dinâmico de aplicação. Ou seja, podemos receber métricas de aplicativos por meio de um endpoint HTTP e não nos preocupar com quais métricas carregar nele e quais não. Com base nesses dados, consultas analíticas podem ser desenvolvidas.
As fontes de dados para outras camadas, por exemplo, métricas de negócios, são divididas em três componentes.
Em primeiro lugar, são sistemas de negócios externos, Google Analytics, coletamos métricas de logs. Deles obtemos dados sobre usuários ativos, conversões e tudo mais relacionado ao negócio. Em segundo lugar, este é um sistema de monitoramento de IU. Deve ser descrito com mais detalhes.
Era uma vez, começamos com testes manuais e evoluímos para testes automáticos de funcionalidades e integrações. A partir disso fizemos o monitoramento, deixando apenas as funcionalidades principais, e contamos com marcadores que sejam o mais estáveis possível e não mudem frequentemente ao longo do tempo.
A nova estrutura de equipe significa que todas as atividades de aplicação estão confinadas às equipes de produto, por isso paramos de fazer testes puros. Em vez disso, fizemos o monitoramento da UI a partir dos testes, escritos em Java, Selenium e Jenkins (usados como sistema de lançamento e geração de relatórios).
Fizemos muitos testes, mas no final decidimos seguir pelo caminho principal, a métrica de nível superior. E se tivermos muitos testes específicos, será difícil manter os dados atualizados. Cada versão subsequente irá quebrar significativamente todo o sistema, e tudo o que faremos é consertar isso. Portanto, nos concentramos em coisas muito fundamentais que raramente mudam, e apenas as monitoramos.
Finalmente, em terceiro lugar, a fonte de dados é um sistema de registo centralizado. Usamos o Elastic Stack para logs e, então, podemos inserir esses dados em nosso sistema de monitoramento para métricas de negócios. Além de tudo isso, temos nosso próprio serviço de API de monitoramento, escrito em Python, que consulta quaisquer serviços via API e coleta dados deles no Zabbix.
Outro atributo indispensável do monitoramento é a visualização. O nosso é baseado no Grafana. Destaca-se entre outros sistemas de visualização por permitir visualizar métricas de diferentes fontes de dados no dashboard. Podemos coletar métricas de nível superior para uma loja online, por exemplo, o número de pedidos feitos na última hora do SGBD, métricas de desempenho para o sistema operacional no qual esta loja online está sendo executada do Zabbix e métricas para instâncias deste aplicativo de Prometeu. E tudo isso estará em um painel. Claro e acessível.
Deixe-me observar sobre a segurança - estamos atualmente finalizando o sistema, que posteriormente integraremos ao sistema de monitoramento global. Na minha opinião, os principais problemas que o comércio eletrónico enfrenta no domínio da segurança da informação estão relacionados com bots, analisadores e força bruta. Precisamos ficar atentos a isso, pois tudo isso pode afetar criticamente tanto a operação de nossas aplicações quanto a nossa reputação do ponto de vista empresarial. E com a pilha escolhida cobrimos essas tarefas com sucesso.
Outro ponto importante é que a camada de aplicação é montada pelo Prometheus. Ele próprio também está integrado ao Zabbix. E também temos o sitespeed, um serviço que nos permite visualizar parâmetros como velocidade de carregamento da nossa página, gargalos, renderização da página, carregamento de scripts, etc., também é integrado à API. Então nossas métricas são coletadas no Zabbix e, consequentemente, também alertamos a partir daí. Todos os alertas são atualmente enviados para os principais métodos de envio (por enquanto é e-mail e telegrama, o MS Teams também foi conectado recentemente). Existem planos para atualizar os alertas para um estado em que os bots inteligentes funcionem como um serviço e forneçam informações de monitoramento a todas as equipes de produtos interessadas.
Para nós, as métricas são importantes não apenas para sistemas de informação individuais, mas também métricas gerais para toda a infraestrutura que as aplicações utilizam: clusters de servidores físicos nos quais as máquinas virtuais rodam, balanceadores de tráfego, Network Load Balancers, a própria rede, utilização de canais de comunicação . Além de métricas para nossos próprios data centers (temos vários deles e a infraestrutura é bastante grande).
As vantagens do nosso sistema de monitorização são que, com a sua ajuda, vemos o estado de saúde de todos os sistemas e podemos avaliar o seu impacto uns sobre os outros e sobre os recursos partilhados. E, em última análise, permite-nos envolver-nos no planeamento de recursos, que também é da nossa responsabilidade. Gerenciamos recursos de servidor - um pool dentro do comércio eletrônico, comissionamos e desativamos novos equipamentos, compramos novos equipamentos adicionais, conduzimos uma auditoria de utilização de recursos, etc. Todos os anos, as equipas planeiam novos projetos, desenvolvem os seus sistemas e é importante para nós fornecer-lhes recursos.
E com a ajuda de métricas, vemos a tendência de consumo de recursos pelos nossos sistemas de informação. E com base neles podemos planejar algo. Ao nível da virtualização, recolhemos dados e visualizamos informações sobre a quantidade de recursos disponíveis por data center. E já dentro do data center você pode ver a reciclagem, a própria distribuição e consumo de recursos. Além disso, tanto com servidores autônomos quanto com máquinas virtuais e clusters de servidores físicos nos quais todas essas máquinas virtuais giram vigorosamente.
Perspectivas
Agora temos o núcleo do sistema como um todo pronto, mas ainda há muitas coisas que precisam ser trabalhadas. No mínimo, esta é uma camada de segurança da informação, mas também é importante para chegar à rede, desenvolver alertas e resolver a questão da correlação. Temos muitas camadas e sistemas e em cada camada há muito mais métricas. Acontece que é uma matryoshka no nível de uma matryoshka.
Nossa tarefa é, em última análise, fazer os alertas corretos. Por exemplo, se houvesse um problema com o hardware, novamente, com uma máquina virtual, e houvesse um aplicativo importante e não fosse feito backup do serviço de forma alguma. Descobrimos que a máquina virtual morreu. Então as métricas de negócios irão alertá-lo: os usuários desapareceram em algum lugar, não há conversão, a UI na interface está indisponível, software e serviços também morreram.
Nessa situação receberemos spam de alertas, e isso não cabe mais no formato de um sistema de monitoramento adequado. Surge a questão da correlação. Portanto, o ideal é que nosso sistema de monitoramento diga: “Gente, sua máquina física morreu, e junto com ela esse aplicativo e essas métricas”, com a ajuda de um alerta, em vez de nos bombardear furiosamente com uma centena de alertas. Deve relatar o principal - a causa, o que ajuda a eliminar rapidamente o problema devido à sua localização.
Nosso sistema de notificação e processamento de alertas é construído em torno de um serviço de linha direta XNUMX horas. Todos os alertas considerados obrigatórios e incluídos no checklist são enviados para lá. Cada alerta deve ter uma descrição: o que aconteceu, o que realmente significa, o que afeta. E também um link para o painel e instruções sobre o que fazer neste caso.
Trata-se de requisitos para criar um alerta. Então a situação pode evoluir em duas direções - ou há um problema e precisa ser resolvido, ou houve uma falha no sistema de monitoramento. Mas, em qualquer caso, você precisa descobrir.
Em média, recebemos hoje cerca de uma centena de alertas por dia, tendo em conta que a correlação de alertas ainda não está devidamente configurada. E se precisarmos realizar um trabalho técnico e desligarmos algo à força, o número deles aumenta significativamente.
Além de monitorar os sistemas que operamos e coletar métricas que são consideradas importantes para nós, o sistema de monitoramento nos permite coletar dados para as equipes de produto. Eles podem influenciar a composição das métricas nos sistemas de informação que monitoramos.
Nosso colega pode vir e pedir para adicionar alguma métrica que será útil para nós e para a equipe. Ou, por exemplo, a equipe pode não ter métricas básicas suficientes que temos; eles precisam monitorar algumas específicas. No Grafana, criamos um espaço para cada equipe e concedemos direitos de administrador. Além disso, se uma equipe precisa de dashboards, mas ela própria não consegue/não sabe como fazê-lo, nós a ajudamos.
Como estamos fora do fluxo de criação de valor da equipe, de seus lançamentos e planejamento, estamos gradativamente chegando à conclusão de que os lançamentos de todos os sistemas são contínuos e podem ser implementados diariamente sem coordenação conosco. E é importante monitorarmos esses lançamentos, porque eles podem afetar potencialmente a operação do aplicativo e quebrar alguma coisa, e isso é fundamental. Para gerenciar lançamentos, utilizamos o Bamboo, de onde recebemos dados via API e podemos ver quais lançamentos foram lançados em quais sistemas de informação e seu status. E o mais importante é a que horas. Sobrepomos marcadores de lançamento nas principais métricas críticas, o que é visualmente muito indicativo em caso de problemas.
Desta forma podemos ver a correlação entre novos lançamentos e problemas emergentes. A ideia principal é entender como o sistema funciona em todas as camadas, localizar rapidamente o problema e corrigi-lo com a mesma rapidez. Afinal, muitas vezes acontece que o que leva mais tempo não é resolver o problema, mas sim buscar a causa.
E nesta área, no futuro, queremos focar na proatividade. Idealmente, eu gostaria de saber antecipadamente sobre um problema que se aproxima, e não depois do fato, para poder evitá-lo em vez de resolvê-lo. Às vezes ocorrem falsos alarmes do sistema de monitoramento, tanto por erro humano quanto por alterações na aplicação, e nós trabalhamos nisso, depuramos e tentamos alertar os usuários que o utilizam conosco sobre isso antes de qualquer manipulação do sistema de monitoramento. , ou realizar essas atividades na janela técnica.
Assim, o sistema foi lançado e tem funcionado com sucesso desde o início da primavera... e está apresentando lucros muito reais. É claro que esta não é a versão final; apresentaremos muitos outros recursos úteis. Mas neste momento, com tantas integrações e aplicações, a automação do monitoramento é realmente inevitável.
Se você também acompanha projetos grandes e com um número significativo de integrações, escreva nos comentários qual solução mágica você encontrou para isso.
Fonte: habr.com