Como você monitora os serviços do Node Micro em execução no Docker Containers?

Este artigo sobre " Qual é a integridade do seu aplicativo Dockerized?" explica o problema do monitoramento, mas não fornece bons exemplos de como realmente monitorar um microsserviço dentro do contêiner do docker.

No momento, estamos usando o PM2 monit para monitorar nossos microsserviços, mas, quando os colocamos em contêineres de docker, perdemos a capacidade de acessar esses dados em uma tela para todos os vários microsserviços que são executados em seu próprio contêiner de docker.

O monitoramento do Dockerswarm nos informará o estado dos contêineres, mas não o microsserviço em execução dentro deles.

Qual é uma maneira comprovada e sólida de resolver esse problema?

Esta é uma área em que o Kubernetes tem o modelo correto; deve haver um balanceador de carga entre todos os sistemas que devem ter verificações de integridade funcionais.

Depois de começar a adicionar o Nagios, o Zabbix ou outros tipos de monitoramento ao sistema, você começa a construir uma grande máquina de estado. Isso quebrará o modelo de acoplamento flexível e introduzirá interdependências que inibem a facilidade de refatoração. Embora não seja uma pedra, a principal diferenciação entre microsserviços e outras variantes de SOA é esse acoplamento solto.

Se os serviços são refinados e executam uma única função, implemente uma verificação de integridade em um balanceador de carga upstream e monitore os membros do pool ativo.

Como um exemplo no HAproxy

backend myapp
[...]
option tcp-check
tcp-check send GET\ /health HTTP/1.0\r\n
tcp-check send Host:\ foo\r\n
tcp-check send \r\n
tcp-check expect rstring ^HTTP/1.1\ 200\ Ok
tcp-check expect string container\ Good
server srv1 10.0.0.1:8080 check
server srv2 10.0.0.2:8080 check

Em teoria, você não se importa com o desempenho de um contêiner real, apenas com o desempenho geral.

Esse método facilita o reparo automático do sistema e o dimensionamento com uma quantidade mínima de complexidade.

Basicamente, você só precisa verificar se o número de sistemas que você espera está ativo e, caso contrário, você aumenta um pouco mais. Se você precisar adicionar capacidade, basta alterar o número de nós esperados.

Isso também simplifica a refatoração, pois você só precisa replicar ou modificar esse teste sem dependências externas ou máquina de estado.

Também deve reduzir o tempo de inatividade e os alertas noturnos do Pagerduty à medida que o sistema se auto repara.

Quanto às métricas gerais dos sistemas, necessárias para rastrear problemas como a latência, eu os gostaria em um local central, usando uma ferramenta como o elasticsearch. Se você usa syslog, logstash ou log4 ??? coletar métricas que serão muito mais úteis a longo prazo. Quando os sistemas são pequenos e simples, o monitoramento tradicional baseado em pesquisas pode fornecer métricas suficientes, mas é preferível tê-las em um formato pesquisável e, mais importante, em relação a outros sistemas.

Soluções como a monit ainda têm seu lugar, mas é para monitorar os componentes de longa duração, como as VMs ou o bare metal que hospeda seu enxame, mas os próprios contêineres devem ser dissociados desse sistema para obter o máximo de benefícios de um modelo de microsserviços.

Uma solução comumente usada (não específica do contêiner) é criar uma API de verificação de integridade em seu serviço, que testa toda a funcionalidade que você deseja monitorar (por exemplo, disponibilidade de bancos de dados e outras dependências) e o próprio aplicativo e retorna a saída esperada (por exemplo, < serviço>: <status>). Você pode acionar alertas de um serviço de monitoramento como o Nagios se esta API não retornar uma aprovação para todos os serviços. Isso também falhará se o próprio microsserviço não estiver íntegro.

Essa abordagem também tem o benefício de executar um teste funcional do seu serviço (atingindo um ponto final da API).

Essa abordagem não cobre alguns casos extremos - por exemplo. o microsserviço é executado (mas APIs específicas falham).