Ops エージェントのデータ取り込みのトラブルシューティング

このドキュメントでは、実行中の Ops エージェントのログと指標のデータ取り込みに関する問題を診断して解決する際に役立つ情報を提供します。Ops エージェントが実行されていない場合は、インストールと起動のトラブルシューティングをご覧ください。

始める前に

問題を解決する前に、エージェントのヘルスチェックのステータスを確認してください。

Google Cloud コンソールに、Ops エージェントのインストールが「保留中」と表示され進行しない

Ops エージェントのインストールが成功しても、Google Cloud コンソールに「保留中」ステータスが引き続き表示される場合があります。gcpdiag を使用して、Ops エージェントのインストールを確認します。また、エージェントが VM インスタンスからログと指標を送信していることを確認します。

インストールが失敗する一般的な理由

次の理由で Ops エージェントのインストールが失敗する場合があります。

• VM にサービス アカウントが接続されていません。VM にサービス アカウントを接続し、Ops エージェントを再インストールします。

• VM に以前のエージェントのいずれかがすでにインストールされているため、Ops エージェントをインストールできません。以前のエージェントをアンインストールしてから、Ops エージェントを再インストールします。

テレメトリー送信が失敗する一般的な理由

インストールして実行中の Ops エージェントは、次の理由で VM からログ、指標、またはそれらの両方を送信できない場合があります。

• VM に接続されているサービス アカウントに roles/logging.logWriter または roles/monitoring.metricWriter ロールが付与されていません。
• ロギングまたはモニタリングのアクセス スコープが有効になっていません。アクセス スコープの確認と更新については、アクセス スコープを確認するをご覧ください。
• Logging API または Monitoring API が有効になっていません。

エージェントのヘルスチェックを使用して、根本原因と対応する解決策を特定します。

エージェントは実行されているが、データが取得されない

Metrics Explorer を使用してエージェントの uptime 指標をクエリし、エージェント コンポーネント google-cloud-ops-agent-metrics または google-cloud-ops-agent-logging がこの指標に書き込んでいるかどうか確認します。

1. Google Cloud コンソールで、[Metrics Explorer] ページに移動します。

   Metrics Explorer に移動

   検索バーを使用してこのページを検索する場合は、小見出しが [Monitoring] の結果を選択します。

2. ビルダーコードの切り替えボタンで [コード] を選択し、言語を [MQL] に設定します。

3. 次のクエリを入力し、[実行] をクリックします。

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

エージェントが Cloud Logging にログを送信しているか

エージェントが実行されていてもログを送信していない場合は、エージェントのランタイム ヘルスチェックのステータスを確認します。

パイプライン エラー

ランタイム エラー LogPipelineErr（Ops Agent logging pipeline failed）が表示される場合、Logging サブエージェントのログの書き込みで問題が発生しています。次の条件を確認してください。

• Logging サブエージェントのストレージ ファイルにアクセスできることを確認します。これらのファイルは以下の場所にあります。
  • Linux: /var/lib/google-cloud-ops-agent/fluent-bit/buffers/
  • Windows: C:\Program Files\Google\Cloud Operations\Ops Agent\run\buffers\
• VM のディスクに空き容量があることを確認します。
• ロギング構成が正しいことを確認します。

以下の手順を行うには、VM に SSH 接続する必要があります。

ロギング構成を変更する場合、またはバッファ ファイルにアクセスできて VM のディスクに空き容量がある場合は、Ops エージェントを再起動します。

Linux

1. エージェントを再起動するには、インスタンスで次のコマンドを実行します。

   sudo systemctl restart google-cloud-ops-agent
   

2. エージェントが再起動したことを確認するには、次のコマンドを実行して「Metrics Agent」と「Logging エージェント」のコンポーネントが起動したことを確認します。

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

Windows

1. RDP または同様のツールを使用してインスタンスに接続し、Windows にログインします。
2. PowerShell アイコンを右クリックし、[管理者として実行] を選択して、管理者権限で PowerShell ターミナルを開きます。
3. エージェントを再起動するには、次の PowerShell コマンドを実行します。

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

4. エージェントが再起動したことを確認するには、次のコマンドを実行して「Metrics Agent」と「Logging エージェント」のコンポーネントが起動したことを確認します。

   Get-Service google-cloud-ops-agent*
   

ログ解析エラー

ランタイム エラー「LogParseErr」（Ops エージェントがログを解析できない）が表示される場合、最も考えられる問題はロギング プロセッサの構成です。この問題を解決するには、次の操作を行います。

• parse_json プロセッサの構成が正しいことを確認します。
• parse_regex プロセッサの構成が正しいことを確認します。
• parse_json プロセッサまたは parse_regex プロセッサがない場合は、他のロギング プロセッサの構成を確認します。

以下の手順を行うには、VM に SSH 接続する必要があります。

ロギング構成を変更した場合は、Ops エージェントを再起動します。

Linux

1. エージェントを再起動するには、インスタンスで次のコマンドを実行します。

   sudo systemctl restart google-cloud-ops-agent
   

2. エージェントが再起動したことを確認するには、次のコマンドを実行して「Metrics Agent」と「Logging エージェント」のコンポーネントが起動したことを確認します。

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

Windows

1. RDP または同様のツールを使用してインスタンスに接続し、Windows にログインします。
2. PowerShell アイコンを右クリックし、[管理者として実行] を選択して、管理者権限で PowerShell ターミナルを開きます。
3. エージェントを再起動するには、次の PowerShell コマンドを実行します。

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

4. エージェントが再起動したことを確認するには、次のコマンドを実行して「Metrics Agent」と「Logging エージェント」のコンポーネントが起動したことを確認します。

   Get-Service google-cloud-ops-agent*
   

ローカル指標を確認する

注: ローカル指標サービスは、Windows では利用できません。

以下の手順を行うには、VM に SSH 接続する必要があります。

• ロギング モジュールが稼働しているかどうか。次のコマンドを使用して確認します。

Linux

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

Windows

管理者として Windows PowerShell を開き、次のコマンドを実行します。

Get-Service google-cloud-ops-agent

また、サービスアプリでサービスのステータスを確認したり、タスク マネージャー アプリで実行中のプロセスを調べることもできます。

ロギング モジュールのログを確認する

このステップを行うには、VM に SSH 接続する必要があります。

Linux の場合、ロギング モジュールのログは /var/log/google-cloud-ops-agent/subagents/*.log にあります。Windows の場合は C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log にあります。ログがない場合、エージェント サービスが正しく実行されていません。この状態を修正するには、まず、エージェントはインストールされているが、実行されていないに移動します。

• Logging API への書き込み時に、403 権限エラーが発生することがあります。次に例を示します。

  [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"
          }
        ]
      }
    ]
  }
  }
  

  このエラーを修正するには、Logging API を有効にし、ログ書き込みロールを設定します。

• Logging API の割り当てに関する問題が発生している可能性があります。例:

  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"
  

  このエラーを解決するには、割り当てを増やすか、ログ スループットを減らします。

• モジュールログに次のエラーが記録されていることがあります。

  {"error":"invalid_request","error_description":"Service account not enabled on this instance"}
  

  または

  can't fetch token from the metadata server
  

  これらのエラーが発生している場合、サービス アカウントまたは指定された認証情報なしでエージェントがデプロイされた可能性があります。この問題を解決する方法については、Ops エージェントを認可するをご覧ください。

エージェントが Cloud Monitoring に指標を送信しているか

指標モジュールのログを確認する

このステップを行うには、VM に SSH 接続する必要があります。

指標モジュールのログは Syslog で確認できます。ログがない場合は、エージェント サービスが正常に実行されていません。この状態を修正するには、まず、エージェントはインストールされているが、実行されていないに移動します。

• Monitoring API への書き込み時に、PermissionDenied エラーが発生することがあります。このエラーは、Ops エージェントの権限が正しく構成されていない場合に発生します。次に例を示します。

  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"}
  

  このエラーを修正するには、Monitoring API を有効にし、モニタリング指標の書き込みロールを設定します。

• Monitoring API への書き込み時に、ResourceExhausted エラーが発生することがあります。プロジェクトが Monitoring API の割り当ての上限に達すると、このエラーが発生します。例:

  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"}
  

  このエラーを解決するには、割り当てを増やすか、指標のスループットを減らします。

• モジュールログに次のエラーが記録されていることがあります。

  {"error":"invalid_request","error_description":"Service account not enabled on this instance"}
  

  または

  can't fetch token from the metadata server
  

  これらのエラーが発生している場合、サービス アカウントまたは指定された認証情報なしでエージェントがデプロイされた可能性があります。この問題を解決する方法については、Ops エージェントを認可するをご覧ください。

ネットワーク接続に関する問題

エージェントが実行されていても、ログや指標が送信されない場合は、ネットワークに問題がある可能性があります。発生する可能性のあるネットワーク接続の問題の種類は、アプリケーションのトポロジによって異なります。Compute Engine ネットワーキングの概要については、VM のネットワーキングの概要をご覧ください。

接続の問題によく見られる原因は、次のとおりです。

• 受信トラフィックを妨げるファイアウォール ルール。ファイアウォール ルールの詳細については、VPC ファイアウォール ルールを使用するをご覧ください。
• HTTP プロキシの構成の問題。
• DNS 構成。

Ops エージェントはネットワーク接続エラーを検出するヘルスチェックを実行します。接続エラーに関して推奨されるアクションについては、ヘルスチェックのドキュメントをご覧ください。

Ops エージェント バージョン 2.28.0 以降では、Ops エージェントは、バッファ チャンクの格納に使用できるディスク容量を制限します。ロギングデータを Cloud Logging API に送信できない場合、Ops エージェントはバッファ チャンクを作成します。制限なしの場合、これらのチャンクは使用可能なすべての容量を消費するため、VM 上の他のサービスは中断される可能性があります。ネットワークの停止によりバッファ チャンクがディスクに書き込まれた場合、Ops エージェントはプラットフォーム固有の量のディスク容量を使用してチャンクを保存します。VM が Cloud Logging API にバッファ チャンクを送信できない場合、Linux VM では /var/log/google-cloud-ops-agent/subagents/logging-module.log、Windows VM では C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log に次のようなメッセージも表示されます。

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

指標またはログのどちらかのみを収集する必要がある

デフォルトでは、Ops エージェントは指標とログの両方を収集します。指標またはログの収集を無効にするには、Ops エージェントの config.yaml ファイルを使用して、デフォルトの logging または metrics サービスをオーバーライドし、デフォルトのパイプラインにレシーバーがないようにします。詳しくは以下をご覧ください。

• ロギングの service 構成の例
• 指標 service の構成例

Ops エージェントのサブエージェント サービスである Logging エージェントまたは Monitoring エージェントを無効にしてデータの取り込みを停止すると、構成が無効になります。この方法はサポートされていません。

指標が収集されているものの、何か問題がある

エージェントが「エクスポートに失敗しました。再試行します」というメッセージをロギングしている

累積指標の最初のデータポイントが破棄されると、「エクスポートに失敗しました」というログエントリが記録されます。次のログは有害ではないため、無視してもかまいません。

  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"}
  

エージェントが「TimeSeries に書き込めませんでした: ポイントを順番に書き込む必要があります」というメッセージをロギングしている

以前の Monitoring エージェントから Ops エージェントにアップグレードした後に、累積指標の書き込み中に次のエラー メッセージが表示された場合は、VM を再起動することで問題を解決できます。Ops エージェントと Monitoring エージェントでは累積指標の開始時刻の計算方法が異なります。このため、ポイントが順不同で表示されることがあります。VM を再起動すると、開始時刻がリセットされ、この問題が修正されます。

  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}
  

エージェントが「トークンは有効期限の短いトークン（60 分）で、適切な時間内である必要があります」というメッセージをロギングしている

エージェントが指標を書き込むときに次のエラー メッセージが表示される場合は、システム クロックが正しく同期されていないことを示しています。

  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.
  

システム クロックの同期の詳細については、VM で NTP を構成するをご覧ください。

エージェントが nvml タイプの指標レシーバーのログを記録できない

nvml レシーバーを使用して NVIDIA Management Library（NVML）の GPU 指標（agent.googleapis.com/gpu）を収集する場合は、NVML 指標のプレビュー サポートがあるエージェントの Ops のバージョンを使用しています。これらの指標のサポートは、Ops エージェント バージョン 2.38.0 で一般提供になりました。一般提供バージョンでは、nvml レシーバーによる指標収集が hostmetrics レシーバーに統合され、nvml レシーバーが削除されました。

Ops エージェント バージョン 2.38.0 以降をインストールした後、プレビューの nvml レシーバーを使用して、ユーザー指定の構成ファイル内のデフォルトのコレクション間隔を上書した場合は、「nvml タイプの指標レシーバーはサポートされていません」というエラー メッセージが表示されます。このエラーは、存在しない nvml レシーバーがユーザー指定の構成ファイルを参照しているために発生します。

この問題を修正するには、代わりに hostmetrics レシーバーで収集間隔をオーバーライドするように、ユーザー指定の構成ファイルを更新します。

GPU 指標がない

Ops エージェントがいくつかの指標を収集しているものの、NVIDIA Management Library（NVML）GPU（agent.googleapis.com/gpu）指標の一部またはすべてが欠落している場合は、構成に問題があるか、GPU を使用するプロセスがない可能性があります。

GPU 指標を収集していない場合は、GPU ドライバを確認します。GPU 指標を収集するには、Ops エージェントでは、GPU ドライバが VM にインストールされ、構成されている必要があります。ドライバを確認する方法は次のとおりです。

1. ドライバが正しくインストールされ、動作していることを確認するには、手順に沿って GPU ドライバのインストールを確認します。

2. ドライバがインストールされていない場合は、次の操作を行います。

   1. GPU ドライバをインストールします。

   2. Ops エージェントを再起動します。

      Ops エージェントは、GPU ドライバをインストールまたはアップグレードした後に再起動する必要があります。

   3. Ops エージェントのログを調べ、通信が正常に開始されたことを確認します。ログメッセージは、次のようになります。

      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.
      

GPU ドライバがインストールされ、Ops エージェントがドライバと通信していることが Ops エージェントのログに示されていても、GPU 指標が表示されない場合は、使用しているグラフに問題がある可能性があります。グラフのトラブルシューティングについては、グラフにデータが表示されないをご覧ください。

いくつかの GPU 指標を収集しているものの、processes 指標（processes/max_bytes_used と processes/utilization）が見当たらない場合は、GPU で実行中のプロセスがありません。GPU で実行中のプロセスがない場合、GPU processes 指標は収集されません。

一部の指標がないか、整合性がない

いくつかの指標は、Ops エージェントのバージョン 2.0.0 以降と Ops エージェントのプレビュー バージョン（2.0.0 未満のバージョン）または Monitoring エージェントとで処理方法が異なります。

次の表に、Ops エージェントと Monitoring エージェントのデータ収集方法の違いを示します。

指標タイプ（省略） agent.googleapis.com	Ops エージェント（一般提供）^†	Ops エージェント（プレビュー）^†	Monitoring エージェント
cpu_state	Windows で使用できる値は idle、interrupt, system、user です。	Windows で使用できる値は idle、interrupt, system、user です。	Windows で使用できる値は idle と used です。
disk/bytes_used と disk/percent_used	device ラベルのフルパスで取得されます（例: /dev/sda15）。 tmpfs や udev などの仮想デバイスの場合には取り込まれません。	device ラベルのパスに /dev なしで取り込まれます（例: sda15）。 tmpfs や udev などの仮想デバイスの場合に取り込まれます。	device ラベルのパスに /dev なしで取り込まれます（例: sda15）。 tmpfs や udev などの仮想デバイスの場合に取り込まれます。

^† 一般提供の列は、Ops エージェント バージョン 2.0.0 以降を示します。プレビュー版の列は、2.0.0 より前の Ops エージェント バージョンを示します。

Windows に固有の問題

以下のセクションは、Windows で実行されている Ops エージェントのみに適用されます。

Windows のパフォーマンス カウンタが破損している

指標サブエージェントの起動に失敗した場合、Cloud Logging に次のいずれかのエラーが表示されることがあります。

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

これらのエラーは、システムのパフォーマンス カウンタが破損した場合に発生することがあります。パフォーマンス カウンタを再構築することで、エラーを解決できます。管理者として PowerShell で次のコマンドを実行します。

cd C:\Windows\system32
lodctr /R

上記のコマンドは失敗することがあります。その場合は、PowerShell を再読み込みして成功するまで再試行してください。

コマンドが成功したら、Ops エージェントを再起動します。

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

エージェントの状態を完全にリセットする

エージェントが回復不能な状態になった場合は、以下の手順でエージェントを最初の状態に復元します。

注: このプロセスではすべてのバッファの状態が削除されるため、ログが失われる可能性があります。バッファの状態をリセットしないプロセスについては、バッファ ファイルをリセットしても保存するをご覧ください。

Linux

エージェント サービスを停止します。

sudo service google-cloud-ops-agent stop

エージェント パッケージを削除します。

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

エージェントのセルフログをディスクから削除します。

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

ディスク上のエージェントのローカル バッファを削除します。

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

注: ディレクトリ /var/lib/google-cloud-ops-agent/fluent-bit/buffers/ には、次のタイプのファイルが含まれています。

• バッファ ファイル: これらのファイルは、Ops エージェントによって記録され、処理されたものの、まだ Cloud Logging に取り込まれていないバッファ内のログエントリです。2.15.0 以上のバージョンでチャンクが破損している場合、Ops エージェントはチャンクをスキップします。ただし、手動でのクリーンアップが必要になる場合もあります。これらのファイルは、/var/lib/google-cloud-ops-agent/fluent-bit/buffers/tail.1/* のようなネストされたフォルダに保存されます。
• ログファイルのテーリング位置ファイル: これらのファイルには、Ops エージェントがすでに処理したログファイルの位置を記録します。これらのファイルが削除されると、Ops エージェントは、テーリングが構成されているファイルの先頭から開始します。これらのログがすでに正常に取り込まれている場合、これらのファイルを削除すると、ログの重複が発生する可能性があります。これらのファイルは、/var/lib/google-cloud-ops-agent/fluent-bit/buffers/default_pipeline_syslog* のようにファイルとしてディレクトリに直接保存されます。

前のコマンドの構文 .../buffers/*/ により、バッファ ファイルのみが削除されます。位置ファイルは削除されません。

エージェントを再インストールして、再起動します。

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

注: Windows のコマンドは、PowerShell で管理者として実行する必要があります。

エージェント サービスを停止します。

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*";

エージェント パッケージを削除します。

(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"

エージェントのセルフログをディスクから削除します。

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

ディスク上のエージェントのローカル バッファを削除します。

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

注: Linux と同様に、このコマンドは C:\ProgramData\Google\Cloud Operations\Ops Agent\run\buffers ディレクトリ内のサブディレクトリのみを削除するため、バッファ ファイルは削除されますが、位置ファイルはそのまま残ります。

エージェントを再インストールして、再起動します。

(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"

バッファ ファイルをリセットして保存する

VM のバッファ チャンクが破損していない場合（つまり、Ops エージェントのセルフログ ファイルに format check failed メッセージがない場合）は、エージェントの状態をリセットする際にローカル バッファを削除する以前のコマンドをスキップできます。

VM にバッファ チャンクが破損している場合は、それらを削除する必要があります。次のオプションは、バッファを処理するさまざまな方法を示しています。エージェントの状態を完全にリセットするで説明した他の手順も引き続き適用されます。

• オプション 1: buffers ディレクトリ全体を削除する。これが最も簡単な方法ですが、位置ファイルが失われるため、バッファ内のログが破損したり、ログが重複する可能性があります。

  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";
  

• オプション 2:buffers ディレクトリからバッファ サブディレクトリを削除しますが、位置ファイルは残します。この方法については、エージェントの状態を完全にリセットするをご覧ください。

• オプション 3: すべてのバッファ ファイルを削除しない場合、エージェントのセルフログから破損したバッファ ファイルの名前を抽出して、破損したバッファ ファイルのみを削除できます。

  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\' + $_)}
  };
  

• オプション 4: 破損したバッファが多く、すべてのログファイルを再処理する場合は、オプション 3 のコマンドを使用します。また、ログファイルごとに Ops エージェントの進行状況を保存している位置ファイルも削除できます。位置ファイルを削除すると、すでに正常に取り込まれているログでログの重複が発生する可能性があります。このオプションは、現在のログファイルのみを再処理します。すでにローテーションされたファイルや、TCP ポートなどの他のソースからのログは再処理されません。位置ファイルは buffers ディレクトリに保存されますが、ファイルとして保存されます。ローカル バッファは、サブディレクトリとして 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()}
  

最新の Ops エージェント リリースの既知の問題

以下のセクションでは、最新の Ops エージェント リリースにおける既知の問題について説明します。

Ops エージェント バージョン 2.47.0、2.48.0、2.49.0 のクラッシュ ループ

バージョン 2.47.0、2.48.0、2.49.0 には、ロギング用の FluentBit コンポーネントに問題がありました。このコンポーネントは特定のログの行で失敗し、Ops エージェントがクラッシュ ループします。

この問題は、Ops エージェントのバージョン 2.50.0 で解決されています。

Ops エージェント バージョン 2.46.0 以降、Prometheus 指標の namespace にはインスタンス ID に加えてインスタンス名が含まれる

バージョン 2.46.0 以降、Ops エージェントで Prometheus 取り込み形式の指標を取り込むときに、namespace ラベルの一部として VM 名が含まれます。以前のバージョンの Prometheus 指標では、namespace ラべルの一部として VM のインスタンス ID のみを使用しますが、バージョン 2.46.0 以降では、namespace が INSTANCE_ID/INSTANCE_NAME に設定されます。

namespace ラベルを使用するグラフ、ダッシュボード、アラート ポリシーがある場合は、Ops エージェントをバージョン 2.46.0 以降にアップグレードした後にクエリの更新が必要になることがあります。たとえば、PromQL クエリが http_requests_total{namespace="123456789"} のような場合、namespace ラベルは INSTANCE_ID/INSTANCE_NAME の形式であるため、これを http_requests_total{namespace=~"123456789.*"} に変更する必要があります。

Ops エージェント バージョン 2.39.0 以降で、型指定のない Prometheus 指標の指標タイプが変更になる

Ops エージェント バージョン 2.39.0 以降では、不明な型の Prometheus 指標の取り込みをサポートしています。以前のバージョンでは、Ops エージェントはこれらの指標をゲージとして扱いますが、バージョン 2.39.0 以降では、型指定のない指標はゲージとカウンタの両方として扱います。その結果、ユーザーはこれらの指標に対して累積オペレーションを使用できるようになりました。

MQL を使用して型指定のない Prometheus 指標をクエリするグラフ、ダッシュボード、アラート ポリシーがある場合は、Ops エージェントをバージョン 2.39.0 以降にアップグレードした後に MQL クエリを更新する必要があります。型指定のない指標を prometheus.googleapis.com/METRIC_NAME/gauge としてクエリするのではなく、次のように指標タイプを変更します。

• 指標のゲージ バージョンには prometheus.googleapis.com/METRIC_NAME/unknown を使用します。
• 指標のカウンタ バージョンには prometheus.googleapis.com/METRIC_NAME/unknown:counter を使用します。

PromQL を使用して型指定のない Prometheus 指標をクエリするグラフ、ダッシュボード、アラート ポリシーがある場合、変更する必要はありません。ただし、これらの指標に累積オペレーションを適用するには、Ops エージェントをバージョン 2.39.0 以降にアップグレードする必要があります。

Windows VM（バージョン 2.27.0～2.29.0）のメモリ使用量が多い

Windows の Ops エージェント バージョン 2.27.0～2.29.0 では、エージェントがソケットをリークするバグによりメモリ使用量が増加し、fluent-bit.exe プロセスで多数のハンドルが保持されることがあります。

この問題を軽減するには、バージョン 2.30.0 以降に Ops エージェントをアップグレードし、エージェントを再起動してください。

Windows でイベントログのタイムゾーンが正しくない（バージョン 2.15.0～2.26.0）

VM のタイムゾーンを UTC から変更すると、Cloud Logging の Windows イベントログに関連付けられたタイムスタンプが不正確になることがあります。これは Ops エージェント 2.27.0 で修正されました。ただし、この問題が発生している場合は、既知の Windows のメモリ使用量増加の問題も併せて修正されるように、Ops エージェント 2.30.0 以降にアップグレードすることをおすすめします。アップグレードできない場合は、次のいずれかの回避策を試すことができます。

UTC タイムゾーンを使用する

PowerShell で管理者として次のコマンドを実行します。

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

ロギングのサブエージェント サービスのタイムゾーン設定のみをオーバーライドする

PowerShell で管理者として次のコマンドを実行します。

注意: サービスの Environment レジストリ値（すでに存在する場合）は上書きされます。

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

Windows でタイムスタンプを解析する場合に正しくないタイムゾーンがある（2.27.0 より前のバージョン）

タイムスタンプを解析するログプロセッサを使用する場合、Windows ではタイムゾーンの値が正しく解析されません。これは Ops エージェント 2.27.0 で修正されました。ただし、この問題が発生している場合は、既知の Windows のメモリ使用量増加の問題も併せて修正されるように、Ops エージェント 2.30.0 以降にアップグレードすることをおすすめします。

古い Ops エージェント リリースの既知の問題

以下のセクションでは、古い Ops エージェント リリースで発生することが確認されている問題について説明します。

無害のログ（バージョン 2.9.1 以前）

疑似プロセスまたは制限されたプロセスから指標を取得すると、エラーが記録される場合があります。次のログは有害ではないため、無視してもかまいません。これらのメッセージが発生しないようにするには、Ops エージェントをバージョン 2.10.0 以降にアップグレードしてください。

    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
  

エージェントのセルフログが使用する CPU、メモリ、ディスク領域が多すぎる（バージョン 2.16.0 以前）

2.17.0 より前のバージョンの Ops エージェントでは、バッファ チャンクの破損により、Linux VM 上の /var/log/google-cloud-ops-agent/subagents/logging-module.log ファイルや Windows VM 上の C:\ProgramData\Google\Cloud Operations\Ops Agent\log\logging-module.log ファイルにより、CPU、メモリ、ディスク容量が大量に消費される可能性があります。その場合、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
  

この問題を解決するには、Ops エージェントをバージョン 2.17.0 以降にアップグレードして、エージェントの状態を完全にリセットします。

それでもシステムが大量のエージェントのセルフログを生成する場合は、ログ ローテーションの使用を検討してください。詳細については、ログ ローテーションを設定するをご覧ください。