Monitoreo de Kubernetes al estilo de Elastic con Filebeat y Metricbeat

En el blog anterior, mostramos cómo usar Prometheus y Fluentd con el Elastic Stack para monitorear Kubernetes. Es una buena opción si ya usas esas herramientas de monitoreo basadas en open source en tu organización. Pero si eres nuevo en el monitoreo de Kubernetes o deseas aprovechar Elastic Observability al máximo, hay una forma más fácil e integral. En este blog, exploraremos cómo monitorear Kubernetes a la manera de Elastic: con Filebeat y Metricbeat.

Usar Filebeat y Metricbeat

Beats, como sabes, es una plataforma gratis y abierta dedica al envío de datos. Con Beats puedes transferir datos de cientos o miles de máquinas a Logstash o Elasticsearch.

Filebeat, que es conocido como un agente de logs ligero, también brinda soporte para una arquitectura en contenedores. Filebeat puede desplegarse en Docker, Kubernetes y entornos en el cloud, recopilar todos los flujos de logs y tomar metadatos, como contenedores, pods, nodos, entornos virtuales y hosts, y luego correlacionarlos directamente con los eventos de logs correspondientes. Metricbeat es un agente de métricas ligero que, como Filebeat, también brinda soporte para entornos en contenedores. En un entorno de Kubernetes, los contenedores se despliegan de forma dinámica como pods en nodos de trabajo disponibles. Esta "dinámica" es la clave, y Filebeat y Metricbeat tienen una característica útil llamada Autodiscover (Detección automática). Al ejecutar aplicaciones en contenedores, se convierten en objetivos móviles para los sistemas de monitoreo. Los proveedores de detección automática de Kubernetes de Filebeat y Metricbeat monitorean el inicio, la actualización y la detención de los nodos, los pods y los servicios de Kubernetes. Cuando Filebeat o Metricbeat detectan estos eventos, ponen a disposición los metadatos adecuados de cada evento. Además, según las anotaciones de los pods de Kubernetes iniciados, aplican la configuración adecuada a las métricas y los logs objetivo. La detección automática basada en sugerencias se explica en detalle en el blog anterior Detección automática con Beats basada en sugerencias de Docker y Kubernetes.

Monitoreo de arquitectura

Tal como en el blog anterior, desplegaremos una aplicación simple multicontenedor denominada Cloud-Voting-App en un cluster de Kubernetes y monitorearemos el entorno de Kubernetes, incluida dicha aplicación. Esta vez, explicaremos el procedimiento para recopilar logs usando Filebeat, recopilar métricas usando Metricbeat, ingestarlos directamente en Elasticsearch y monitorearlos usando Kibana. También veremos cómo obtener métricas personalizadas de Prometheus usando Elastic APM. La visión general de la arquitectura se muestra en la imagen a continuación. Además, el código para este tutorial está disponible en este repositorio de GitHub, consúltalo para ver el procedimiento completo.

Veamos cada uno de los pasos.

Desplegar Filebeat como DaemonSet

Solo se debe desplegar una instancia de Filebeat por nodo de Kubernetes. El manifiesto del DaemonSet ya está definido en el archivo elastic/filebeat-kubernetes.yaml, pero echemos un vistazo a la configuración relevante.

Primero, usa el proveedor de detección automática de Kubernetes a fin de configurar los ajustes de anotación de pods de las aplicaciones para que se ocupe de los logs. Como puedes ver, la configuración de Autodiscover (Detección automática) se define en la sección filebeat.autodiscover. Habilitamos las sugerencias y configuramos la ruta predeterminada para los logs de contenedores. Consulta la documentación de Filebeat para obtener más información sobre la configuración de Autodiscover (Descubrimiento automático) en Filebeat.

...
    # Para habilitar el descubrimiento automático basado en sugerencias, elimina la configuración de "filebeat.inputs" y quita el comentario de esto:
    filebeat.autodiscover:
      providers:
        - type: kubernetes
          node: ${NODE_NAME}
          hints.enabled: true
          hints.default_config:
            type: container
            paths:
              - /es/var/log/containers/*${data.kubernetes.container.id}.log
...

Además de lo anterior, lo único que debes hacer básicamente es agregar la URL y las credenciales de tu cluster de Elasticsearch.

...
     containers:
      - name: filebeat
        image: docker.elastic.co/beats/filebeat:7.13.0
        args: [
          "-c", "/es/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:
...

Desplegar kube-state-metrics

kube-state-metrics es un complemento de Kubernetes que monitorea los objetos almacenados en Kubernetes. kube-state-metrics se enfoca en identificar el estado de los objetos de Kubernetes desplegados en un cluster de Kubernetes. Por ejemplo, en un momento dado, cuántos pods hay desplegados en el cluster, cuáles son los CPU cores asignables en el cluster, cuántos trabajos fallaron, etc. kube-state-metrics no está desplegado en los clusters de Kubernetes de forma predeterminada, tendrás que desplegarlo tú. Hay un manifiesto de muestra de kube-state-metrics bajo examples/standard a modo de referencia. Consulta este repositorio de GitHub para obtener más información sobre kube-state-metrics.

Desplegar Metricbeat como DaemonSet

Solo se debe desplegar una instancia de Metricbeat por nodo de Kubernetes, similar a Filebeat. El manifiesto del DaemonSet ya está definido en el archivo elastic/metricbeat-kubernetes.yaml, pero es un poco más complejo que Filebeat. Veamos las configuraciones clave.

Las configuraciones de Autodiscover (Detección automática) se definen en la sección metricbeat.autodiscover. La primera configuración - type: kubernetes aplica a todo el cluster de Kubernetes. Aquí usamos el módulo de Kubernetes de Metricbeat para configurar las métricas para el cluster de Kubernetes completo. La primera configuración - module: kubernetes establece las métricas que obtenemos de kube-state-metrics antes mencionado. La segunda configuración - module: kubernetes es una configuración para monitorear el servidor de API de Kubernetes (kube-apiserver), que es la esencia del plano de control de Kubernetes que expone la API de Kubernetes. Consulta la documentación de Metricbeat para obtener más información sobre el módulo de Kubernetes de 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: /es/var/run/secrets/kubernetes.io/serviceaccount/token
              ssl.certificate_authorities:
                - /es/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
              period: 30s

Además, se definen sugerencias para aprovechar el proveedor de detección automática de Kubernetes a fin de permitir el procesamiento de las métricas usando las configuraciones de anotación de pods de las aplicaciones. Consulta la documentación de Metricbeat para obtener más información sobre la configuración de Autodiscover (Descubrimiento automático) en Metricbeat.

    # Para permitir la detección automática basada en sugerencias, quita el comentario de esto:
    - type: kubernetes
      node: ${NODE_NAME}
      hints.enabled: true

Las siguientes configuraciones de ConfigMap son para nodo/sistema/pod/contenedor/volumen, que son el conjunto de métricas predeterminado del módulo de Kubernetes de Metricbeat. Estas métricas se toman del endpoint de kubelet de cada nodo.

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

Tal como en Filebeat, lo único que debes hacer es agregar la URL y las credenciales de tu cluster de Elasticsearch.

Desplegar la aplicación

Como en el blog anterior, desplegaremos Cloud-Voting-App. La interfaz de la aplicación se creó usando Python/Flask. El componente de datos usa Redis. Recuerda que la aplicación se instrumentó con el cliente de Python para Prometheus a fin de exponer las métricas personalizadas de Prometheus. ¿Cómo recopilamos las métricas personalizadas de Prometheus a pesar de la falta de Prometheus esta vez? A partir de la versión 7.12, podemos usar Elastic APM Agent para obtener métricas de Prometheus personalizadas.

Primero, la aplicación importa ElasticAPM y las variables de entorno se usan para la configuración de Elastic APM Agent. SERVICE_NAME es una cadena de caracteres arbitraria para identificar la aplicación, ENVIRONMENT es una cadena de caracteres arbitraria para identificar el entorno de la aplicación y SECRET_TOKEN y SERVER_URL son para comunicarse con el APM Server. Al final, PROMETHEUS_METRICS es un parámetro que indica si se obtendrá la métrica de prometheus_client.

from elasticapm.contrib.flask import ElasticAPM
...
app = Flask(__name__)
...
# Configuraciones de Elastic APM
app.config['ELASTIC_APM'] = {
# Configura el nombre de servicio obligatorio. Caracteres permitidos:
# a-z, A-Z, 0-9, -, _ y espacio.
'SERVICE_NAME': os.environ['SERVICE_NAME'],
#
# Úsala si el servidor APM requiere un token.
'SECRET_TOKEN': os.environ['SECRET_TOKEN'],
#
# Configura la URL personalizada de APM Server (predeterminada: http://localhost:8200).
'SERVER_URL': os.environ['SERVER_URL'],
#
# Configura el entorno.
'ENVIRONMENT': os.environ['ENVIRONMENT'],
#
# Configura prometheus_metrics.
'PROMETHEUS_METRICS': os.environ['PROMETHEUS_METRICS'],
}
apm = ElasticAPM(app)

El siguiente es el manifiesto para desplegar Cloud-Voting-App en un cluster de Kubernetes. El archivo correspondiente se encuentra en elastic/cloud-vote-all-in-one-redis-aks.yaml. En primer lugar, respecto a la interfaz de usuario cloud-vote-front, las variables requeridas para APM Agent antes mencionado están configuradas como variables de entorno en las especificaciones del contenedor. Aquí no hay especificadas anotaciones específicas del pod, por lo tanto, tanto las métricas como los logs se adquieren con la configuración predeterminada.

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 otro lado, el backend, cloud-vote-redis usa annotations de pod para habilitar el módulo redis de Filebeat para logs y el módulo redis de Metricbeat para métricas, aplicando cualquier configuración necesaria. Mientras que cloute-vote-front usa la configuración predeterminada para recopilar logs y métricas con Beats, cloud-vote-back usa el módulo redis de Beats para recopilar logs y métricas. Además, configurando cómo recopilar logs y métricas en el manifiesto de la aplicación en lugar de en el manifiesto de Beats, puedes aislar las responsabilidades del equipo de desarrollo y el equipo de la plataforma de observabilidad.

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

Acceder a Kibana

Ahora ya desplegamos todos los componentes necesarios. Votemos algunas veces con Cloud-Voting-App y luego accedamos a Kibana.

Visión general de Observability

En primer lugar, cuando abres Elastic Observability en Kibana, las tasas de logs de las entradas de logs de Filebeat y el resumen de las entradas de métricas de Metricbeat se muestran sin que hagas nada. Este resultado se debe a que Filebeat y Metricbeat ingestan datos en formato ECS de forma predeterminada.

Logs

Los logs ingestados por Filebeat se almacenan en los índices filebeat-*. Puedes usar la app Logs en Kibana para buscar, filtrar y seguir el final de todos los logs recopilados en Elasticsearch. También puedes destacar cadenas específicas; por ejemplo, destacamos cloud-vote-front en el ejemplo siguiente.

Métricas

Las métricas ingestadas por Metricbeat se almacenan en los índices metricbeat-*. La app Metrics en Kibana proporciona una forma intuitiva y fácil de comprender de ver las métricas recopiladas en Elasticsearch. Con la vista Kubernetes Pods, como se muestra a continuación, se mapean los nodos y los pods de Kubernetes, y se muestra el uso de cada recurso.

También puedes hacer clic en un pod específico para saltar a otras apps, como rastreos de APM o logs de pod, preservando el contexto. Ten en cuenta que View details for kubernetes.pod.uid a47d81b1-02d7-481a-91d4-1db9fe82d7a7 se muestra en pantalla.

Luego puedes saltar a los logs de este pod haciendo clic en Kubernetes Pod logs. ¿Notaste que en la barra de búsqueda de la app Logs ya aparece kubernetes.pod.uid: a47d81b1-02d7-481a-91d4-1db9fe82d7a7? Al preservar el contexto de esta forma, Kibana puede transicionar de una app a otra sin problemas y devolver resultados relevantes al instante..

¿Qué sucedió con las métricas personalizadas de Prometheus? Las métricas personalizadas que mantiene el cliente de Python de Prometheus se escriben en índices denominados apm-* a través de Elastic APM Agent. Si compruebas con Kibana Discover, puedes ver que se recopilan en el campo prometheus.metrics.cloud_votes. La variable en la solicitud POST se almacena como labels.vote. Consulta la documentación de APM para obtener más información sobre recopilar métricas personalizadas de Prometheus con el agente Python de Elastic APM.

Puedes visualizar con facilidad los índices apm-* con Kibana Lens de la siguiente manera.

Dashboards predefinidos

Para el pod cloud-vote-back que usa Redis, habilitamos el módulo redis para Filebeat y Metricbeat. Esto también creará previamente dashboards listos para usar relacionados. Puedes visualizar de forma instantánea métricas y logs de Redis sin configuración adicional.

Además, el dashboard de Kubernetes también está listo para usar, gracias al módulo de Kubernetes de Metricbeat.

Resumen

En este blog, vimos una forma más del estilo de Elastic de usar Filebeat y Metricbeat para ingresar logs y métricas al Elastic Stack a fin de monitorear Kubernetes. También vimos cómo usar Elastic APM Agent para obtener métricas personalizadas de Prometheus. Puedes comenzar a monitorear tus entornos de Kubernetes hoy registrándote para una prueba gratuita de Elastic Cloud o descargando el Elastic Stack y hospedándolo tú mismo. Elastic Observability permite un monitoreo más eficiente y efectivo. También se puede integrar con el machine learning de Elastic y las alertas de Kibana para establecer una observabilidad integral, procesable y sumamente automatizada. Si encuentras algún obstáculo o tienes preguntas, visita nuestros foros de debate; estamos aquí para ayudarte.

Mantente atento a un futuro blog de seguimiento con más formas de usar Elastic para monitorear Kubernetes.