For AI agents: the complete documentation index is available at https://docs.ovhcloud.com/fr/llms.txt, the full documentation bundle is available at https://docs.ovhcloud.com/fr/llms-full.txt, and this page is available as Markdown at https://docs.ovhcloud.com/fr/guides/manage-and-operate/observability/logs-data-platform/kubernetes-fluent-bit.md.

Envoyer les logs d'un cluster Kubernetes vers Logs Data Platform avec Fluent Bit

Voir en Markdown

Tous les logs de vos pods au même endroit

Objectif

Dans ce tutoriel, vous apprendrez à collecter les logs des pods d'un cluster Kubernetes et à les envoyer vers Logs Data Platform.

Kubernetes est le standard de fait pour gérer des applications conteneurisées sur les plateformes cloud. Il est open source, dispose d'un large écosystème et d'une communauté en constante progression. Une fois vos conteneurs en production dans le cloud, vous devez néanmoins pouvoir superviser leur comportement. Plus vous avez de conteneurs, plus il peut être difficile de naviguer dans les logs et d'avoir une vision claire de ce qui se passe. Comment centraliser au même endroit tous les logs de vos pods Kubernetes et les analyser facilement ? En utilisant Logs Data Platform avec l'aide de Fluent Bit. Fluent Bit est un processeur et forwarder de logs rapide et léger. Il est open source, orienté cloud et fait partie de l'écosystème Fluentd. Ce tutoriel vous aidera à le configurer pour Logs Data Platform ; vous pouvez évidemment l'appliquer à notre offre Kubernetes entièrement managée.

Prérequis

Notez que pour réaliser ce tutoriel, vous devez au minimum :

Préparation

Avant d'aborder ce tutoriel, il est important de comprendre comment nous allons déployer Fluent Bit. La configuration de Fluent Bit sera similaire à celle que vous pouvez trouver dans la documentation officielle. Fluent Bit sera déployé en tant que DaemonSet sur chaque nœud du cluster Kubernetes, via une installation Helm. Helm est un gestionnaire de paquets pour Kubernetes qui peut simplifier le déploiement d'applications sur Kubernetes. Par défaut, Fluent Bit lira, analysera et enverra chaque log de chaque pod de votre cluster. Il enrichira également chaque log de précieuses métadonnées telles que le nom et l'identifiant du pod, le nom et les identifiants du conteneur, les labels et les annotations. Comme indiqué dans la documentation de Fluent Bit, un filtre Kubernetes intégré utilisera l'API Kubernetes pour recueillir une partie de ces informations. Cette configuration a été testée avec Kubernetes 1.30 et l'image Fluent Bit 2.2.2.

En pratique

Nous allons configurer Fluent Bit en suivant ces étapes :

  • Créer le namespace logging dans lequel le déploiement de Fluent Bit sera hébergé.
  • Définir les valeurs Helm qui seront utilisées dans la configuration de Fluent Bit.
  • Installer le DaemonSet avec Helm afin de lancer Fluent Bit.

Namespace

Exécutez la commande suivante afin de créer le namespace de Fluent Bit :

kubectl create namespace logging

Configuration

Une fois le namespace créé, nous pouvons passer aux étapes suivantes : définir un secret pour la valeur X-OVH-TOKEN du jeton de votre flux.

Création du secret contenant le jeton

Il existe plusieurs méthodes pour créer un secret dans Kubernetes. Par souci de concision, nous utiliserons la version en une seule ligne de la création de secret.

kubectl --namespace logging create secret generic ldp-token --from-literal=ldp-token=<your-token-value>

Nous créons un secret ldp-token comportant une seule clé, nommée ldp-token, ayant pour valeur celle de notre jeton. Remplacez la valeur your-token-value par celle de votre jeton.

Valeurs Helm

L'installation via Helm est documentée dans la documentation Fluent Bit. Nous allons personnaliser les valeurs utilisées par l'installation Helm afin de modifier la configuration de Fluent Bit avant son déploiement.

Les valeurs par défaut du fichier de configuration du paquet Helm se trouvent ici : https://github.com/fluent/helm-charts/blob/main/charts/fluent-bit/values.yaml.

Par souci de concision, nous détaillerons uniquement la partie dans laquelle nous modifions les valeurs par défaut. Veillez à consulter les valeurs par défaut de l'ensemble du fichier afin de l'adapter à votre configuration Kubernetes.

Recherchez la configuration env: dans le fichier et ajoutez les valeurs suivantes afin d'utiliser votre secret comme variable d'environnement.

env:
  - name: FLUENT_LDP_TOKEN
    valueFrom:
      secretKeyRef:
        name: ldp-token
        key: ldp-token

Nous devons maintenant ajouter plusieurs filtres afin d'ajouter le jeton et de formater les enregistrements de logs pour la sortie GELF de Fluent Bit.

config:
  filters: |
    [FILTER]
        Name kubernetes
        Match kube.*
        Merge_Log On
        Keep_Log Off
        K8S-Logging.Parser On
        K8S-Logging.Exclude On

    [FILTER]
        Name record_modifier
        Match *
        Record X-OVH-TOKEN ${FLUENT_LDP_TOKEN}

    [FILTER]
        Name nest
        Match *
        Wildcard pod_name
        Operation lift
        Nested_under kubernetes
        Add_prefix kubernetes_

    [FILTER]
        Name modify
        Match *
        Copy kubernetes_pod_name host

    [FILTER]
        Name modify
        Match *
        Add log "none"
  • Le premier filtre analyse les messages entrants et ajoute toutes les métadonnées (pod, conteneur, images).
  • Le deuxième filtre ajoute le X-OVH-TOKEN en utilisant la variable d'environnement que nous avons configurée précédemment.
  • Le troisième filtre garantit que toutes les métadonnées Kubernetes sont aplaties au premier niveau de l'enregistrement, afin de pouvoir être utilisées comme champs.
  • Le quatrième filtre copie le nom du pod dans la clé host, afin que cette valeur soit correctement renseignée. Vous êtes libre d'utiliser ici toute autre valeur de métadonnée qui correspondrait à vos besoins.
  • Le dernier filtre garantit qu'il y a toujours une valeur pour le champ log. Ce champ sera utilisé comme clé short_message pour la sortie GELF et ne peut donc pas être vide. Certains logiciels peuvent placer leurs messages de logs dans un autre champ que log. Cela évitera que ces messages de logs soient perdus.

Nous pouvons maintenant fournir la configuration de sortie qui enverra les logs vers Logs Data Platform au format GELF. Ajoutez-la sous la même clé config: que le bloc filters: ci-dessus.

  outputs: |
    [OUTPUT]
        Name gelf
        Match kube.*
        Host graX.logs.ovh.com
        Port 12202
        Mode tls
        tls On
        Compress False
        Gelf_Short_Message_Key log

Dans cette configuration de sortie GELF, nous utilisons l'adresse graX.logs.ovh.com. Remplacez-la par l'adresse réelle de votre compte Logs Data Platform. Le port utilisé est celui de GELF et tls est activé. Notez que Gelf_Short_Message_Key est défini à log, car c'est là que se trouve le champ de log principal de Kubernetes.

Lancer Fluent Bit

Vous devez d'abord ajouter le dépôt Helm à l'aide de la commande suivante :

helm repo add fluent https://fluent.github.io/helm-charts

Utilisez ensuite la commande helm suivante afin de déployer Fluent Bit sur votre plateforme :

helm upgrade --install --namespace logging  -f values.yaml fluent-bit fluent/fluent-bit

values.yaml est le fichier qui contient la configuration modifiée.

Vérifiez que les pods fonctionnent correctement à l'aide de la commande :

kubectl get pods --namespace logging

Vous pouvez maintenant vous rendre sur l'interface du flux pour constater que vos logs sont correctement structurés.

Flux Graylog affichant une entrée de log Kubernetes avec ses métadonnées en champs distincts

L'activité de votre cluster Kubernetes est désormais entièrement journalisée au même endroit.

Aller plus loin

Cette page vous a-t-elle aidé ?