Monitorer Kubernetes à la manière d'Elastic à l'aide de Filebeat et de Metricbeat

Dans mon précédent article de blog, je montrais comment utiliser Prometheus et Fluentd avec Elastic Stack pour monitorer Kubernetes. C'est une solution pertinente si vous employez déjà ces outils de monitoring open source dans votre organisation. Si, à l'inverse, vous découvrez tout juste le monitoring de Kubernetes, ou si vous souhaitez exploiter pleinement Elastic Observability, il existe un moyen plus simple et complet. Dans le présent article, nous verrons comment monitorer Kubernetes à la manière d'Elastic, c'est-à-dire à l'aide de Filebeat et de Metricbeat.

À l'aide de Filebeat et de Metricbeat

Comme vous le savez, Beats est une plate-forme ouverte et gratuite, dédiée au transfert de données. Beats vous permet de transférer des centaines, voire des milliers de machines et de systèmes vers Logstash et Elasticsearch.

Filebeat, un agent de transfert de log léger, prend aussi en charge une architecture conteneurisée. Filebeat peut également être déployé dans des environnements Docker, Kubernetes et cloud, collectant alors tous les flux de données et récupérant des métadonnées telles que des conteneurs, des pods, des nœuds et des environnements virtuels. Cet outil les héberge et les met automatiquement en corrélation avec les événements de log. [Metricbeat] (https://www.elastic.co/fr/beats/metricbeat) est un agent de transfert d'indicateur léger qui, à l'instar de Filebeat, prend en charge des environnements conteneurisés. Dans un environnement Kubernetes, les conteneurs sont déployés de manière dynamique comme pods sur des nœuds de travail. Cette "dynamique" est la clé, et Filebeat ainsi que Metricbeat sont dotés d'une fonctionnalité bien pratique, Autodiscover. Quand vous exécutez des applications dans des conteneurs, elles deviennent des cibles en mouvement pour les systèmes de monitoring. Les Kubernetes Autodiscover Providers de Filebeat et de Metricbeat monitorent le lancement, la mise à jour et l'arrêt et des nœuds, pods et services Kubernetes. Quand Filebeat ou Metricbeat détectent ces événements, ils rendent les métadonnées associées disponibles concernant chaque événement. De plus, en fonction des annotations des pods Kubernetes lancés, ils appliquent les paramètres adéquats aux logs et indicateurs cibles. Autodiscover, basé sur les indices, est expliqué en détail dans notre article de blog précédent Fonction Autodiscover fondée sur les indices, compatible avec Docker et Kubernetes, dans Beats.

Architecture de monitoring

Comme dans l'article précédent, nous déploierons une application simple et multi-conteneurs, appelée Cloud-Voting-App, dans un cluster Kubernetes et monitorerons l'environnement Kubernetes comprenant cette application. Cette fois-ci, j'expliquerai la procédure de collecte de logs à l'aide de Filebeat, de collecte d'indicateurs à l'aide de Metricbeat, de leur ingestion directe dans Elasticsearch et de leur monitoring à l'aide de Kibana. J'aborderai aussi la manière d'obtenir des indicateurs Prometheus personnalisés à l'aide de l'APM Elastic. L'architecture globale est illustrée ci-dessous. Et le code pour ce tutoriel est disponible dans mon référentiel GitHub : merci de vous y reporter pour connaître l'intégralité de la procédure.

Voyons maintenant chacune des étapes.

Déploiement de Filebeat comme un DaemonSet

Il convient de déployer une seule instance de Filebeat par nœud Kubernetes. Le manifeste du DaemonSet est déjà défini dans le fichier "elastic/filebeat-kubernetes.yaml", mais examinons les paramètres pertinents.

D'abord, utilisez le Kubernetes Autodiscover Provider pour configurer les paramètres d'annotation du pod d'application en vue de traiter les logs. Comme vous pouvez le voir, les paramètres Autodiscover sont définis dans la section "filebeat.autodiscover". J'ai activé les indices et réglé le chemin par défaut pour les logs de conteneur. Merci de vous reporter à la documentation Filebeat pour plus d'informations sur la configuration d'Autodiscover pour 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:
              - /fr/var/log/containers/*${data.kubernetes.container.id}.log
...

En plus des étapes ci-dessus, tout ce que vous devez faire consiste essentiellement à ajouter l'URL et les identifiants pour votre cluster Elasticsearch.

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

Déploiement de kube-state-metrics

kube-state-metrics est un module complémentaire Kubernetes qui monitore les objets stockés dans ce dernier. kube-state-metrics cible l'identification de la condition des objets Kubernetes déployés dans un cluster Kubernetes. Par exemple, à un moment donné, le nombre de pods déployés dans le cluster, les cœurs de processeur pouvant être attribués dans le cluster, le nombre de tâches qui ont échoué, etc. kube-state-metrics n'est pas déployé dans les clusters Kubernetes par défaut, c'est pourquoi vous devrez le faire. Un exemple de manifeste est à votre disposition dans "examples:standard" pour référence. Merci de vous reporter à ce référentiel GitHub pour plus d'informations sur kube-state-metrics.

Déploiement de Metricbeat comme un DaemonSet

Il convient de déployer une seule instance de Metricbeat par nœud Kubernetes, comme pour Filebeat. Le manifeste du DaemonSet est déjà défini dans le fichier "elastic/metricbeat-kubernetes.yaml", mais il est un peu plus complexe que pour Filebeat. Regardons les paramètres clés.

Les paramètres d'Autodiscover sont définis dans la section "metricbeat.autodiscover". Le premier paramètre "- type: kubernetes" concerne l'intégralité du cluster Kubernetes. Ici, nous utilisons le module Kubernetes de Metricbeat en vue de configurer les indicateurs pour l'intégralité du cluster Kubernetes. La première configuration "- module: kubernetes" définit les indicateurs que nous obtenons à partir de kube-state-metrics dont il est fait mention ci-dessus. La seconde configuration "- module: kubernetes" sert à monitorer le server API Kubernetes (kube-apiserver), qui est au cœur du plan de contrôle qui présente l'API Kubernetes. Merci de vous reporter à la documentation Metricbeat pour plus d'informations sur le module 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: /fr/var/run/secrets/kubernetes.io/serviceaccount/token
              ssl.certificate_authorities:
                - /fr/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
              period: 30s

Par ailleurs, les indices sont définis de manière à exploiter le Kubernetes Autodiscover Provider afin d'activer le traitement des indicateurs à l'aide des paramètres d'annotation de pod d'application. Merci de vous reporter à la documentation Metricbeat pour plus d'informations sur la configuration d'Autodiscover pour Metricbeat.

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

Les paramètres ConfigMap suivants sont pour le nœud/ système/pod/conteneur/volume, et correspondent à l'ensemble d'indicateurs par défaut du module Kubernetes de Metricbeat. Ces indicateurs sont extraits du point de terminaison kubelet de chaque nœud.

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

Comme pour Filebeat, en plus des étapes ci-dessus, tout ce que vous devez faire consiste essentiellement à ajouter l'URL et les identifiants pour votre cluster Elasticsearch.

Déploiement de l'application

Comme dans l'article précédent, nous déploierons Cloud-Voting-App. L'interface d'application a été créée à l'aide de Python/Flask. La composante de données utilise Redis. Rappelez-vous que l'application a été instrumentée avec le client Python Prometheus pour présenter les indicateurs personnalisés Prometheus. Comment collecter les indicateurs personnalisés Prometheus malgré l'absence de Prometheus cette fois-ci ? À partir de la version 7.12, nous pouvons utiliser l'agent APM Elastic pour obtenir des indicateurs personnalisés Prometheus !

D'abord, l'application importe "ElasticAPM" et les variables d'environnement sont utilisées pour les paramètres de l'agent APM Elastic. "SERVICE_NAME" est une chaîne de caractères arbitraire pour l'identification de l'application, "ENVIRONMENT" en est une pour l'identification de l'environnement d'application, tandis que "SECRET_TOKEN" et "SERVER_URL" servent à communiquer avec votre serveur d'APM. Le "PROMETHEUS_METRICS" final est un paramètre indiquant s'il faut obtenir l'indicateur depuis 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)

Voici le Manifeste de déploiement de Cloud-Voting-App dans un cluster Kubernetes. Le fichier correspondant se situe ici : "elastic/cloud-vote-all-in-one-redis-aks.yaml". Pour commencer, concernant l'interface utilisateur "cloud-vote-front", les variables requises pour l'agent APM mentionné ci-dessus sont définies comme variables environnementales dans les spécifications de conteneur. Ici, aucune annotation spécifique aux pods n'est indiquée, c'est pourquoi les logs et les indicateurs sont tous acquis à l'aide des paramètres par défaut.

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"

D'un autre côté, le back-end, "cloud-vote-redis", utilise des "annotations" de pod afin d'activer le module Redis Filebeat pour les logs et le module Redis Metricbeat pour les indicateurs, en appliquant tous les paramètres nécessaires. Tandis que cloud-vote-front utilise les paramètres par défaut pour collecter les logs et les indicateurs avec Beats, cloud-vote-back utilise le module Redis de Beats pour collecter les logs et les indicateurs. Aussi, en configurant la manière de collecter les logs et les indicateurs dans le manifeste de l'application au lieu du manifeste de Beats, vous pouvez séparer les responsabilités entre l'équipe de développement et l'équipe de plateforme 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

Accès à Kibana

Nous avons maintenant déployé toutes les composantes requises. Votons quelques fois avec Cloud-Voting-App, puis accédons à Kibana.

Présentation d'Observability

Tout d'abord, quand vous ouvrez Elastic Observability dans Kibana, les taux de log des entrées de log issues de Filebeat et le résumé des entrées d'indicateur issues de Metricbeat s'affichent sans que vous ayez à faire quoi ce soit. Cela est dû au fait que Filebeat et Metricbeat ingèrent des données au format ECS par défaut.

Logs

Les logs ingérés par Filebeat sont stockés dans les index filebeat-*. Vous pouvez utiliser l'application Logs sur Kibana pour rechercher, filtrer et suivre tous les fichiers collectés dans Elasticsearch. Vous pouvez également surligner des chaînes spécifiques. Par exemple, nous avons surligné cloud-vote-front dans l'exemple ci-dessous.

Indicateurs

Les indicateurs ingérés par Metricbeat sont stockés dans les index metricbeat-*. L'application Metrics dans Kibana offre un moyen intuitif et facile à comprendre pour afficher les indicateurs collectés dans Elasticsearch. La vue "Kubernetes Pods", comme illustré ci-dessous, permet de cartographier les nœuds et pods Kubernetes, et d'afficher l'utilisation de chaque ressource.

Par ailleurs, vous pouvez cliquer sur un pod précis pour passer à d'autres applications telles que les logs de pod ou les traces d'APM, tout en préservant le contexte. Notez que "View details for kubernetes.pod.uid a47d81b1-02d7-481a-91d4-1db9fe82d7a7" s'affiche à l'écran.

Vous pouvez alors accéder aux logs de ce pod en cliquant sur "Kubernetes Pods logs". Avez-vous remarqué que la barre de recherche dans l'application Logs était déjà remplie par "kubernetes.pod.uid: a47d81b1-02d7-481a-91d4-1db9fe82d7a7" ? En préservant le contexte de cette façon, Kibana peut passer d'application en application en toute fluidité et proposer immédiatement les résultats pertinents.

Que sont devenus les indicateurs personnalisés Prometheus ? Les indicateurs personnalisés détenus par le client Python Prometheus sont écrits dans des index appelés apm-* via l'agent APM Elastic. Si vous vérifiez dans Kibana Discover, vous les verrez collectés dans le champ "prometheus.metrics.cloud_votes". La variable dans la demande POST est stockée comme "labels.vote". Merci de vous reporter à la documentation APM pour plus d'informations sur la collecte d'indicateurs personnalisés Prometheus à l'aide de l'agent APM Elastic Python.

Vous pouvez facilement visualiser les index apm-* avec Kibana Lens comme suit.

Tableaux de bord prédéfinis

Pour le pod "cloud-vote-back" à l'aide de Redis, nous avons activé le module Redis pour Filebeat et Metricbeat. Cela entraînera aussi la création préalable des tableaux de bord associés, prêts à l'emploi. Vous pouvez visualiser instantanément les logs et indicateurs Redis sans configuration supplémentaire.

De plus, le tableau de bord Kubernetes est prêt à l'emploi grâce au module Kubernetes de Metricbeat.

Récapitulons

Dans cet article, nous avons traité de l'utilisation de Filebeat et de Metricbeat à la manière d'Elastic, dans le but de remplir Elastic Stack par des logs et des indicateurs permettant de monitorer Kubernetes. Nous avons également vu comment utiliser l'agent APM Elastic pour obtenir des indicateurs personnalisés Prometheus. Vous pouvez commencer à monitorer vos environnements Kubernetes en vous inscrivant à un essai gratuit d'Elastic Cloud ou en téléchargeant Elastic Stack et en l'hébergeant vous-même. Elastic Observability offre un monitoring plus efficace et rentable. Il est également possible de l'intégrer au machine learning Elastic et à l'alerting Kibana afin de mettre en place une observabilité hautement automatisée, exploitable et complète. Si vous rencontrez des difficultés ou si vous avez des questions, allez dans nos forums de discussion, nous sommes là pour vous aider.

Dans un futur article complémentaire, vous découvrirez d'autres manières d'employer Elastic pour monitorer Kubernetes.