Cette page a été traduite par l'API Cloud Translation.

Résoudre les problèmes liés à l'ingestion de données de l'agent Ops

Ce document fournit des informations pour vous aider à diagnostiquer et à résoudre les problèmes d'ingestion de données, pour les journaux et les métriques, dans l'agent Ops en cours d'exécution. Si l'agent Ops n'est pas en cours d'exécution, consultez la page Résoudre les problèmes liés à l'installation et au démarrage.

Avant de commencer

Avant d'essayer de résoudre un problème, vérifiez l'état des vérifications d'état de l'agent.

La console Google Cloud affiche l'installation de l'agent Ops comme bloquée sur "En attente"

Même après avoir installé l'agent Ops, la console Google Cloud peut toujours afficher un état "En attente". Utilisez gcpdiag pour confirmer l'installation de l'agent Ops et pour vérifier que l'agent Ops transmet bien les journaux et des métriques à partir de votre instance de VM.

Causes courantes d'échec de l'installation

L'installation de l'agent Ops peut échouer pour les raisons suivantes :

La VM n'est pas associée à un compte de service. Associez un compte de service à la VM, puis réinstallez l'agent Ops.
L'un des anciens agents est déjà installé sur la VM, ce qui empêche l'installation de l'agent Ops. Désinstallez les anciens agents, puis réinstallez l'agent Ops.

Causes courantes d'échec de la transmission de télémétrie

Un agent Ops installé et en cours d'exécution peut échouer à envoyer des journaux, des métriques ou les deux, à partir d'une VM, pour les raisons suivantes :

Le compte de service associé à la VM ne dispose pas du rôle roles/logging.logWriter ou du rôle roles/monitoring.metricWriter.
Le niveau d'accès pour la journalisation ou la surveillance n'est pas activé. Pour en savoir plus sur la vérification et la mise à jour des niveaux d'accès, consultez Vérifier vos niveaux d'accès.
L'API Logging ou l'API Monitoring n'est pas activée.

Utilisez les vérifications d'intégrité de l'agent pour identifier la cause première et la solution correspondante.

L'agent est en cours d'exécution, mais les données ne sont pas ingérées

Utilisez l'Explorateur de métriques pour interroger la métrique uptime de l'agent et vérifiez que le composant d'agent, google-cloud-ops-agent-metrics ou google-cloud-ops-agent-logging, écrit des données dans la métrique.

Dans la console Google Cloud, accédez à la page Explorateur de métriques :
Accéder à l'explorateur de métriques

Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Surveillance.
Dans la liste déroulante intitulée Builder Code (Code de compilateur), sélectionnez Code, puis définissez le langage sur MQL.

Saisissez la requête suivante, puis cliquez sur Exécuter :

fetch gce_instance
| metric 'agent.googleapis.com/agent/uptime'
| align rate(1m)
| every 1m

L'agent envoie-t-il des journaux à Cloud Logging ?

Si l'agent est en cours d'exécution, mais n'envoie pas de journaux, vérifiez l'état des vérifications d'état de l'environnement d'exécution de l'agent.

Erreurs de pipeline

Si vous voyez l'erreur d'exécution LogPipelineErr ("Échec de la journalisation de l'Agent Ops"), cela signifie que le sous-agent Logging a rencontré un problème avec l'écriture des journaux. Vérifiez les conditions suivantes :

Vérifiez que les fichiers de stockage du sous-agent Logging sont accessibles. Ces fichiers se trouvent aux emplacements suivants :
- Linux : /var/lib/google-cloud-ops-agent/fluent-bit/buffers/
- Windows : C:\Program Files\Google\Cloud Operations\Ops Agent\run\buffers\
Vérifiez que le disque de la VM n'est pas saturé.
Vérifiez que la configuration de journalisation est correcte.

Pour suivre cette procédure, vous devez vous connecter en SSH à la VM.

Si vous modifiez la configuration de journalisation, ou si les fichiers des tampons sont accessibles et que le disque de la VM n'est pas saturé, redémarrez l'Agent Ops :

Linux

Pour redémarrer l'agent, exécutez la commande suivante sur votre instance :
```
sudo systemctl restart google-cloud-ops-agent
```
Pour vérifier que l'agent a redémarré, exécutez la commande suivante et vérifiez que les composants "Agent de métriques" et "Agent de journalisation" ont démarré :
```
sudo systemctl status "google-cloud-ops-agent*"
```

Windows

Connectez-vous à votre instance via RDP ou un outil similaire, et connectez-vous à Windows.
Ouvrez un terminal PowerShell avec des droits d'administrateur en effectuant un clic droit sur l'icône PowerShell, puis en sélectionnant Exécuter en tant qu'administrateur.
Pour redémarrer l'agent, exécutez la commande PowerShell suivante :
```
Restart-Service google-cloud-ops-agent -Force
```
Pour vérifier que l'agent a redémarré, exécutez la commande suivante et vérifiez que les composants "Agent de métriques" et "Agent de journalisation" ont démarré :
```
Get-Service google-cloud-ops-agent*
```

Erreurs d'analyse des journaux

Si l'erreur d'exécution LogParseErr ("Agent Ops n'a pas pu analyser les journaux") s'affiche, le problème le plus probable concerne la configuration d'un processeur de journalisation. Pour résoudre ce problème, procédez comme suit :

Vérifiez que la configuration de tous les processeurs parse_json est correcte.
Vérifiez que la configuration de tous les processeurs parse_regex est correcte.
Si vous n'avez pas de processeurs parse_json ou parse_regex, vérifiez la configuration des autres processeurs de journalisation.

Pour suivre cette procédure, vous devez vous connecter en SSH à la VM.

Si vous modifiez la configuration de journalisation, redémarrez l'Agent Ops :

Linux

Pour redémarrer l'agent, exécutez la commande suivante sur votre instance :
```
sudo systemctl restart google-cloud-ops-agent
```
Pour vérifier que l'agent a redémarré, exécutez la commande suivante et vérifiez que les composants "Agent de métriques" et "Agent de journalisation" ont démarré :
```
sudo systemctl status "google-cloud-ops-agent*"
```

Windows

Connectez-vous à votre instance via RDP ou un outil similaire, et connectez-vous à Windows.
Ouvrez un terminal PowerShell avec des droits d'administrateur en effectuant un clic droit sur l'icône PowerShell, puis en sélectionnant Exécuter en tant qu'administrateur.
Pour redémarrer l'agent, exécutez la commande PowerShell suivante :
```
Restart-Service google-cloud-ops-agent -Force
```
Pour vérifier que l'agent a redémarré, exécutez la commande suivante et vérifiez que les composants "Agent de métriques" et "Agent de journalisation" ont démarré :
```
Get-Service google-cloud-ops-agent*
```

Vérifier les métriques locales

Pour suivre cette procédure, vous devez vous connecter en SSH à la VM.

Le module de journalisation est-il en cours d'exécution ? Exécutez les commandes suivantes pour vérifier :

Linux

sudo systemctl status google-cloud-ops-agent"*"

Windows

Ouvrez Windows PowerShell en tant qu'administrateur et exécutez la commande suivante :

Get-Service google-cloud-ops-agent

Vous pouvez également vérifier l'état du service dans l'application Services et inspecter les processus en cours d'exécution dans l'application Gestionnaire de tâches.

Consulter le journal du module de journalisation

Cette étape nécessite une connexion en SSH à la VM.

Les journaux du module de journalisation sont disponibles à l'emplacement /var/log/google-cloud-ops-agent/subagents/*.log pour Linux et à l'emplacement C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log pour Windows. Si aucun journal ne s'affiche, cela indique que le service de l'agent ne s'exécute pas correctement. Accédez à la section L'agent est installé mais ne s'exécute pas pour résoudre ce problème.

Il est possible que des erreurs d'autorisation 403 s'affichent lors de l'écriture dans l'API Logging. Exemple :

[2020/10/13 18:55:09] [ warn] [output:stackdriver:stackdriver.0] error
{
"error": {
  "code": 403,
  "message": "Cloud Logging API has not been used in project 147627806769 before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/logging.googleapis.com/overview?project=147627806769 then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.",
  "status": "PERMISSION_DENIED",
  "details": [
    {
      "@type": "type.googleapis.com/google.rpc.Help",
      "links": [
        {
          "description": "Google developers console API activation",
          "url": "https://console.developers.google.com/apis/api/logging.googleapis.com/overview?project=147627806769"
        }
      ]
    }
  ]
}
}

Pour corriger cette erreur, activez l'API Logging et définissez le rôle Rédacteur de journaux.

Il est possible que vous rencontriez un problème de quota pour l'API Logging. Exemple :

error="8:Insufficient tokens for quota 'logging.googleapis.com/write_requests' and limit 'WriteRequestsPerMinutePerProject' of service 'logging.googleapis.com' for consumer 'project_number:648320274015'." error_code="8"

Pour corriger cette erreur, augmentez le quota ou réduisez le débit du journal.

Il est possible que les messages d'erreur suivants s'affichent dans le journal du module :
```
{"error":"invalid_request","error_description":"Service account not enabled on this instance"}
```
ou
```
can't fetch token from the metadata server
```
Ces erreurs peuvent indiquer que vous avez déployé l'agent sans compte de service ou sans identifiants spécifiés. Pour en savoir plus sur la résolution de ce problème, consultez la page Autoriser l'agent Ops.

L'agent envoie-t-il des métriques à Cloud Monitoring ?

Consulter le journal du module des métriques

Cette étape nécessite une connexion en SSH à la VM.

Les journaux du module des métriques sont disponibles dans syslog. S'il n'existe pas de journaux, cela signifie que le service de l'agent ne fonctionne pas correctement. Accédez à la section L'agent est installé mais ne s'exécute pas pour résoudre ce problème.

Il est possible que des erreurs PermissionDenied s'affichent lors de l'écriture dans l'API Monitoring. Cette erreur se produit si l'autorisation pour l'agent Ops n'est pas correctement configurée. Exemple :

Nov  2 14:51:27 test-ops-agent-error otelopscol[412]: 2021-11-02T14:51:27.343Z#011info#011exporterhelper/queued_retry.go:231#011Exporting failed. Will retry the request after interval.#011{"kind": "exporter", "name": "googlecloud", "error": "[rpc error: code = PermissionDenied desc = Permission monitoring.timeSeries.create denied (or the resource may not exist).; rpc error: code = PermissionDenied desc = Permission monitoring.timeSeries.create denied (or the resource may not exist).]", "interval": "6.934781228s"}

Pour corriger cette erreur, activez l'API Monitoring et définissez le rôle Rédacteur de métriques Monitoring.

Il est possible que des erreurs ResourceExhausted s'affichent lors de l'écriture dans l'API Monitoring. Cette erreur se produit si le projet atteint la limite de quotas pour l'API Monitoring. Exemple :

Nov  2 18:48:32 test-ops-agent-error otelopscol[441]: 2021-11-02T18:48:32.175Z#011info#011exporterhelper/queued_retry.go:231#011Exporting failed. Will retry the request after interval.#011{"kind": "exporter", "name": "googlecloud", "error": "rpc error: code = ResourceExhausted desc = Quota exceeded for quota metric 'Total requests' and limit 'Total requests per minute per user' of service 'monitoring.googleapis.com' for consumer 'project_number:8563942476'.\nerror details: name = ErrorInfo reason = RATE_LIMIT_EXCEEDED domain = googleapis.com metadata = map[consumer:projects/8563942476 quota_limit:DefaultRequestsPerMinutePerUser quota_metric:monitoring.googleapis.com/default_requests service:monitoring.googleapis.com]", "interval": "2.641515416s"}

Pour corriger cette erreur, augmentez le quota ou réduisez le débit des métriques.

Il est possible que les messages d'erreur suivants s'affichent dans le journal du module :
```
{"error":"invalid_request","error_description":"Service account not enabled on this instance"}
```
ou
```
can't fetch token from the metadata server
```
Ces erreurs peuvent indiquer que vous avez déployé l'agent sans compte de service ou sans identifiants spécifiés. Pour en savoir plus sur la résolution de ce problème, consultez la page Autoriser l'agent Ops.

Problèmes de connectivité réseau

Si l'agent est en cours d'exécution, mais n'envoie ni journaux, ni métriques, il se peut qu'il y ait un problème de réseau. Les types de problèmes de connectivité réseau que vous pouvez rencontrer varient en fonction de la topologie de votre application. Pour en savoir plus sur la mise en réseau de Compute Engine, consultez la section Présentation de la mise en réseau pour les VM.

Voici les causes les plus courantes de problèmes de connectivité :

Des règles de pare-feu qui interfèrent avec le trafic entrant. Pour en savoir plus sur les règles de pare-feu, consultez la page Utiliser des règles de pare-feu VPC.
Problèmes de configuration d'un proxy HTTP.
Configuration DNS.

L'agent Ops exécute des vérifications d'état qui détectent les erreurs de connectivité réseau. Consultez la documentation sur les vérifications d'état pour connaître les actions suggérées en cas d'erreur de connectivité.

À partir de la version 2.28.0 de l'agent Ops, celui-ci limite la quantité d'espace disque qu'il peut utiliser pour stocker les fragments de mémoire tampon. L'agent Ops crée des fragments de mémoire tampon lorsque les données de journalisation ne peuvent pas être envoyées à l'API Cloud Logging. Sans limite, ces fragments peuvent consommer tout l'espace disponible, ce qui interrompt les autres services de la VM. Lorsqu'une panne réseau entraîne l'écriture des fragments de mémoire tampon sur le disque, l'agent Ops utilise une quantité d'espace disque spécifique à la plate-forme pour stocker les fragments. Un message semblable à l'exemple suivant s'affiche également dans /var/log/google-cloud-ops-agent/subagents/logging-module.log sur les VM Linux ou C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log sur les VM Windows lorsque la VM ne peut pas envoyer les fragments de tampon à l'API Cloud Logging :

[2023/04/15 08:21:17] [warn] [engine] failed to flush chunk

Je souhaite collecter seulement les métriques ou seulement les journaux, mais pas les deux

Par défaut, l'agent Ops collecte les métriques et les journaux. Pour désactiver la collecte de métriques ou de journaux, utilisez le fichier config.yaml de l'agent Ops afin de remplacer le service par défaut logging ou metrics afin que le pipeline par défaut ne comporte pas de récepteurs. Pour en savoir plus, consultez les ressources suivantes :

L'arrêt de l'ingestion de données en désactivant les services du sous-agent de l'agent Ops "Agent Logging" ou "Agent Monitoring" entraîne une configuration non valide et n'est pas compatible.

Des métriques sont collectées, mais il semble y avoir un problème

L'agent enregistre le message "Échec de l'exportation. Réessayer"

Les entrées de journal "Échec de l'exportation" s'affichent lorsque le premier point de données d'une métrique cumulative est supprimé. Les journaux suivants ne sont pas dangereux et peuvent être ignorés en toute sécurité :

  Jul 13 17:28:03 debian9-trouble otelopscol[2134]: 2021-07-13T17:28:03.092Z        info        exporterhelper/queued_retry.go:316        Exporting failed. Will retry the request a
  fter interval.        {"kind": "exporter", "name": "googlecloud/agent", "error": "rpc error: code = InvalidArgument desc = Field timeSeries[1].points[0].interval.start_time had a
  n invalid value of "2021-07-13T10:25:18.061-07:00": The start time must be before the end time (2021-07-13T10:25:18.061-07:00) for the non-gauge metric 'agent.googleapis.com/ag
  ent/uptime'.", "interval": "23.491024535s"}
  Jul 13 17:28:41 debian9-trouble otelopscol[2134]: 2021-07-13T17:28:41.269Z        info        exporterhelper/queued_retry.go:316        Exporting failed. Will retry the request a
  fter interval.        {"kind": "exporter", "name": "googlecloud/agent", "error": "rpc error: code = InvalidArgument desc = Field timeSeries[0].points[0].interval.start_time had a
  n invalid value of "2021-07-13T10:26:18.061-07:00": The start time must be before the end time (2021-07-13T10:26:18.061-07:00) for the non-gauge metric 'agent.googleapis.com/ag
  ent/monitoring/point_count'.", "interval": "21.556591578s"}

L'agent affiche des messages "Les séries temporelles n'ont pas pu être écrites : les points doivent être écrits dans l'ordre.".

Si vous êtes passé de l'ancien agent Monitoring à l'Agent Ops et que le message d'erreur suivant s'affiche lors de l'écriture de métriques cumulatives, la solution consiste à redémarrer votre VM. L'Agent Ops et l'agent Monitoring calculent les heures de début des métriques cumulatives différemment, ce qui peut entraîner l'apparition de points dans le désordre. Redémarrer la VM réinitialise l'heure de début et résout ce problème.

  Jun 2 14:00:06 * otelopscol[4035]: 2023-06-02T14:00:06.304Z#011error#011exporterhelper/queued_retry.go:367#011Exporting failed.
  Try enabling retry_on_failure config option to retry on retryable errors#011{"error": "failed to export time series to GCM: rpc error: code = InvalidArgument desc =
  One or more TimeSeries could not be written: Points must be written in order. One or more of the points specified had an older start time than the most recent point.:
  gce_instance{instance_id:,zone:} timeSeries[0-199]: agent.googleapis.com/memory/bytes_used{state:slab}

L'agent enregistre des messages "Le jeton doit être un jeton de courte durée (60 minutes) et dans un délai raisonnable"

Si le message d'erreur suivant s'affiche lorsque l'agent écrit des métriques, cela signifie que l'horloge système n'est pas synchronisée correctement :

  Invalid JWT: Token must be a short-lived token (60 minutes) and in a
  reasonable timeframe. Check your iat and exp values in the JWT claim.

Pour en savoir plus sur la synchronisation des horloges système, consultez Configurer NTP sur une VM.

L'agent enregistre le message "le récepteur de métriques avec le type "nvml" n'est pas compatible".

Si vous collectez des métriques GPU de la bibliothèque de gestion NVIDIA (agent.googleapis.com/gpu) à l'aide du récepteur nvml, vous utilisez une version de l'Agent Ops compatible avec les aperçus des métriques NVML. La compatibilité de ces métriques est désormais disponible pour tous les utilisateurs dans la version 2.38.0 de l'Agent Ops. Dans la version en disponibilité générale, la collecte de métriques effectuée par le récepteur nvml a été fusionnée avec le récepteur hostmetrics, et le récepteur nvml a été supprimé.

Vous voyez s'afficher le message d'erreur "récepteur de métriques avec le type "nvml" n'est pas pris en charge" après l'installation de la version 2.38.0 ou ultérieure de l'Agent Ops lorsque vous utilisez l'aperçu du récepteur nvml et que vous remplacez par défaut l'intervalle de collecte dans le fichier de configuration spécifié par l'utilisateur. L'erreur se produit car le récepteur nvml n'existe plus, alors que votre paramètre spécifié par l'utilisateur de configuration s'y réfère toujours.

Pour résoudre ce problème, mettez à jour votre fichier de configuration spécifié par l'utilisateur afin de remplacer l'intervalle de collecte sur le récepteur hostmetrics.

Les métriques du GPU sont manquantes

Si l'agent Ops collecte certaines métriques, mais qu'une partie ou la totalité des métriques GPU de la bibliothèque de gestion NVIDIA (NVML) (agent.googleapis.com/gpu) sont manquantes, vous avez peut-être un problème de configuration ou aucun processus utilisant le GPU.

Si vous ne collectez aucune métrique GPU, vérifiez le pilote du GPU. Pour collecter des métriques GPU, l'agent Ops nécessite que le pilote du GPU soit installé et configuré sur la VM. Pour vérifier le pilote, procédez comme suit :

Pour vérifier que le pilote est installé et fonctionne correctement, suivez les étapes pour vérifier l'installation du pilote du GPU.

Si le pilote n'est pas installé, procédez comme suit :

Installez le pilote du GPU.
Redémarrez l'Agent Ops.

Vous devez redémarrer l'agent Ops après avoir installé ou mis à niveau le pilote du GPU.

Consultez les journaux de l'agent Ops pour vérifier que la communication a bien été lancée. Les messages de journal se présentent comme suit :

Jul 11 18:28:12 multi-gpu-debian11-2 otelopscol[906670]: 2024-07-11T18:28:12.771Z        info        nvmlreceiver/client.go:128        Successfully initialized Nvidia Management Library
Jul 11 18:28:12 multi-gpu-debian11-2 otelopscol[906670]: 2024-07-11T18:28:12.772Z        info        nvmlreceiver/client.go:151        Nvidia Management library version is 12.555.42.06
Jul 11 18:28:12 multi-gpu-debian11-2 otelopscol[906670]: 2024-07-11T18:28:12.772Z        info        nvmlreceiver/client.go:157        NVIDIA driver version is 555.42.06
Jul 11 18:28:12 multi-gpu-debian11-2 otelopscol[906670]: 2024-07-11T18:28:12.781Z        info        nvmlreceiver/client.go:192        Discovered Nvidia device 0 of model NVIDIA L4 with UUID GPU-fc5a05a7-8859-ec33-c940-3cf0930c0e61.

Si le pilote du GPU est installé et que les journaux de l'agent Ops indiquent que l'agent Ops communique avec le pilote, mais que vous ne voyez aucune métrique GPU, le problème peut venir de la carte graphique que que vous utilisez. Pour en savoir plus sur le dépannage des graphiques, consultez la section Le graphique n'affiche aucune donnée.

Si vous collectez certaines métriques GPU, mais qu'il manque les métriques processes (processes/max_bytes_used et processes/utilization), aucun processus n'est exécuté sur les GPU. Les métriques processes du GPU ne sont pas collectées si aucun processus n'est en cours d'exécution sur le GPU.

Certaines métriques sont manquantes ou incohérentes

Un petit nombre de métriques sont gérées par l'agent Ops version 2.0.0 et ultérieure de manière différente des versions "bêta" de l'agent Ops (versions antérieures à la version 2.0.0) ou de l'agent Monitoring.

Le tableau suivant décrit les différences entre les données ingérées par l'agent Ops et par l'agent Monitoring.

Type de métrique, omission `agent.googleapis.com`	Agent Ops (disponibilité générale)^†	Agent Ops (preview)^†	Agent Monitoring
`cpu_state`	Les valeurs possibles pour Windows sont les suivantes : `idle`, `interrupt,` `system` et `user`.	Les valeurs possibles pour Windows sont les suivantes : `idle`, `interrupt,` `system` et `user`.	Les valeurs possibles pour Windows sont `idle` et `used`.
`disk/bytes_used` et `disk/percent_used`	Ingestion avec le chemin complet dans le libellé `device`. Par exemple, `/dev/sda15`. Pas d'ingestion pour les appareils virtuels tels que `tmpfs` et `udev`.	Ingestion sans `/dev` dans le chemin d'accès dans le libellé `device`. Par exemple, `sda15`. Ingestion pour les appareils virtuels tels que `tmpfs` et `udev`.	Ingestion sans `/dev` dans le chemin d'accès dans le libellé `device`. Par exemple, `sda15`. Ingestion pour les appareils virtuels tels que `tmpfs` et `udev`.

^† La colonne DG fait référence à l'agent Ops version 2.0.0 ou ultérieure. La colonne bêta fait référence à des versions de l'agent Ops antérieures à la version 2.0.0.

Problèmes spécifiques à Windows

Les sections suivantes ne s'appliquent qu'à l'agent Ops exécuté sous Windows.

Compteurs de performances corrompus sous Windows

Si le sous-agent de métriques ne démarre pas, l'une des erreurs suivantes peut s'afficher dans Cloud Logging :

Failed to retrieve perf counter object "LogicalDisk"
Failed to retrieve perf counter object "Memory"
Failed to retrieve perf counter object "System"

Ces erreurs peuvent se produire si les compteurs de performances de votre système sont corrompus. Vous pouvez résoudre les erreurs en recréant les compteurs de performances. Dans PowerShell, en tant qu'administrateur, exécutez la commande suivante :

cd C:\Windows\system32
lodctr /R

La commande précédente peut parfois échouer. Dans ce cas, actualisez PowerShell et réessayez jusqu'à ce qu'elle aboutisse.

Une fois la commande exécutée, redémarrez l'agent Ops :

Restart-Service -Name google-cloud-ops-agent -Force

Réinitialiser complètement l'état de l'agent

Si l'agent passe à un état non récupérable, procédez comme suit pour le restaurer à un nouvel état.

Linux

Arrêtez le service de l'agent à l'aide de la commande suivante :

sudo service google-cloud-ops-agent stop

Supprimez le package d'agent :

curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh
sudo bash add-google-cloud-ops-agent-repo.sh --uninstall --remove-repo

Supprimez les journaux automatiques de l'agent sur le disque :

sudo rm -rf /var/log/google-cloud-ops-agent

Supprimez les tampons locaux de l'agent sur le disque :

sudo rm -rf /var/lib/google-cloud-ops-agent/fluent-bit/buffers/*/

Remarque : Le répertoire /var/lib/google-cloud-ops-agent/fluent-bit/buffers/ contient les types de fichiers suivants :

Fichiers tampons : ces fichiers sont des entrées de journal mises en mémoire tampon qui ont été suivies et traitées par l'agent Ops, mais n'ont pas encore été ingérées dans Cloud Logging. En cas de fragments corrompus, l'agent Ops doit les ignorer dans les versions 2.15.0 et ultérieures. Dans certains cas, ils doivent toutefois être nettoyés manuellement. Ces fichiers sont stockés dans les dossiers imbriqués de la manière suivante : /var/lib/google-cloud-ops-agent/fluent-bit/buffers/tail.1/*
Fichiers de position de suivi de fichier journal : ces fichiers enregistrent l'emplacement dans les fichiers journaux que l'agent Ops a déjà suivi. Si ces fichiers sont supprimés, l'agent Ops démarre en haut des fichiers qu'il est configuré de suivre. La suppression de ces fichiers peut entraîner une duplication des journaux si ceux-ci ont déjà été ingérés avec succès. Ces fichiers sont stockés directement dans le répertoire sous la forme de fichiers tels que /var/lib/google-cloud-ops-agent/fluent-bit/buffers/default_pipeline_syslog*.

La syntaxe .../buffers/*/ de la commande précédente garantit que seuls les fichiers tampons sont supprimés. Les fichiers de position ne sont pas supprimés.

Réinstallez et redémarrez l'agent :

curl -sSO https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.sh
sudo bash add-google-cloud-ops-agent-repo.sh --also-install
sudo service google-cloud-ops-agent restart

Windows

Arrêtez le service de l'agent à l'aide de la commande suivante :

Stop-Service google-cloud-ops-agent -Force;
Get-Service google-cloud-ops-agent* | %{sc.exe delete $_};
taskkill /f /fi "SERVICES eq google-cloud-ops-agent*";

Supprimez le package d'agent :

(New-Object Net.WebClient).DownloadFile("https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.ps1", "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1");
$env:REPO_SUFFIX="";
Invoke-Expression "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1 -Uninstall -RemoveRepo"

Supprimez les journaux automatiques de l'agent sur le disque :

rmdir -R -ErrorAction SilentlyContinue "C:\ProgramData\Google\Cloud Operations\Ops Agent\log";

Supprimez les tampons locaux de l'agent sur le disque :

Get-ChildItem -Path "C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers\" -Directory -ErrorAction SilentlyContinue | %{rm -r -Path $_.FullName}

Réinstallez et redémarrez l'agent :

(New-Object Net.WebClient).DownloadFile("https://dl.google.com/cloudagents/add-google-cloud-ops-agent-repo.ps1", "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1");
$env:REPO_SUFFIX="";
Invoke-Expression "${env:UserProfile}\add-google-cloud-ops-agent-repo.ps1 -AlsoInstall"

Réinitialiser mais enregistrer les fichiers tampons

Si la VM ne comporte pas de fragments de mémoire tampon corrompus (c'est-à-dire, qu'il n'y a pas de messages format check failed dans le fichier journal automatique de l'agent Ops), vous pouvez ignorer les commandes précédentes qui suppriment les tampons locaux lors de la réinitialisation de l'état de l'agent.

Si la VM comporte des fragments de mémoire tampon corrompus, vous devez les supprimer. Les options suivantes décrivent différentes manières de gérer les tampons. Les autres étapes décrites dans la section Réinitialiser complètement l'état de l'agent restent applicables.

Option 1 : supprimez l'intégralité du répertoire buffers. Il s'agit de la solution la plus simple, mais elle peut entraîner une perte des journaux mis en mémoire tampon non corrompus ou des doublons de journaux en raison de la perte des fichiers de position.

Linux
```
sudo rm -rf /var/lib/google-cloud-ops-agent/fluent-bit/buffers
```
Windows
```
rmdir -R -ErrorAction SilentlyContinue "C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers";
```
Option 2 : supprimez les sous-répertoires de tampon du répertoire buffers, mais laissez les fichiers de position. Cette approche est décrite dans la section Réinitialiser complètement l'état de l'agent.

Option 3 : si vous ne souhaitez pas supprimer tous les fichiers tampons, vous pouvez extraire les noms des fichiers tampons corrompus des journaux automatiques de l'agent et ne supprimer que les fichiers de tampon corrompus.

Linux

grep "format check failed" /var/log/google-cloud-ops-agent/subagents/logging-module.log | sed 's|.*format check failed: |/var/lib/google-cloud-ops-agent/fluent-bit/buffers/|' | xargs sudo rm -f

Windows

$oalogspath="C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log";
if (Test-Path $oalogspath) {
  Select-String "format check failed" $oalogspath |
  %{$_ -replace '.*format check failed: (.*)/(.*)', '$1\$2'} |
  %{rm -ErrorAction SilentlyContinue -Path ('C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers\' + $_)}
};

Option 4 : s'il existe de nombreux tampons corrompus et que vous souhaitez relancer le traitement de tous les fichiers journaux, vous pouvez utiliser les commandes de l'option 3 et supprimer aussi les fichiers de position (qui stockent les opérations de progression de l'agent Ops par fichier journal). La suppression des fichiers de position peut entraîner la duplication des journaux qui ont déjà été ingérés. Cette option ne traite à nouveau que les fichiers de journal actuels. Elle ne retraite pas les fichiers qui ont déjà été alternés ou les journaux d'autres sources telles qu'un port TCP. Les fichiers de position sont stockés dans le répertoire buffers, mais sont stockés sous forme de fichiers. Les tampons locaux sont stockés en tant que sous-répertoires dans le répertoire buffers.

Linux

grep "format check failed" /var/log/google-cloud-ops-agent/subagents/logging-module.log | sed 's|.*format check failed: |/var/lib/google-cloud-ops-agent/fluent-bit/buffers/|' | xargs sudo rm -f
sudo find /var/lib/google-cloud-ops-agent/fluent-bit/buffers -maxdepth 1 -type f -delete

Windows

$oalogspath="C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log";
if (Test-Path $oalogspath) {
  Select-String "format check failed" $oalogspath |
  %{$_ -replace '.*format check failed: (.*)/(.*)', '$1\$2'} |
  %{rm -ErrorAction SilentlyContinue -Path ('C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers\' + $_)}
};
Get-ChildItem -Path "C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers\" -File -ErrorAction SilentlyContinue | %{$_.Delete()}

Problèmes connus dans les versions récentes de l'agent Ops

Les sections suivantes décrivent les problèmes connus dans les versions récentes de l'agent Ops.

Boucle de plantage pour les versions 2.47.0, 2.48.0 ou 2.49.0 de l'agent Ops

Les versions 2.47.0, 2.48.0 et 2.49.0 incluaient un composant FluentBit défectueux pour la journalisation. Ce composant échoue sur des lignes de journal spécifiques et provoque l'agent Ops afin qu'il effectue une boucle de plantage.

Ce problème est résolu dans la version 2.50.0 de l'agent Ops.

L'espace de noms des métriques Prometheus inclut le nom de l'instance en plus de l'ID d'instance à partir de la version 2.46.0 de l'agent Ops.

À partir de la version 2.46.0, l'Agent Ops inclut le nom de la VM dans le libellé namespace lors de l'ingestion de métriques au format d'ingestion Prometheus. Dans les versions précédentes, les métriques Prometheus n'utilisaient que l'ID d'instance de la VM dans le cadre du libellé namespace, mais à partir de la version 2.46.0, namespace est défini sur INSTANCE_ID/INSTANCE_NAME.

Si vous avez des graphiques, des tableaux de bord ou des règles d'alerte qui utilisent le libellé namespace, vous devrez peut-être mettre à jour vos requêtes après la mise à niveau de votre agent Ops vers la version 2.46.0 ou ultérieure. Par exemple, si votre requête PromQL se présente comme suit : http_requests_total{namespace="123456789"}, vous devez la remplacer par http_requests_total{namespace=~"123456789.*"}, car le libellé namespace est au format INSTANCE_ID/INSTANCE_NAME.

Les métriques non typées Prometheus changent de type de métrique à partir de la version 2.39.0 de l'Agent Ops

À partir de la version 2.39.0, l'Agent Ops accepte l'ingestion de métriques Prometheus dont le type est inconnu. Dans les versions antérieures, ces métriques sont traitées par l'Agent Ops comme des jauges, mais à partir de la version 2.39.0, les métriques non typées sont traitées à la fois comme des jauges et des compteurs. Par conséquent, les utilisateurs peuvent désormais utiliser des opérations cumulatives sur ces métriques.

Si vous avez des graphiques, des tableaux de bord ou des règles d'alerte qui utilisent MQL pour interroger des métriques Prometheus non typées, vous devez mettre à jour vos requêtes MQL après avoir mis à niveau votre Agent Ops vers la version 2.39.0 ou une version ultérieure. Au lieu d'interroger les métriques non typées en tant que prometheus.googleapis.com/METRIC_NAME/gauge, modifiez les types de métriques comme suit :

Utilisez prometheus.googleapis.com/METRIC_NAME/unknown pour la version "jauge" de la métrique.
Utilisez prometheus.googleapis.com/METRIC_NAME/unknown:counter pour la version "compteur" de la métrique.

Vous n'avez pas besoin de modifier les graphiques, les tableaux de bord ou les règles d'alerte qui utilisent PromQL pour interroger des métriques Prometheus non typées, mais vous pouvez appliquer des opérations cumulatives à ces métriques après avoir mis à niveau votre Agent Ops vers la version 2.39.0 ou ultérieure.

Utilisation élevée de la mémoire sur les VM Windows (versions 2.27.0 à 2.29.0)

Sous Windows, dans les versions 2.27.0 à 2.29.0 de l'agent Ops, un bug qui amenait parfois l'agent à divulguer des sockets entraînait une utilisation accrue de la mémoire et la conservation d'un grand nombre de handles par le processus fluent-bit.exe.

Pour résoudre ce problème, mettez à jour l'agent Ops vers la version 2.30.0 ou une version ultérieure, puis redémarrez-le.

Les fuseaux horaires des journaux des événements sont incorrects sous Windows (versions 2.15.0 à 2.26.0)

Les codes temporels associés aux journaux des événements Windows dans Cloud Logging peuvent être incorrects si vous choisissez un fuseau horaire autre que UTC pour votre VM. Ce problème a été résolu dans l'agent Ops 2.27.0, mais en raison du problème connu d'utilisation élevée de la mémoire sous Windows, nous vous recommandons de mettre à niveau l'agent Ops vers la version 2.30.0 ou ultérieure si vous rencontrez ce problème. Si vous ne pouvez pas effectuer de mise à niveau, vous pouvez essayer l'une des solutions suivantes.

Utiliser un fuseau horaire UTC

Dans PowerShell, exécutez les commandes suivantes en tant qu'administrateur :

Set-TimeZone -Id "UTC"
Restart-Service -Name "google-cloud-ops-agent-fluent-bit" -Force

Ignorer le paramètre de fuseau horaire, seulement pour le service de sous-agent de journalisation

Dans PowerShell, exécutez les commandes suivantes en tant qu'administrateur :

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\google-cloud-ops-agent-fluent-bit" -Name "Environment" -Type "MultiString" -Value "TZ=UTC0"
Restart-Service -Name "google-cloud-ops-agent-fluent-bit" -Force

Le fuseau horaire des codes temporels analysés sous Windows est incorrect (versions antérieures à 2.27.0)

Si vous utilisez un processeur de journaux qui analyse un code temporel, la valeur du fuseau horaire ne sera pas analysée correctement sous Windows. Ce problème a été résolu dans l'agent Ops 2.27.0, mais en raison du problème connu d'utilisation élevée de la mémoire sous Windows, nous vous recommandons de mettre à niveau l'agent Ops vers la version 2.30.0 ou ultérieure si vous rencontrez ce problème.

Problèmes connus dans les anciennes versions de l'agent Ops

Les sections suivantes décrivent les problèmes connus pour les anciennes versions de l'agent Ops.

Journaux non nuisibles (versions 2.9.1 et antérieures)

Des erreurs peuvent se produire lors de l'extraction de métriques de pseudo-processus ou de processus restreints. Les journaux suivants ne sont pas dangereux et peuvent être ignorés en toute sécurité. Pour éliminer ces messages, mettez à niveau l'agent Ops vers la version 2.10.0 ou ultérieure.

    Jul 13 17:28:55 debian9-trouble otelopscol[2134]: 2021-07-13T17:28:55.848Z        error        scraperhelper/scrapercontroller.go:205        Error scraping metrics        {"kind"
  : "receiver", "name": "hostmetrics/hostmetrics", "error": "[error reading process name for pid 2: readlink /proc/2/exe: no such file or directory; error reading process name for
  pid 3: readlink /proc/3/exe: no such file or directory; error reading process name for pid 4: readlink /proc/4/exe: no such file or directory; error reading process name for pid
  5: readlink /proc/5/exe: no such file or directory; error reading process name for pid 6: readlink /proc/6/exe: no such file or directory; error reading process name for pid 7: r
  eadlink /proc/7/exe: no such file or directory; error reading process name for pid 8: readlink /proc/8/exe: no such file or directory; error reading process name for pid 9: readl
  ink /proc/9/exe: no such file or directory; error reading process name for pid 10: readlink /proc/10/exe: no such file or directory; error reading process name for pid 11: readli
  nk /proc/11/exe: no such file or directory; error reading process name for pid 12: readlink /proc/12/exe: no such file or directory; error reading process name for pid 13: readli
  nk /proc/13/exe: no such file or directory; error reading process name for pid 14: readlink /proc/14/exe: no such file or directory; error reading process name for pid 15: readli
  nk /proc/15/exe: no such file or directory; error reading process name for pid 16: readlink /proc/16/exe: no such file or directory; error reading process name for pid 17: readli
  nk /proc/17/exe: no such file or directory; error reading process name for pid 18: readlink /proc/18/exe: no such file or directory; error reading process name for pid 19: readli
  nk /proc/19/exe: no such file or directory; error reading process name for pid 20: readlink /proc/20/exe: no such file or directory; error reading process name for pid 21: readli
  nk /proc/21/exe: no such file or directory; error reading process name for pid 22: readlink /proc/22/exe: no such file or directory; error reading process name for pid
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]: 23: readlink /proc/23/exe: no such file or directory; error reading process name for pid 24: readlink /proc/24/exe: no such file
   or directory; error reading process name for pid 25: readlink /proc/25/exe: no such file or directory; error reading process name for pid 26: readlink /proc/26/exe: no such file
   or directory; error reading process name for pid 27: readlink /proc/27/exe: no such file or directory; error reading process name for pid 28: readlink /proc/28/exe: no such file
   or directory; error reading process name for pid 30: readlink /proc/30/exe: no such file or directory; error reading process name for pid 31: readlink /proc/31/exe: no such file
   or directory; error reading process name for pid 43: readlink /proc/43/exe: no such file or directory; error reading process name for pid 44: readlink /proc/44/exe: no such file
   or directory; error reading process name for pid 45: readlink /proc/45/exe: no such file or directory; error reading process name for pid 90: readlink /proc/90/exe: no such file
   or directory; error reading process name for pid 92: readlink /proc/92/exe: no such file or directory; error reading process name for pid 106: readlink /proc/106/exe: no such fi
  le or directory; error reading process name for pid 360: readlink /proc/360/exe: no such file or directory; error reading process name for pid 375: readlink /proc/375/exe: no suc
  h file or directory; error reading process name for pid 384: readlink /proc/384/exe: no such file or directory; error reading process name for pid 386: readlink /proc/386/exe: no
   such file or directory; error reading process name for pid 387: readlink /proc/387/exe: no such file or directory; error reading process name for pid 422: readlink /proc/422/exe
  : no such file or directory; error reading process name for pid 491: readlink /proc/491/exe: no such file or directory; error reading process name for pid 500: readlink /proc/500
  /exe: no such file or directory; error reading process name for pid 2121: readlink /proc/2121/exe: no such file or directory; error reading
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]: process name for pid 2127: readlink /proc/2127/exe: no such file or directory]"}
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]: go.opentelemetry.io/collector/receiver/scraperhelper.(controller).scrapeMetricsAndReport
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]:         /root/go/pkg/mod/go.opentelemetry.io/collector@v0.29.0/receiver/scraperhelper/scrapercontroller.go:205
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]: go.opentelemetry.io/collector/receiver/scraperhelper.(controller).startScraping.func1
  Jul 13 17:28:55 debian9-trouble otelopscol[2134]:         /root/go/pkg/mod/go.opentelemetry.io/collector@v0.29.0/receiver/scraperhelper/scrapercontroller.go:186

Les journaux automatiques des agents consomment trop de processeurs, de mémoire et d'espace disque (versions 2.16.0 et antérieures).

Les versions de l'agent Ops antérieures à la version 2.17.0 peuvent consommer beaucoup de ressources de processeur, de mémoire et d'espace disque avec des fichiers /var/log/google-cloud-ops-agent/subagents/logging-module.log sur des VM Linux ou des fichiers C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log sur des VM Windows en raison de fragments de mémoire tampon corrompus. Dans ce cas, un grand nombre de messages semblables à ceux-ci s'affichent dans le fichier logging-module.log.

  [2022/04/30 05:23:38] [error] [input chunk] error writing data from tail.2 instance
  [2022/04/30 05:23:38] [error] [storage] format check failed: tail.2/2004860-1650614856.691268293.flb
  [2022/04/30 05:23:38] [error] [storage] format check failed: tail.2/2004860-1650614856.691268293.flb
  [2022/04/30 05:23:38] [error] [storage] [cio file] file is not mmap()ed: tail.2:2004860-1650614856.691268293.flb

Pour résoudre ce problème, mettez à niveau l'agent Ops vers la version 2.17.0 ou ultérieure, puis réinitialisez complètement l'état de l'agent.

Si votre système génère toujours un volume important de journaux automatiques d'agent, envisagez d'utiliser la rotation des journaux. Pour en savoir plus, consultez la section Configurer la rotation des journaux.