Engenharia

Monitoramento de Kubernetes e Containers Docker com os Beats: logs, métricas e metadados

Por
Dan Roscigno

Este post é sobre o monitoramento de um ambiente de containers, que pode incluir o Google Kubernetes Engine (GKE), o IBM Cloud Kubernetes Service e qualquer outro ambiente Kubernetes (k8s) e Docker. Neste post, usarei o IBM Cloud Kubernetes Service.

Você deve estar se perguntando por que escrevo sobre o monitoramento de containers Docker e Kubernetes. Certamente, os provedores da nuvem estão gerenciando a infraestrutura para que eu possa me preocupar apenas com a minha aplicação, certo? Você pode ter razão, mas eu sou o tipo de pessoa que lê as avaliações do Yelp mesmo se um conhecido me recomendar algum lugar, porque quanto mais informações eu tiver, melhor. Eu quero ter todos os logs e métricas da minha aplicação e do ambiente dela, e quero também poder pesquisar, visualizar e receber alertas sobre tudo isso. Aquele monitoramento comum de containers é ótimo, mas eu também vou mostrar a você um jeito interessante de usar eventos e metadados do Kubernetes para anotar o gráfico de performance da minha aplicação com notificações sobre aumento de capacidade ou atualizações sem interrupção.

Vamos definir alguns termos antes de continuar.

  • Log: é um carimbo de data/hora e uma mensagem. Inclui entradas típicas de log, como “NGINX iniciou às 13h42” e eventos do k8s, como “Houve um recuo em um container do NGINX reinicializando container falho às 16h20.”
  • Métrica: uma medida numérica coletada em período predeterminado. Por exemplo, “As vendas pelo site de e-commerce totalizaram US$ 50.000 nos últimos 10 minutos” ou “A utilização da CPU foi de 17% das 14:00:00 às 14:00:10”.

Implantação de aplicações em um cluster do Kubernetes

No meu exemplo, vou usar esta aplicação baseada em Apache HTTP Server, PHP e Redis.

k8s-module-1.png

Além disso, para monitorar a aplicação e a infraestrutura de containers, temos: 

  • Uma implantação hospedada do Elasticsearch Service no Elastic Cloud.
  • Beats, expedidores leves de logs e métricas implantados como um DaemonSet no mesmo cluster de Kubernetes.  Observe que ele pode substituir o fluentd que é geralmente implantado em um cluster de Kubernetes.

Logs e métricas

A aplicação acima é apenas uma parte de um ecossistema que está constantemente gerando informações úteis que devemos capturar. Estes são os níveis em que coletamos esses logs e métricas:

  1. Orquestração (Kubernetes)
  2. Hosts
  3. Aplicação
  4. Container (Docker)

k8s-module-2.png

Para coletar os dados, usamos os Beats (Filebeat, Metricbeat e Packetbeat) e os módulos System, Kubernetes e Docker juntamente com os módulos de aplicação (Apache e Redis). Implantamos um DaemonSet para cada Beat e deixamos o Kubernetes gerenciá-los. A lista parece longa, mas fique tranquilo, pois a descoberta automática dos Beats mantém a simplicidade do processo.  Os detalhes sobre a implantação dos Beats para monitorar uma aplicação estão neste post e no vídeo que o acompanha.  Para começar do início, confira a página de monitoramento de containers da Elastic.

Para indexar, armazenar, pesquisar, analisar e visualizar os dados, eu usei o Elasticsearch Service hospedado.  A implantação do Elasticsearch Service no Elastic Cloud está detalhada em nossa página de introdução, bem como a implantação do Elasticsearch e do Kibana em um sistema que você mesmo gerencia.  De um jeito ou de outro, funciona bem.

Eu mencionei Beats e módulos, e estes pontos merecem uma apresentação mais detalhada. Um Beat é um agente leve que envia dados para o Elasticsearch e para o Logstash. Em alguns casos, os Beats são implantados no ponto de origem dos dados, como em sistemas físicos ou virtuais, e, em outros, a implantação acontece paralela às fontes, por exemplo, como um DaemonSet (e esta é forma descrita neste post). Os módulos simplificam o processo de coleta, análise, indexação e visualização de formatos comuns de logs.

Isso soou meio enfadonho, mas deixe-me explicar melhor: os módulos do Elastic são uma experiência pré-empacotada. Digamos que você saiba tudo sobre o gerenciamento do Apache HTTPD Server, mas NGINX é novidade para você. Talvez você pergunte a alguém que conheça o NGINX: “O que você observa nos logs? Que métricas você acompanha? Tem como obter os greps do seu arquivo de histórico?” As respostas a essas perguntas definem os módulos Beat para mim: dashboards prontos, pesquisas salvas, parsing e coleta para um monte de coisas, como  Kubernetes, Docker, NGINX, Apache, sistemas operacionais, bancos de dados, etc. Na minha experiência, é um conjunto de recursos bastante potente.

O módulo k8s coleta métricas relacionadas a pods, nós, volumes, ReplicaSets, implantações, etc. Cada métrica tem um conjunto rico de metadados para que você atrelar os dados à sua aplicação. Por exemplo, talvez você não se importe que o pod xyz esteja próximo ao limite do uso de memória, mas se a métrica aparecer como associada ao front-end da sua aplicação, você saberá o valor dessa informação para o seu negócio. Ela também coleta eventos (lembre-se de que eu incluí os eventos de Kubernetes na definição de log acima), que usaremos para enriquecer um gráfico de performance no vídeo abaixo.

O módulo do Docker coleta métricas relacionadas a containers, hosts, memória, rede, checks de saúde, etc. Assim como o módulo do Kubernetes, os metadados são muito valiosos para entender a performance da sua aplicação e do ambiente.

Há muitos outros módulos para o Filebeat e para o Metricbeat.  Além disso, o Packetbeat vem com muitos dashboards para serviços como Cassandra, Flows, HTTP, MySQL, MongoDB, etc.

Assista para ver como é fácil transformar dados em inteligência acionável. O vídeo mostra:

  • Visualização de eventos de Kubernetes com métricas de performance da aplicação
  • Aprofundamento no conjunto de métricas de eventos do módulo de Kubernetes do Metricbeat
  • Navegação pelos eventos do Kubernetes e construção da visualização customizada