Journalisation et surveillance de l'équilibrage de charge TCP/UDP interne

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Ce document explique comment configurer et utiliser Cloud Logging et Cloud Monitoring pour l'équilibrage de charge TCP/UDP interne.

Logging

Les journaux fournissent des informations utiles pour dépanner et surveiller l'équilibreur de charge pass-through Google Cloud. Les journaux sont agrégés par connexion et exportés en quasi-temps réel. Les journaux sont générés pour chaque flux TCP et UDP des instances à équilibrage de charge pour le trafic entrant et sortant. Pour en savoir plus sur les champs fournis dans l'entrée de journal, consultez la section Champs de journal.

L'utilisation des journaux n'entraîne aucuns frais supplémentaires. Selon la manière dont vous ingérez les journaux, les tarifs standards pour Cloud Logging, BigQuery ou Pub/Sub s'appliquent. L'activation des journaux n'a aucun effet sur les performances de l'équilibreur de charge.

Avantages

Voici les avantages de l'utilisation de la journalisation :

Surveillance du trafic de l'équilibreur de charge TCP/UDP interne

La journalisation par connexion vous indique comment chaque connexion est acheminée vers les backends de diffusion.

Dépannage du réseau

Vous pouvez utiliser les journaux de l'équilibreur de charge TCP/UDP interne pour le dépannage. Pour en savoir plus, consultez la page Résoudre les problèmes liés à l'équilibreur de charge TCP/UDP interne.

Exemple de format de journal pour les flux entre plusieurs VM

Le schéma suivant illustre le trafic entrant et sortant pour un client interne (192.168.1.2), un équilibreur de charge TCP/UDP interne (10.240.0.200) et une instance backend (10.240.0.3).

Flux entre des clients internes et des services de VM de backend.
Flux entrants et sortants pour les flux entre plusieurs VM.

Les journaux de l'équilibreur de charge TCP/UDP interne pour les connexions du client à l'instance backend sont formatés comme suit :

  • connection.clientIp : 192.168.1.2
  • connection.serverIp : 10.240.0.200
  • bytesSent : 1256
  • bytesReceived : 4521

Échantillonnage et collecte des journaux

Google Cloud échantillonne les paquets qui quittent les VM de backend de l'équilibreur de charge et y entrent. Ces paquets échantillonnés sont traités afin de générer des journaux.

Tous les paquets ne sont pas échantillonnés. Google Cloud échantillonne un sous-ensemble variable de paquets en fonction du volume de trafic sur l'hôte physique. Le taux d'échantillonnage le plus faible est de un paquet sur 1 024. Le taux d'échantillonnage est contrôlé de manière dynamique par Google Cloud. Vous ne pouvez pas l'ajuster.

L'échantillonnage de paquets interagit avec les règles de pare-feu de la manière suivante :

  • Les paquets sont échantillonnés avant l'application des règles de pare-feu de sortie.
  • Les paquets sont échantillonnés après l'application des règles de pare-feu d'entrée.

Après échantillonnage des paquets, Google Cloud traite les paquets échantillonnés en suivant la procédure suivante :

  1. Agrégation : les paquets échantillonnés sont agrégés sur un intervalle de cinq secondes pour produire une seule entrée de flux.

  2. Échantillonnage de journal configurable (secondaire) : il s'agit d'un deuxième processus d'échantillonnage, qui échantillonne les flux. Vous contrôlez la fraction des entrées de flux qui sont émises en tant qu'entrées de journal grâce au paramètre logConfig.sampleRate. Lorsque la valeur de logConfig.sampleRate est définie sur 1.0 (100 %), cela signifie que tous les paquets échantillonnés sont traités.

  3. Écriture dans Logging : les entrées de journal sont écrites dans Cloud Logging.

Exigences relatives à l'adresse IP source du paquet de réponse

La journalisation de l'équilibrage de charge TCP/UDP interne n'échantillonne les paquets de réponse des VM de backend que si l'adresse IP source de ces paquets correspond à l'adresse IP de la règle de transfert de l'équilibreur de charge à laquelle un paquet de requête correspondant a été envoyé. Pour les connexions TCP, les paquets de réponse doivent toujours avoir des sources correspondant à la destination du paquet de requête. Toutefois, pour d'autres protocoles, il est possible que les paquets de réponse utilisent une adresse IP source différente. Pour plus d'informations, consultez la section Adresses IP pour les paquets de requêtes et de retours.

Le processus d'échantillonnage des paquets utilisé par la journalisation de l'équilibrage de charge TCP/UDP interne omet tous les paquets de réponse des VM de backend, si ces paquets ont des sources qui ne correspondent pas à l'adresse IP d'une règle de transfert pour un équilibreur de charge TCP/UDP interne.

Activer la journalisation pour un nouveau service de backend

gcloud

Créez un service de backend et activez la journalisation à l'aide de la commande gcloud beta compute backend-services create.

gcloud beta compute backend-services create BACKEND_SERVICE \
--region=REGION \
--enable-logging \
--logging-sample-rate=SAMPLE_RATE

Remplacez les éléments suivants :

  • BACKEND_SERVICE : nom du service de backend.
  • REGION 00: région du service de backend à créer.
  • SAMPLE_RATE : ce champ ne peut être spécifié que si la journalisation est activée pour ce service de backend. La valeur du champ doit être comprise entre 0,0 et 1,0 ; où 0,0 signifie qu'aucun journal n'est signalé et 1,0 si toutes les requêtes consignées sont signalées. L'activation de la journalisation en définissant le taux d'échantillonnage sur 0.0 équivaut à désactiver la journalisation. La valeur par défaut est 1.0.

api

Envoyez une requête POST à la méthode regionBackendServices.insert.

POST https://compute.googleapis.com/compute/beta/projects/PROJECT_ID/regions/REGION/backendServices

 {
 "name": "BACKEND_SERVICE",
  "loadBalancingScheme": "INTERNAL",
  "logConfig": {
   "enable": true,
   "sampleRate": SAMPLE_RATE
  }
 }
 

Activer la journalisation sur un service de backend existant

gcloud

Activez la journalisation sur un service de backend existant à l'aide de la commande gcloud beta compute backend-services update.

gcloud beta compute backend-services update BACKEND_SERVICE \
--region=REGION \
--enable-logging \
--logging-sample-rate=SAMPLE_RATE

Remplacez les éléments suivants :

  • BACKEND_SERVICE : nom du service de backend.
  • REGION 00: région du service de backend à créer.
  • SAMPLE_RATE : ce champ ne peut être spécifié que si la journalisation est activée pour ce service de backend. La valeur du champ doit être comprise entre 0,0 et 1,0 ; où 0,0 signifie qu'aucun journal n'est signalé et 1,0 si toutes les requêtes consignées sont signalées. L'activation de la journalisation en définissant le taux d'échantillonnage sur 0.0 équivaut à désactiver la journalisation. La valeur par défaut est 1.0.

api

Envoyez une requête PATCH à la méthode regionBackendServices/patch.

PATCH https://compute.googleapis.com/compute/beta/projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE

 {
 "logConfig": {
   "enable": true,
   "sampleRate": SAMPLE_RATE
  }
 }
 

Activer la journalisation sur un service de backend existant

gcloud

Désactivez la journalisation sur un service de backend à l'aide de la commande gcloud beta compute backend-services update.

gcloud beta compute backend-services update BACKEND_SERVICE \
--region=REGION \
--no-enable-logging

Remplacez les éléments suivants :

  • BACKEND_SERVICE : nom du service de backend.
  • REGION 00: région du service de backend à créer.

api

Envoyez une requête PATCH à la méthode regionBackendServices/patch.

PATCH https://compute.googleapis.com/compute/beta/projects/PROJECT_ID/regions/REGION/backendServices/BACKEND_SERVICE

 {
 "logConfig": {
   "enable": false
  }
 }
 

Afficher les journaux

Lorsque les journaux sont ingérés dans Cloud Logging et non exclus via un récepteur de routeur de journaux, vous pouvez les lire à l'aide de l'API Cloud Logging et de la Google Cloud CLI.

Pour afficher tous les journaux d'équilibreurs de charge TCP/UDP internes, procédez comme suit :

Console

  1. Dans Google Cloud Console, accédez à la page Explorateur de journaux.
    Accéder à l'explorateur de journaux
  2. Sélectionnez le type de ressource Règle d'équilibreur de charge réseau interne Google Cloud.
  3. Sélectionnez le nom du journal loadbalancing.googleapis.com/flows.

Requête de la console

  1. Dans Google Cloud Console, accédez à la page Explorateur de journaux.
    Accéder à l'explorateur de journaux
  2. Cliquez sur le bouton Afficher la requête.
  3. Collez le texte suivant dans le champ de la requête. Veillez à remplacer PROJECT_ID par l'ID de votre projet.
    resource.type="loadbalancing.googleapis.com/InternalNetworkLoadBalancerRule"
    logName="projects/PROJECT_ID/logs/loadbalancing.googleapis.com%2Fflows"
    
  4. Cliquez sur Exécuter la requête.

Afficher les journaux d'un service de backend spécifique

Pour afficher les journaux de l'équilibreur de charge TCP/UDP interne pour un service de backend spécifique, procédez comme suit :

Console

  1. Dans Google Cloud Console, accédez à la page Explorateur de journaux.
    Accéder à l'explorateur de journaux
  2. Activez l'option Champs de journal.
  3. Sélectionnez le type de ressource Règle d'équilibreur de charge réseau interne Google Cloud.
  4. Sélectionnez le nom du journal loadbalancing.googleapis.com/flows.

Requête de la console

  1. Dans Google Cloud Console, accédez à la page Explorateur de journaux.
    Accéder à l'explorateur de journaux
  2. Cliquez sur le bouton Afficher la requête.
  3. Collez le texte suivant dans le champ de la requête. Assurez-vous de remplacer PROJECT_ID par l'ID de votre projet et BACKEND_SERVICE_NAME par le nom de votre service de backend.
    resource.type="loadbalancing.googleapis.com/InternalNetworkLoadBalancerRule"
    logName="projects/PROJECT_ID/logs/loadbalancing.googleapis.com%2Fflows"
    resource.labels.backend_service_name="BACKEND_SERVICE_NAME"
    
  4. Cliquez sur Exécuter la requête.

Afficher les journaux pour un backend spécifique

Pour afficher les journaux de l'équilibreur de charge TCP/UDP interne pour un groupe d'instances backend ou groupe de points de terminaison du réseau (NEG) spécifique avec des points de terminaison GCE_VM_IP, procédez comme suit :

Console

  1. Dans Google Cloud Console, accédez à la page Explorateur de journaux.
    Accéder à l'explorateur de journaux
  2. Activez l'option Champs de journal.
  3. Sélectionnez le type de ressource Règle d'équilibreur de charge réseau interne Google Cloud.
  4. Sélectionnez le nom du journal loadbalancing.googleapis.com/flows.

Requête de la console

  1. Dans Google Cloud Console, accédez à la page Explorateur de journaux.
    Accéder à l'explorateur de journaux
  2. Cliquez sur le bouton Afficher la requête.
  3. Collez le texte suivant dans le champ de la requête. Remplacez PROJECT_ID par l'ID de votre projet et BACKEND_GROUP_NAME par le nom du groupe d'instances ou du NEG.

    resource.type="loadbalancing.googleapis.com/InternalNetworkLoadBalancerRule"
    logName="projects/PROJECT_ID/logs/loadbalancing.googleapis.com%2Fflows"
    resource.labels.backend_group_name="BACKEND_GROUP_NAME"
    
  4. Cliquez sur Exécuter la requête.

Champs de journal

Le format "structuré" de certains champs affiche plusieurs données dans un même champ. Par exemple, le champ connection est de type IpConnection, qui contient l'adresse IP source et de destination, le port et le protocole dans un seul champ. Ces champs particuliers sont décrits dans les tableaux ci-dessous.

La ressource surveillée est loadbalancing.googleapis.com/InternalNetworkLoadBalancerRule.

Champ Type Description
connexion IpConnection 5-tuple décrivant cette connexion.
startTime chaîne Horodatage (format de chaîne de date RFC 3339) du premier paquet observé pendant l'intervalle de temps cumulé
endTime chaîne Horodatage (format de chaîne de date RFC 3339) du dernier paquet observé pendant l'intervalle de temps cumulé
bytesSent int64 Nombre d'octets envoyés par le serveur au client.
bytesReceived Int64 Nombre d'octets reçus par le serveur en provenance du client.
packetsSent int64 Nombre de paquets envoyés par le serveur au client.
packetsReceived int64 Nombre de paquets reçus par le serveur depuis la destination.
rtt chaîne La latence n'est mesurée que pour les connexions TCP. La latence correspond à la somme du délai aller-retour (DAR) estimé sur le réseau et du temps dédié au traitement du paquet dans le système d'exploitation de la VM du client. Pour les paquets échantillonnés, le DAR est calculé du point de vue d'un backend à équilibrage de charge, en mesurant le temps écoulé entre le backend qui envoie un segment TCP et le backend qui reçoit un accusé de réception TCP pour le numéro de séquence du segment envoyé. La latence est formatée sous forme de chaîne commençant par le nombre de secondes et se terminant par "s" pour indiquer les secondes. Les nanosecondes sont exprimées en fractions de secondes. Par exemple, une latence de 250 millisecondes est au format "0,250000000 s".

IpConnection

Champ Type Description
clientIp chaîne Adresse IP du client
clientPort int32 Port client. Défini pour les connexions TCP et UDP uniquement.
serverIp chaîne Adresse IP du serveur (adresse IP de la règle de transfert)
serverPort int32 Port du serveur. Défini pour les connexions TCP et UDP uniquement.
protocole int32 Numéro de protocole IANA

Monitoring

L'équilibrage de charge TCP/UDP interne exporte les données de surveillance vers Cloud Monitoring.

Les métriques de surveillance peuvent être utilisées aux fins suivantes :

  • Évaluation de la configuration, de l'utilisation et des performances d'un équilibreur de charge TCP/UDP interne
  • Dépannage
  • Améliorer l'utilisation des ressources et l'expérience utilisateur

En plus des tableaux de bord prédéfinis proposés dans Monitoring, vous pouvez créer des tableaux de bord personnalisés, configurer des alertes et interroger les métriques via l'API Monitoring.

Afficher les tableaux de bord Monitoring

  1. Dans Google Cloud Console, accédez à Monitoring.
    Accéder à Monitoring
  2. Si Ressources apparaît dans le volet de navigation, sélectionnez Ressources, puis Équilibreurs de charge Google Cloud. Sinon, sélectionnez Tableaux de bord, puis le tableau de bord intitulé Équilibreurs de charge Google Cloud.
  3. Cliquez sur le nom de votre équilibreur de charge.

Le volet de gauche affiche diverses informations sur l'équilibreur de charge sélectionné. Le volet de droite présente les graphiques de séries temporelles. Cliquez sur le lien Breakdowns (Répartitions) pour afficher des répartitions spécifiques. Le volet de gauche présente les données actuellement configurées, tandis que le volet de droite peut présenter des données diffusées par des configurations historiques qui ne sont pas reflétées dans le volet de gauche.

Définir des tableaux de bord Monitoring personnalisés

Vous pouvez créer des tableaux de bord Monitoring personnalisés pour les métriques d'équilibrage de charge TCP/UDP interne :

  1. Dans Google Cloud Console, accédez à Monitoring.
    Accéder à Monitoring
  2. Sélectionnez Tableaux de bord > Créer un tableau de bord.
  3. Cliquez sur Ajouter un graphique.
  4. Indiquez un titre pour le graphique.
  5. Sélectionnez des métriques et des filtres. Pour les métriques, le type de ressource est Règle (interne) d'équilibreur de charge TCP Google Cloud (internal_tcp_lb_rule) ou Règle (interne) d'équilibreur de charge UDP Google Cloud (internal_udp_lb_rule).
  6. Cliquez sur Save (Enregistrer).

Définir des règles d'alerte

Vous pouvez créer des règles d'alerte pour surveiller les valeurs des métriques et être informé lorsqu'elles ne respectent pas une condition.

  1. Dans Google Cloud Console, accédez à la page Monitoring.

    Accéder à Monitoring

  2. Dans le volet de navigation Monitoring, sélectionnez  Alertes :
  3. Si vous n'avez pas créé vos canaux de notification et que vous souhaitez être averti, cliquez sur Modifier les canaux de notification et ajoutez vos canaux de notification. Revenez à la page Alertes après avoir ajouté vos canaux.
  4. Sur la page Alertes, cliquez sur Créer une règle.
  5. Pour sélectionner la métrique, développez le menu Sélectionner une métrique, puis procédez comme suit :
    1. Pour limiter le menu aux entrées pertinentes, saisissez Google Cloud TCP Load Balancer ou Google Cloud UDP Load Balancer dans la barre de filtre. Si aucun résultat ne s'affiche après avoir filtré le menu, désactivez l'option Afficher seulement les ressources et les métriques actives.
    2. Pour le champ Type de ressource, sélectionnez Équilibreur de charge TCP Google Cloud ou Équilibreur de charge UDP Google Cloud.
    3. Sélectionnez une Catégorie de métrique et une Métrique, puis cliquez sur Appliquer.
  6. Cliquez sur Suivant.
  7. Les paramètres de la page Configurer le déclencheur d'alerte déterminent le moment où l'alerte se déclenche. Sélectionnez un type de condition et, si nécessaire, spécifiez un seuil. Pour en savoir plus, consultez la section Déclencheur de condition.
  8. Cliquez sur Suivant.
  9. Facultatif : Pour ajouter des notifications à votre règle d'alerte, cliquez sur Canaux de notification. Dans la boîte de dialogue, sélectionnez un ou plusieurs canaux de notification dans le menu, puis cliquez sur OK.
  10. (Facultatif) Mettez à jour la durée de fermeture automatique de l'incident. Ce champ détermine à quel moment Monitoring ferme les incidents en l'absence de données de métriques.
  11. Facultatif : Cliquez sur Documentation, puis ajoutez les informations à inclure dans le message de notification.
  12. Cliquez sur Nom de l'alerte et saisissez un nom pour la règle d'alerte.
  13. Cliquez sur Créer une stratégie.
Pour plus d'informations, consultez la page Règles d'alerte.

Métriques des équilibreurs de charge TCP/UDP internes

Les métriques suivantes pour les équilibreurs de charge TCP/UDP internes sont indiquées dans Monitoring.

Métrique Description
Débit entrant Nombre d'octets envoyés vers les règles de transfert d'équilibreur de charge TCP/UDP interne, tels qu'ils sont reçus par les backends.
Paquets entrants Nombre de paquets envoyés vers les règles de transfert d'équilibreur de charge TCP/UDP interne, tels qu'ils sont reçus par les backends.
Débit sortant Nombre d'octets envoyés par les backends à équilibrage de charge interne sur les connexions liées aux adresses IP de règle de transfert.
Paquets sortants Nombre de paquets envoyés par les backends à équilibrage de charge interne sur les connexions liées aux adresses IP de règle de transfert.
Latence (*) Répartition du délai aller-retour (DAR) calculé pour les groupes de paquets sur chaque connexion à équilibrage de charge interne. Généralement réduite au 95e centile dans les vues Monitoring.

(*) Disponible uniquement pour le trafic TCP.

Dimensions de filtrage pour les métriques d'équilibreur de charge TCP/UDP interne

Les métriques sont agrégées pour chaque équilibreur de charge TCP/UDP interne. Ces métriques peuvent être décomposées selon les dimensions suivantes :

Propriété Description
BACKEND NAME Nom du groupe d'instances ou groupe de points de terminaison du réseau (NEG) avec des points de terminaison GCE_VM_IP.
BACKEND SCOPE Champ d'application (région ou zone) du backend ayant reçu la connexion.
BACKEND ZONE Pour les groupes d'instances zonaux et les groupes de points de terminaison du réseau, zone du backend ayant diffusé la connexion.
CLIENT NETWORK Réseau de l'instance cliente connectée à l'équilibreur de charge TCP/UDP interne.
CLIENT SUBNETWORK Sous-réseau de l'instance cliente connectée à l'équilibreur de charge TCP/UDP interne.
CLIENT ZONE Zone Google Cloud de l'instance connectée à la règle de transfert.
FORWARDING RULE Nom de la règle de transfert de l'équilibreur de charge TCP/UDP interne.

Fréquence et conservation des rapports sur les métriques

Les métriques des équilibreurs de charge TCP/UDP internes sont exportées vers Monitoring par lots de précision d'une minute. Les données de surveillance sont conservées pendant six semaines. Les métriques sont basées sur l'échantillonnage du trafic (le taux d'échantillonnage est dynamique et ne peut pas être ajusté). Le tableau de bord fournit une analyse des données à des intervalles par défaut d'une heure (1H), six heures (6H), un jour (1D), une semaine (1W) et six semaines (6W). Vous pouvez demander manuellement une analyse à un intervalle compris entre une minute et six semaines.

Étapes suivantes