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 dans les journaux et les métriques de 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.

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 le panneau de navigation de la console Google Cloud, sélectionnez Monitoring, puis Explorateur de métriques :
Accédez à l'explorateur de métriques
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*
```

Analyser les erreurs

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 l'ensemble des processeurs parse_json est correcte.
Vérifiez que la configuration de l'ensemble des processeurs parse_regex est correcte.
Si vous ne disposez 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. S'il n'existe pas de journaux, 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 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. Exemples :

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 les journaux, ni les métriques, il se peut que vous rencontriez un problème de réseau. Les types de problèmes de connectivité réseau que vous pouvez rencontrer varient avec la topologie de votre application. Pour en savoir plus sur la mise en réseau Compute Engine, consultez la page 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 perturbent 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 de l'état qui détectent les erreurs de connectivité réseau. Pour obtenir des suggestions d'actions à effectuer en cas d'erreurs de connectivité, consultez la documentation sur les vérifications d'état.

À 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 pour remplacer le service logging ou metrics par défaut afin que le pipeline par défaut ne dispose 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.

Les métriques sont collectées, mais quelque chose semble incorrect

L'agent enregistre l'erreur "É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. Le redémarrage de la VM réinitialise l'heure de début et résout le 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 la section 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 dans 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, mais le fichier de configuration spécifié par l'utilisateur y fait toujours référence.

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

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 (version bêta)^†	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 ces erreurs en recompilant 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.

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 avec les versions plus anciennes de l'agent Ops.

Journaux non nuisibles (versions 2.9.1 et antérieures)

Des erreurs peuvent survenir lorsque vous récupérez des 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 grand volume de journaux automatiques d'agents, envisagez d'utiliser la rotation de journaux. Pour en savoir plus, consultez la page Configurer la rotation des journaux.