Monitoramento do Kubernetes no estilo Elastic com o Filebeat e o Metricbeat

Em minha postagem anterior no blog, demonstrei como usar o Prometheus e o Fluentd com o Elastic Stack para monitorar o Kubernetes. Essa é uma boa opção se você já estiver usando essas ferramentas de monitoramento baseadas em código aberto na sua organização. No entanto, se você for novo no monitoramento do Kubernetes ou quiser aproveitar ao máximo o Elastic Observability, há uma maneira mais fácil e abrangente. Neste blog, explicaremos como monitorar o Kubernetes no estilo da Elastic: usando o Filebeat e o Metricbeat.

Com o Filebeat e Metricbeat

O Beats é uma plataforma gratuita e aberta dedicada ao envio de dados. Com o Beats, você pode transferir dados de centenas ou milhares de computadores para o Logstash ou o Elasticsearch.

O Filebeat, conhecido como um agente lightweight de log, também dá suporte à arquitetura em containers. O Filebeat pode ser implantado no Docker, no Kubernetes e em ambientes de nuvem, coletando todos os fluxos de log, além de buscar metadados, como containers, pods, nós, ambientes virtuais e hosts e correlacioná-los automaticamente aos eventos de log correspondentes. O Metricbeat é um agente lightweight de métricas que, como o Filebeat, também dá suporte a ambientes em containers. Em um ambiente Kubernetes, os containers são implantados dinamicamente como pods nos nós de trabalho disponíveis. Essa “dinâmica” é a chave, e o Filebeat e o Metricbeat têm um recurso útil chamado Autodiscover (Autodescoberta). Quando você executa aplicativos em containers, eles se tornam alvos móveis para os sistemas de monitoramento. Os provedores de Autodiscover do Kubernetes do Filebeat e do Metricbeat monitoram o início, a atualização e a parada de nós, pods e serviços do Kubernetes. Quando o Filebeat ou o Metricbeat detectam esses eventos, eles disponibilizam os metadados apropriados para cada evento. Além disso, dependendo das anotações dos pods do Kubernetes iniciados, eles aplicam as configurações apropriadas aos logs e métricas de destino. O Autodiscover baseado em dicas é explicado em detalhes em nosso post anterior do blog Docker and Kubernetes Hints-Based Autodiscover with Beats.

Arquitetura de monitoramento

Como no blog anterior, implantaremos uma aplicação simples e com vários containers chamada Cloud-Voting-App em um cluster do Kubernetes e monitoraremos o ambiente do Kubernetes, incluindo essa aplicação. Desta vez, explicarei o procedimento para coletar logs usando o Filebeat, coletar métricas usando o Metricbeat, ingeri-los diretamente no Elasticsearch e monitorá-los usando o Kibana. Também falarei sobre como obter métricas personalizadas do Prometheus usando o Elastic APM. A visão geral da arquitetura é mostrada na figura abaixo. Além disso, o código deste tutorial está disponível em meu repositório do GitHub, portanto, consulte-o para obter o procedimento completo.

Vamos dar uma olhada em cada etapa.

Implantação do Filebeat como um DaemonSet

Apenas uma instância do Filebeat deve ser implantada por nó do Kubernetes. O manifesto do DaemonSet já está definido no arquivo elastic/filebeat-kubernetes.yaml, mas vamos dar uma olhada nas configurações relevantes.

Primeiro, use o provedor Kubernetes Autodiscover para definir as configurações de anotação do pod da aplicação para lidar com os logs. Como você pode ver, as configurações do Autodiscover são definidas na seção ‘filebeat.autodiscover’. Habilitei as dicas e defini o caminho padrão para os logs do container. Consulte a Documentação do Filebeat para obter mais informações sobre como configurar o Autodiscover para o Filebeat.

...
    # To enable hints based autodiscover, remove `filebeat.inputs` configuration and uncomment this:
    filebeat.autodiscover:
      providers:
        - type: kubernetes
          node: ${NODE_NAME}
          hints.enabled: true
          hints.default_config:
            type: container
            paths:
              - /pt/var/log/containers/*${data.kubernetes.container.id}.log
...

Além disso, tudo o que você precisa fazer é adicionar a URL e as credenciais do cluster do Elasticsearch.

...
     containers:
      - name: filebeat
        image: docker.elastic.co/beats/filebeat:7.13.0
        args: [
          "-c", "/pt/etc/filebeat.yml",
          "-e",
        ]
        env:
        - name: ELASTICSEARCH_HOST
          value: elasticsearch
        - name: ELASTICSEARCH_PORT
          value: "9200"
        - name: ELASTICSEARCH_USERNAME
          value: elastic
        - name: ELASTICSEARCH_PASSWORD
          value: changeme
        - name: ELASTIC_CLOUD_ID
          value:
        - name: ELASTIC_CLOUD_AUTH
          value:
...

Implantação do kube-state-metrics

O kube-state-metrics é um complemento do Kubernetes que monitora os objetos armazenados no Kubernetes. O kube-state-metrics se concentra em identificar a condição dos objetos do Kubernetes implantados em um cluster do Kubernetes. Por exemplo, em um determinado momento, quantos pods estão implantados no cluster, quais são os núcleos de CPU alocáveis no cluster, quantos trabalhos falharam e assim por diante. O kube-state-metrics não é implantado nos clusters do Kubernetes por padrão, portanto, você precisará implantá-lo por conta própria. Um manifesto de amostra do kube-state-metrics é colocado em examples/standard para sua referência. Consulte este repositório do GitHub para obter mais informações sobre o kube-state-metrics.

Implantação do Metricbeat como um DaemonSet

De forma semelhante ao Filebeat, apenas uma instância do Metricbeat deve ser implantada por nó do Kubernetes. O manifesto do DaemonSet já está definido no arquivo elastic/metricbeat-kubernetes.yaml, mas é um pouco mais complicado do que o do Filebeat. Vamos dar uma olhada nas configurações mais importantes.

As configurações do Autodiscover são definidas na seção metricbeat.autodiscover. A primeira configuração - type: kubernetes é para todo o cluster do Kubernetes. Aqui, usamos o módulo Kubernetes do Metricbeat para configurar métricas para todo o cluster Kubernetes. A primeira configuração - module: kubernetes define as métricas que obtemos do kube-state-metrics mencionado acima. A segunda configuração - module: kubernetes serve para monitorar o servidor da API do Kubernetes (kube-apiserver), que é o núcleo do plano de controle do Kubernetes que expõe a API do Kubernetes. Consulte a documentação do Metricbeat para obter mais informações sobre o módulo Kubernetes do Metricbeat.

metricbeat.autodiscover:
  providers:
    - type: kubernetes
      scope: cluster
      node: ${NODE_NAME}
      unique: true
      templates:
        - config:
            - module: kubernetes
              hosts: ["kube-state-metrics:8080"]
              period: 10s
              add_metadata: true
              metricsets:
                - state_node
                - state_deployment
                - state_daemonset
                - state_replicaset
                - state_pod
                - state_container
                - state_cronjob
                - state_resourcequota
                - state_statefulset
                - state_service
            - module: kubernetes
              metricsets:
                - apiserver
              hosts: ["https://${KUBERNETES_SERVICE_HOST}:${KUBERNETES_SERVICE_PORT}"]
              bearer_token_file: /pt/var/run/secrets/kubernetes.io/serviceaccount/token
              ssl.certificate_authorities:
                - /pt/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
              period: 30s

Além disso, as dicas são definidas para aproveitar o provedor de Autodescoberta do Kubernetes para permitir o processamento das métricas usando as configurações de anotação do pod da aplicação. Consulte a documentação do Metricbeat para obter mais informações sobre como configurar o Autodiscover para o Metricbeat.

    # To enable hints based autodiscover uncomment this:
    - type: kubernetes
      node: ${NODE_NAME}
      hints.enabled: true

As seguintes configurações do ConfigMap são para node/system/pod/container/volume, que é o Metricset padrão do módulo Kubernetes do Metricbeat. Essas métricas são extraídas do endpoint do kubelet de cada nó.

kubernetes.yml: |-
  - module: kubernetes
    metricsets:
      - node
      - system
      - pod
      - container
      - volume
    period: 10s
    host: ${NODE_NAME}
    hosts: ["https://${NODE_NAME}:10250"]
    bearer_token_file: /pt/var/run/secrets/kubernetes.io/serviceaccount/token
    ssl.verification_mode: "none"

E, assim como no Filebeat, tudo o que você precisa fazer é adicionar a URL e as credenciais do seu cluster do Elasticsearch.

Implantação da aplicação

Assim como no blog anterior, implantaremos o Cloud-Voting-App. A interface da aplicação foi criada usando Python/Flask. O componente de dados usa o Redis. Lembre-se de que a aplicação foi instrumentada com o Prometheus Python Client para expor as métricas personalizadas do Prometheus. Como podemos coletar métricas personalizadas do Prometheus, apesar da ausência do Prometheus desta vez? Da versão 7.12 em diante, podemos usar o Elastic APM Agent para obter métricas personalizadas do Prometheus!

Primeiro, a aplicação importa o ElasticAPM e as variáveis de ambiente são usadas para as configurações do Elastic APM Agent. SERVICE_NAME é uma cadeia de caracteres arbitrária para identificar a aplicação, ENVIRONMENT é uma cadeia de caracteres arbitrária para identificar o ambiente da aplicação e SECRET_TOKEN e SERVER_URL são para a comunicação com o APM Server. O PROMETHEUS_METRICS final é um parâmetro que indica se a métrica deve ser obtida do prometheus_client.

from elasticapm.contrib.flask import ElasticAPM
...
app = Flask(__name__)
...
# Elastic APM Configurations
app.config['ELASTIC_APM'] = {
# Set required service name. Allowed characters:
# a-z, A-Z, 0-9, -, _, and space
'SERVICE_NAME': os.environ['SERVICE_NAME'],
#
# Use if APM Server requires a token
'SECRET_TOKEN': os.environ['SECRET_TOKEN'],
#
# Set custom APM Server URL (default: http://localhost:8200)
'SERVER_URL': os.environ['SERVER_URL'],
#
# Set environment
'ENVIRONMENT': os.environ['ENVIRONMENT'],
#
# Set prometheus_metrics
'PROMETHEUS_METRICS': os.environ['PROMETHEUS_METRICS'],
}
apm = ElasticAPM(app)

A seguir, o Manifesto para implantar o Cloud-Voting-App em um cluster do Kubernetes. O respectivo arquivo está localizado em elastic/cloud-vote-all-in-one-redis-aks.yaml. Em primeiro lugar, em relação à interface de usuário cloud-vote-front, as variáveis necessárias para o APM Agent mencionado acima são definidas como variáveis de ambiente na especificação do container. Aqui, nenhuma anotação específica do pod é especificada, portanto, tanto os registros quanto as métricas são adquiridos usando as configurações padrão.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cloud-vote-front
spec:
  replicas: 1
  selector:
    matchLabels:
      app: cloud-vote-front
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  minReadySeconds: 5
  template:
    metadata:
      labels:
        app: cloud-vote-front
    spec:
      nodeSelector:
        "beta.kubernetes.io/os": linux
      containers:
      - name: cloud-vote-front
        image: your image name
        ports:
        - containerPort: 80
        resources:
          requests:
            cpu: 250m
          limits:
            cpu: 500m
        env:
        - name: REDIS
          value: "cloud-vote-back"
        - name: SERVICE_NAME
          value: "cloud-voting"
        - name: SECRET_TOKEN
          value: "APM Server secret token"
        - name: SERVER_URL
          value: "APM Server URL"
        - name: ENVIRONMENT
          value: "Production"
        - name: PROMETHEUS_METRICS
          value: "True"

Por outro lado, o backend, cloud-vote-redis, usa o pod annotations para habilitar o módulo Filebeat redis para logs e o módulo Metricbeat redis para métricas, aplicando as configurações necessárias. Enquanto o cloute-vote-front usa as configurações padrão para coletar logs e métricas com o Beats, o cloud-vote-back usa o módulo redis do Beats para coletar logs e métricas. Além disso, ao configurar como coletar logs e métricas no manifesto do aplicativo em vez de no manifesto do Beats, você pode isolar as responsabilidades entre a equipe de desenvolvimento e a equipe da plataforma Observability.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cloud-vote-back
spec:
  replicas: 1
  selector:
    matchLabels:
      app: cloud-vote-back
  template:
    metadata:
      labels:
        app: cloud-vote-back
      annotations:
        co.elastic.logs/enabled: "true"
        co.elastic.logs/module: redis
        co.elastic.logs/fileset.stdout: log
        co.elastic.metrics/enabled: "true"
        co.elastic.metrics/module: redis
        co.elastic.metrics/hosts: "${data.host}:6379"
    spec:
      nodeSelector:
        "beta.kubernetes.io/os": linux
      containers:
      - name: cloud-vote-back
        image: redis
        ports:
        - containerPort: 6379
          name: redis

Vamos acessar o Kibana

Agora, implantamos todos os componentes necessários. Vamos votar algumas vezes com o Cloud-Voting-App e depois acessar o Kibana.

Visão geral do Observability

Em primeiro lugar, quando você abre o Elastic Observability no Kibana, as taxas de logs das entradas de log do Filebeat e o resumo das entradas de métrica do Metricbeat são exibidos sem você precisar fazer nada. Esse resultado decorre do fato de que o Filebeat e o Metricbeat ingerem dados no formato ECS por padrão.

Logs

Os logs ingeridos pelo Filebeat são armazenados nos índices filebeat-*. Você pode usar o app Logs no Kibana para buscar, filtrar e acompanhar todos os logs coletados no Elasticsearch. Você também pode destacar strings específicas; por exemplo, destacamos cloud-vote-front no exemplo abaixo.

Métricas

As métricas ingeridas pelo Metricbeat são armazenadas nos índices metricbeat-*. O app Metrics no Kibana fornece uma maneira fácil de entender e intuitiva de visualizar as métricas coletadas no Elasticsearch. Ao usar a visualização Kubernetes Pods, conforme mostrado abaixo, você mapeia os nós e pods do Kubernetes e mostra o uso de cada recurso.

Você também pode clicar em um pod específico para ir para outros apps, como logs de pod ou traces de APM, preservando o contexto. Observe que View details for kubernetes.pod.uid a47d81b1-02d7-481a-91d4-1db9fe82d7a7 é exibido na tela.

Em seguida, você pode acessar os logs desse pod clicando em Kubernetes Pod logs. Você notou que a barra de busca no app Logs já está preenchida com kubernetes.pod.uid: a47d81b1-02d7-481a-91d4-1db9fe82d7a7? Ao preservar o contexto dessa forma, o Kibana pode fazer a transição de um app para outro sem dificuldades, retornando resultados relevantes instantaneamente.

Então, o que aconteceu com as métricas personalizadas do Prometheus? As métricas personalizadas mantidas pelo Prometheus Python Client são gravadas em índices chamados apm-* por meio do Agente de APM do Elastic. Se você verificar no Discover do Kibana, verá que ele é coletado no campo prometheus.metrics.cloud_votes. A variável na solicitação POST é armazenada como labels.vote. Consulte a documentação do APM para obter mais informações sobre a coleta de métricas personalizadas do Prometheus com o agente Python do Elastic APM.

Você pode visualizar facilmente os índices apm-* com Kibana Lens da seguinte forma.

Dashboards pré-definidos

Para o pod cloud-vote-back que usa o Redis, habilitamos o módulo redis para o Filebeat e o Metricbeat. Isso também criará previamente dashboards prontos para uso relacionados. Você pode visualizar instantaneamente os logs e as métricas do Redis sem nenhuma configuração adicional.

Além disso, o dashboard do Kubernetes também está pronto para uso, graças ao módulo Kubernetes do Metricbeat.

Resumo

Neste blog, vimos uma maneira mais no estilo Elastic de usar o Filebeat e o Metricbeat para preencher o Elastic Stack com logs e métricas para monitorar o Kubernetes. Também vimos como usar o Agente Elastic APM para obter métricas personalizadas do Prometheus. Você pode começar a monitorar seus ambientes Kubernetes hoje mesmo inscrevendo-se em uma avaliação gratuita do Elastic Cloud ou baixando o Elastic Stack e hospedando-o por conta própria. O Elastic Observability permite um monitoramento mais eficiente e eficaz. Ele também pode ser integrado ao machine learning da Elastic e aos alertas do Kibana para estabelecer uma observabilidade altamente automatizada, acionável e abrangente. Se tiver alguma dificuldade ou dúvidas, vá para os nossos fóruns de discussão — estamos aqui para ajudar.

Em um futuro post do blog, abordaremos mais maneiras de usar o Elastic para monitorar o Kubernetes.