Qu’est-ce que les journaux réseau de conteneurs ?

Les journaux réseau de conteneurs dans Advanced Container Networking Services pour Azure Kubernetes Service (AKS) vous donnent une visibilité sur chaque flux réseau au sein de votre cluster. Les métriques vous indiquent ce qui se passe dans votre réseau (utilisation de la bande passante, taux d’erreur). Les journaux vous indiquent pourquoi : qui a lancé une connexion, quels protocoles ont été utilisés et si le trafic a été autorisé ou bloqué.

Ces journaux de bord enregistrent les métadonnées pour chaque flux réseau :

• Adresses IP source et de destination, noms de pods et noms de service
• Espaces de noms, ports et protocoles
• Direction du trafic et verdicts de stratégie

Avec ce contexte, vous pouvez mettre en corrélation le comportement réseau avec des charges de travail spécifiques, résoudre les problèmes de connectivité, valider des stratégies de sécurité et effectuer une analyse légale. Les journaux réseau de conteneurs couvrent le trafic de couche 3 (IP), de couche 4 (TCP/UDP) et de couche 7 (HTTP/gRPC/Kafka).

Pour gérer le volume et le coût des données, les journaux réseau de conteneurs prennent en charge l’agrégation des journaux de flux, qui regroupe des flux similaires dans des enregistrements résumés au lieu de stocker un enregistrement par événement de connexion. Vous conservez les modèles opérationnels dont vous avez besoin tout en réduisant les coûts de stockage et d’ingestion. Pour plus d’informations, consultez Agrégation du journal de flux.

Les journaux réseau de conteneurs offrent deux modes :

• Journaux stockés : collecte continue avec des filtres personnalisés et l’agrégation de flux. Idéal pour la surveillance et l’analyse à long terme.
• Journaux à la demande : capture en temps réel via le CLI Hubble et l'UI Hubble. Idéal pour la résolution des problèmes ad hoc.

Utilisez les journaux stockés lorsque vous avez besoin d’enregistrements persistants pour la conformité, l’analyse des tendances ou les alertes automatisées. Utilisez les journaux à la demande lorsque vous déboguez activement un problème de connectivité ou de performances et que vous avez besoin d’une visibilité immédiate sur le trafic en direct.

Logs sauvegardés

Le mode journaux stockés est activé automatiquement chaque fois que Advanced Container Networking Services est activé sur un cluster. La fonctionnalité est en place, mais aucun journal n’est généré tant que vous n’avez pas indiqué à ACNS ce qu’il faut capturer.

Pour commencer à collecter des journaux, définissez des ContainerNetworkLog ressources personnalisées qui spécifient le trafic à surveiller : par espace de noms, pod, service, protocole ou verdict. Une fois qu’un CRD est appliqué, l’agent Cilium commence à générer des flux qui correspondent à ses filtres et les écrit sur chaque nœud. La collection reste active jusqu’à ce que vous supprimiez les CRDs ou désactiviez ACNS.

Étant donné que vous contrôlez exactement le trafic enregistré via des filtres CRD, vous pouvez vous concentrer sur les flux qui importent et éviter de collecter des données inutiles. Combinée à l’agrégation des journaux de flux, cette approche maintient les coûts de stockage prévisibles et concentre l'analyse.

Fonctionnement du mode Journaux stockés

Advanced Container Networking Services utilise la technologie eBPF avec Cilium pour capturer les flux réseau sur chaque nœud. Une fois qu’ACNS est activé et qu’une ContainerNetworkLog ressource personnalisée est appliquée, l’agent Cilium collecte le trafic qui correspond au filtre et écrit les journaux au format JSON sur /var/log/acns/hubble/events.log sur chaque hôte. La génération de journaux s'exécute entièrement à l'intérieur du cluster et ne dépend pas d'Azure Monitor.

Pour une utilisation en production, nous vous recommandons d’activer le module complémentaire Azure Monitor. Lorsqu'ils sont activés, les agents de Container Insights collectent les journaux locaux de l'hôte, appliquent des limites de taux et les envoient à un espace de travail Log Analytics, où vous bénéficiez d'une rétention à long terme, de requêtes KQL, ainsi que des tableaux de bord intégrés sur Azure Portal et Grafana. Il s’agit du chemin le plus intégré et celui que la plupart des clients doivent choisir.

Si votre équipe dispose d’un pipeline d’observabilité existant, vous pouvez transférer les mêmes journaux locaux de l'hôte vers n’importe quel collecteur compatible OpenTelemetry ou service de journalisation, en parallèle avec Azure Monitor ou à sa place.

Pour plus d’informations sur la limitation et Container Insights, consultez la documentation de Container Insights.

Utilisation des journaux de réseau de conteneurs avec ou sans Azure Monitor

Vous pouvez consommer les journaux des réseaux de conteneurs de deux façons. Le bon choix varie selon que vous souhaitez une expérience intégrée Azure native ou que vous disposez déjà d’un pipeline d’observabilité que vous souhaitez continuer à utiliser.

Pour la plupart des clients, nous vous recommandons d’activer Azure Monitor. Il s’agit du moyen le plus rapide d’obtenir des fonctionnalités de rétention, de requête et de tableau de bord sans créer votre propre pipeline.

Fonctionnalités clés du mode journaux stockés

• Filtres personnalisables. Définissez des ContainerNetworkLog ressources personnalisées pour filtrer par espace de noms, pod, service, port, protocole, verdict ou direction du trafic. Seul le trafic correspondant est journalisé, de sorte que vous obtenez un contrôle précis sur ce qui est collecté et ce qu’il coûte.

• Agrégation du journal de flux. Des flux similaires sont automatiquement regroupés en enregistrements résumés toutes les 30 secondes, ce qui réduit le volume de données tout en préservant les signaux opérationnels tels que les modèles de communication de service, les taux d’erreur et les verdicts de sécurité. Couplé avec des filtres ciblés, l’agrégation vous permet de maintenir une visibilité étendue sans coûts d’ingestion excessifs. Pour plus d’informations, consultez Agrégation du journal de flux.

• Options de stockage des journaux. ACNS enregistre toujours les journaux localement sur chaque nœud. À partir de là, vous pouvez choisir comment les consommer :

  • Fichiers locaux hôtes (toujours activés) : Les journaux sont stockés sur les nœuds hôtes à l’adresse /var/log/acns/hubble. Les fichiers pivotent automatiquement à 50 Mo et les journaux plus anciens sont remplacés. Utilisez-le directement pour la surveillance en temps réel à court terme ou transférez les fichiers à n’importe quel collecteur ou service de journalisation compatible OpenTelemetry pour une gestion supplémentaire des journaux.

  • Azure Monitor (recommandé) : Activez le module complémentaire Azure Monitor pour collecter et stocker des journaux dans un espace de travail Log Analytics. Vous bénéficiez d’un stockage sécurisé et conforme avec la rétention à long terme, les requêtes KQL, la détection des anomalies, l’analyse historique et les alertes via le service managé pour Prometheus. La génération de journaux continue de fonctionner via l’agent Cilium et le ContainerNetworkLog CRD ; Azure Monitor ajoute la couche de consommation au-dessus.

    La ContainerNetworkLogs table utilise le niveau Analytics par défaut. Vous pouvez passer au niveau De base pour réduire les coûts d’ingestion et de rétention tout en conservant une expérience d’observabilité similaire. Chaque niveau dispose d’un tableau de bord dédié Azure portail optimisé pour ses fonctionnalités de requête. Pour plus d’informations sur les plans des tables, consultez Log Analytics table plans. Pour savoir comment définir le plan de table, consultez Définir le plan de table.

• Visualisation dans le portail Azure. Interrogez et analysez les journaux directement dans Log Analytics, ou utilisez les tableaux de bord intégrés du portail Azure. Un tableau de bord dédié est disponible pour chaque niveau de table. Vous bénéficiez donc de la même expérience d’observabilité, quel que soit le niveau que vous choisissez. Pour plus d’informations, consultez Visualiser les journaux dans le portail Azure.

Visualisez les journaux dans le portail Azure

Vous pouvez visualiser, interroger et analyser les journaux de flux dans le portail Azure dans l’espace de travail Log Analytics de votre cluster.

Les journaux réseau de conteneurs incluent des tableaux de bord intégrés du portail Azure pour visualiser les données de flux réseau. Un tableau de bord distinct est disponible pour chaque niveau de table Log Analytics :

Les deux tableaux de bord indiquent les charges de travail AKS qui communiquent entre elles, notamment les demandes réseau, les réponses, les suppressions et les erreurs. Utilisez le tableau de bord qui correspond au niveau de table configuré pour votre ContainerNetworkLogs table.

Les tableaux de bord du portail Azure ont les principaux composants suivants :

• Vue d’ensemble de l’intégrité du réseau. La section supérieure présente les métriques récapitulatives (nombre total de journaux de flux, demandes uniques, demandes supprimées et demandes transférées) afin de détecter rapidement les anomalies. Les statistiques sont réparties par protocole : requêtes supprimées DNS, réponses HTTP 2xx, taux de requête et de réponse de couche 4, et nombres de suppressions. Un graphique des dépendances de service montre les services qui communiquent entre eux, ce qui facilite l’identification des goulots d’étranglement et des chemins de trafic inattendus.

  

• Journaux de flux et journaux d’erreurs. Le tableau de bord sépare les journaux de flux des journaux d’erreurs dans des vues distinctes. Vous pouvez donc vous concentrer sur les erreurs sans parcourir le trafic normal. Utilisez les filtres intégrés pour affiner les résultats par protocole, espace de noms ou verdict. Par exemple, pour résoudre les échecs de résolution DNS, filtrez les journaux d’erreurs selon le protocole DNS.

  

  Chaque entrée de journal inclut des étiquettes, des horodatages et des détails source/destination pour vous aider à identifier des événements spécifiques pendant une investigation.

  

• Principaux espaces de noms, charges de travail et erreurs DNS. Cette section présente les espaces de noms les plus actifs, les charges de travail de trafic le plus élevé, l’utilisation des ports et les erreurs DNS les plus fréquentes. Utilisez-la pour identifier les charges de travail qui génèrent le plus de trafic, repérer les requêtes supprimées et comparer la distribution de protocole (par exemple, TCP et UDP). Des modèles inhabituels ici, tels que des pics inattendus ou des destinations inconnues, peuvent indiquer des configurations incorrectes ou des problèmes de sécurité.

  

Agrégation du journal de flux

Les flux réseau s’ajoutent rapidement. Un cluster avec 200 microservices peut générer des centaines de milliers d’enregistrements de flux toutes les 30 secondes. Le stockage de toutes ces données brutes coûte cher.

Par exemple, supposons que client-1 et client-2 communiquent tous les deux avec un pod server via TCP. Sur une fenêtre de 30 secondes, les enregistrements de flux bruts sur le nœud ressemblent à ceci :

Avec l’agrégation, ces 10 enregistrements deviennent deux :

L’agrégation des journaux de flux s’en attaque en regroupant des flux similaires dans des enregistrements résumés. Pendant chaque fenêtre de 30 secondes, les flux qui partagent les mêmes champs de clé d’agrégation sont combinés en un seul enregistrement avec le nombre de flux qu’il représente.

Les champs suivants composent la clé d’agrégation :

Les flux correspondant à tous ces champs dans une fenêtre de 30 secondes sont fusionnés en un seul enregistrement. Cela conserve les signaux dont vous avez besoin (quels services communiquent, à quelle fréquence, quelles erreurs se produisent, que le trafic a été autorisé ou bloqué) tout en réduisant considérablement le volume de données. Contrairement à l’échantillonnage, qui ignore de façon aléatoire les flux et peut manquer des événements de sécurité rares, l’agrégation conserve 100% des informations de modèle.

Points clés :

• L’agrégation est activée et configurée par défaut. Cela diminue les coûts de stockage et d'ingestion des journaux, et ce, sans aucun réglage manuel.
• Vous contrôlez quel trafic est intercepté à travers includeFilters dans le ContainerNetworkLog CRD.
• Les filtres plus étroits (paires d’espaces de noms ou de services spécifiques) obtiennent généralement une meilleure compression, car les flux capturés sont plus similaires.
• Les journaux agrégés ignorent la cardinalité élevée et les attributs par flux (par exemple, les horodatages individuels, les adresses IP de pod, les URL HTTP, les noms de requête DNS) pour réduire le volume d’ingestion et le coût de stockage. Ils sont conçus pour la détection des problèmes de haut niveau. Utilisez les journaux à la demande pour l’analyse et l’examen précis des flux.

Journaux à la demande

Les journaux à la demande vous permettent de capturer et d’inspecter les journaux de flux en temps réel, sans configuration préalable ni stockage persistant. Utilisez les journaux à la demande lorsque vous résolvez activement un problème de connectivité ou de performances et que vous avez besoin d’une visibilité immédiate.

ACNS fournit deux outils pour la capture à la demande. Pour configurer l’un ou l’autre outil, consultez Configurer le mode journaux à la demande.

Hubble CLI

L’interface CLI Hubble vous permet d’interroger, de filtrer et d’analyser les journaux de flux directement à partir de votre terminal. Il est particulièrement utile lorsque vous avez besoin de filtres détaillés, par exemple pour isoler le trafic par espace de noms, label de pod ou verdict pendant une session de débogage active.

Interface utilisateur Hubble

L’interface utilisateur Hubble fournit une vue graphique de la communication de service à service. Il est judicieux de suivre visuellement les chemins de trafic, d’identifier les services qui communiquent et de repérer les anomalies sans écrire de commandes CLI.

Principaux avantages des logs sur demande

• Aucune configuration antérieure n’est requise. Commencez à capturer des flux immédiatement sans définir de ressources personnalisées ou configurer le stockage.
• Visibilité en temps réel. Inspectez le trafic en direct et affichez les métadonnées des paquets à mesure que des problèmes se produisent.
• Résolution rapide des problèmes. Filtrez les flux de manière interactive via l’interface CLI Hubble ou affichez visuellement les mappages de service dans l’interface utilisateur Hubble.
• Faible surcoût. Aucun stockage persistant requis, il n’y a donc aucun coût continu pour les enquêtes ad hoc.

Recommandations pour les journaux de bord stockés

1. Commencez par des filtres larges, puis réduisez les données. Lorsque vous activez d’abord les journaux de flux, utilisez des filtres larges pour capturer le trafic entre vos espaces de noms clés. Exécutez la configuration pendant quelques jours et passez en revue les données collectées dans Log Analytics. Examinez le volume de données, le coût et si les flux capturés correspondent à ce dont vous avez réellement besoin. Ensuite, concentrez votre includeFilters pour vous focaliser sur le trafic de grande valeur et éliminer le bruit.

2. Utilisez d'abord les tableaux de bord prédéfinis. Les tableaux de bord intégrés Azure portail couvrent les cas d’usage courants tels que les modèles de communication de service, les taux d’erreur et les échecs DNS. Commencez là. Ajoutez des panels personnalisés ou des requêtes Log Analytics uniquement si vous avez besoin de visibilité que les tableaux de bord préconstruits ne fournissent pas.

3. Passez régulièrement en revue. À mesure que les charges de travail et les modèles de trafic changent, vos filtres peuvent avoir besoin de la mise à jour. Vérifiez régulièrement le volume de données et la couverture des flux pour vous assurer que vous capturez toujours le trafic approprié à un coût raisonnable.

Limites

Configuration requise pour le plan de données et les fonctionnalités :

• Le mode journaux stockés fonctionne uniquement avec le plan de données Cilium.
• Les journaux de flux de couche 7 sont capturés uniquement lorsque la prise en charge de la politique de couche 7 est activée. Pour plus d’informations, consultez Configurer une stratégie de couche 7.
• Les flux et métriques DNS sont capturés uniquement lorsqu’une stratégie réseau de nom de domaine complet (FQDN) Cilium est appliquée. Pour plus d’informations, consultez Configurer une stratégie de nom de domaine complet.

Compromis d’agrégation :

• L’agrégation des journaux de flux ne conserve pas les horodatages de flux individuels, les adresses IP par pod ou les champs de cardinalité élevée, tels que les URL HTTP et les noms de requêtes DNS. Utilisez les journaux à la demande pour l'analyse par flux.

Stockage et plateforme :

• Le fichier local hôte est limité à /var/log/acns/hubble/ 50 Mo par nœud et effectue une rotation automatique. Si vous avez besoin de rétention à long terme, activez Azure Monitor (recommandé) ou transférez le fichier à votre propre service de journalisation.
• Le plan de table Journaux auxiliaires n’est pas pris en charge.

Tarification

Pour plus d’informations sur la tarification, consultez Tarification des services avancés de mise en réseau de conteneurs.

Contenu connexe

• Configurer les journaux de bord du réseau de conteneurs
• Services de mise en réseau avancés pour conteneurs AKS
• Observabilité du réseau de conteneurs dans Advanced Container Networking Services
• Sécurité du réseau de conteneurs dans Advanced Container Networking Services