Monitoramento

Monitoramento

Seja qual for a arquitetura usada nos sistemas, algo sempre dará errado. Infelizmente, por mais que Built In Quality seja parte integrante dos processos de engenharia, defeitos sempre existirão. Isso não significa que devemos parar de colocar esforço em tentar evitar que os defeitos ocorram, mas que também devemos nos preparar para identificar e corrigir os defeitos o mais rápido possível.

Nesse sentido, o monitoramento é fundamental. Em uma arquitetura distribuída como a de microserviços, o monitoramento é ainda mais importante porque estamos lidando com dezenas de serviços que juntos produzem o resultado final disponibilizado ao usuário.

O objetivo deste documento é apresentar qual abordagem temos seguido para monitorar os serviços do STF Digital.

Objetivos

Em termos de monitoramento, trabalhamos com seguinte conjunto de objetivos:

Conceitos

Na era do monitoramento de microserviços, muito tem se falado sobre a diferença entre monitoring e observability, com segundo sendo comumente usado por diversos fornecedores para vender “um monitoramento melhor”. Abaixo, como entendemos cada um desses termos:

Portanto, no nosso entendido, ambos são complementares. Usar monitoramento em sistemas pouco observáveis resultaria em um ambiente de monitoramento pouco eficiente, ao passo que ter um sistema com vários pontos de observação sem o monitoramento desses pontos não resulta em nenhuma capacidade de controle.

Os pontos de observação são externalizados usando eventos de telemetria. No nosso caso, tais eventos são usados para observar métricas separadas para acompanhar as seguintes categorias:

Métricas para essas duas categorias são coletadas e apresentadas por padrão sempre que um novo serviço é ativado, mas outras, específicas para cada serviço, também podem ser adicionadas para aumentar a capacidade de observação do ativo (observability).

Monitoramento nos Projetos

Como vimos acima, mesmo usando as melhores ferramentas de monitoramento, com altos níveis de instrumentação do ativo, ainda assim não teremos uma boa capacidade de observação se os eventos de telemetria não forem identificados e expostos de forma adequada pelo serviço correspondente. Ou seja, a capacidade de observação nasce com o produto. Você não conseguirá aumentá-la se seu produto não expor tais eventos.

Portanto, a identificação e implementação desses eventos deve ser feita durante a fase de projeto, como parte do processo de desenvolvimento. Recomenda-se que tais métricas abordem não só aspectos não funcionais, como performance, por exemplo, mas, preferencialmente, aspectos funcionais, especialmente aqueles vinculados às hipóteses negociais que deseja provar com a implantação do produto.

Monitoramento nas Operações

Com as métricas definidas e o monitoramento funcionando, as equipes de operações poderiam acompanhá-las e tomar as medidas adequadas em caso de alguma inconformidade. Para as duas categorias listadas acima, recomendamos o seguinte conjunto de ações:

Como ainda não existem canais para reportar e controlar as alertas gerados a partir dos eventos listados acima, sugerimos reportá-los por e-mail para o grupo de gestores do STF Digital.

Limitações

Atualmente, nossa principal limitação é a ausência de conexão entre as ferramentas de monitoramento e o processo de gestão de incidentes. Tal integração deve ser incorporada como parte da evolução da infraestrutura de monitoramento, que já está prevista para ser executada após a conclusão das atividades relacionadas à incorporação de alta disponibilidade para todos os ativos em uso atualmente.

Outra importante limitação é a capacidade de identificação dos eventos de telemetria em tempo de projeto. Acreditamos que tal limitação só será resolvida com o amadurecimento natural das equipes de análise, desenvolvimento e operações.