Monitoring エージェントのトラブルシューティング

このページは、Monitoring エージェントのインストールや実行に関する問題を診断するのに役立ちます。

チェックリスト

Monitoring エージェントのインストールまたは使用に問題がある場合は、次の点を確認してください。

  • Linux のインストール コマンドでエラーが発生した場合は、インストール コマンドの前に sudo を付加してください。

  • VM インスタンス上でエージェント サービスが実行されていることを確認します。

    • Windows VM の場合は、次の PowerShell コマンドを使用します。

      Get-Service -Name StackdriverMonitoring

      Stackdriver Monitoring というサービスを検索します。エージェントが実行されていない場合は、エージェントの再起動が必要になる可能性があります。

    • Linux VM の場合は、次のコマンドを使用します。

      sudo service stackdriver-agent status

      エージェントが実行されていない場合は、次のコマンドを使用して再起動することが必要になる可能性があります。

      sudo service stackdriver-agent restart

      再起動に失敗し、ログ出力に「Disabled via metadata」と表示されている場合は、Google Cloud Marketplace からイメージを実行している可能性があります。Google Cloud Marketplace では Monitoring エージェントがデフォルトで無効になっています。この動作は、google-monitoring-enable インスタンス メタデータキー（値は 0）によって制御されています。エージェントを再び有効化するには、このキーを削除するか、値を 1 に設定します（インスタンス メタデータの設定をご覧ください）。

      エージェントがメタデータによって無効化されていない場合は、エージェントを再インストールしてください。このプロセスの詳細については、Monitoring エージェントの再インストール をご覧ください。

  • エージェントからのエラー メッセージがログに書き込まれていないかどうかを確認します。

    • Windows では、Monitoring エージェントは Windows イベントログにメッセージを書き込みます。

    • Linux では、Monitoring エージェントは collectd パッケージであり、メッセージが /var/log/syslog または /var/log/messages に記録されます。ログメッセージの先頭には collectd または stackdriver-agent が付加されています。

      • HTTP 429 エラーが発生している場合は、Monitoring API の割り当てを超過している可能性があります。使用可能な割り当ては、Google Cloud コンソールで [API とサービス] > [ダッシュボード] を選択して確認できます。[Monitoring API] を選択します。

      • プロキシに問題がある場合は、HTTP プロキシが正しく構成されていることを確認します。その手順は Linux および Windows へのインストールに含まれています。

      • API アクセスや承認に関する問題がある場合や、「Unable to determine collectd endpoint」のようなエラー メッセージが発生している場合は、次のプロジェクトと認証情報を確認するをご覧ください。

      • ログに「Unsupported collectd plugin/type combination」または「Unsupported collectd id」というエラーが表示された場合は、サポートされていないエージェント指標を送信している可能性があります。これは次のような場合に発生する可能性があります。

        • エージェントのいずれかのサードパーティ アプリケーションの構成を変更した場合。変更を元に戻すには、特定のプラグインの構成を再インストールします。手順については、該当するドキュメント ページをご覧ください。エージェントを使用してその指標を Monitoring に送信する場合は、ユーザー定義指標への変換を考慮してください。

        • サードパーティのアプリケーション プラグインの 1 つが、Monitoring で不明な新しい指標を送信しています。これらの指標を確認して分類するリクエストを送信する方法の詳細については、サポートページをご覧ください。

  • エージェントが正しく実行されているようであっても、データを取得できない、またはアラート ポリシーが意図したとおりに機能しない場合は、エージェントが正しいプロジェクトにデータを送信していることを確認する必要があります。次のプロジェクトと認証情報を確認するをご覧ください。

プロジェクトと認証情報を確認する

Monitoring エージェントがアクセスエラーまたは承認エラーを報告している場合、エージェントが正しく実行されているようであってもデータが存在しない場合、またはアラート ポリシーが意図したとおりに機能しない場合は、VM インスタンスの認証情報が正しいかどうか（正しいプロジェクトを指定しているかどうかなど）を確認してください。

  • 秘密鍵ではなく標準の認証情報で Compute Engine VM インスタンスを使用している場合は、データが間違ったプロジェクトに送信されている可能性は低いものの、認証情報が不完全な可能性があります。認証情報の詳細については、Monitoring エージェントを認可するをご覧ください。認証情報を確認するには、Compute Engine 認証情報を確認するをご覧ください。

  • Amazon EC2 VM インスタンスを使用している場合、または Compute Engine インスタンスで秘密鍵認証情報を使用している場合は、認証情報が無効であるか、異なるプロジェクトの認証情報であることが考えられます。AWS アカウントの場合は、エージェントで使用されるプロジェクトが指標を送信する Google Cloud プロジェクトであることが必要です。認証情報の詳細については、Monitoring エージェントを認可するをご覧ください。認証情報を確認するには、秘密鍵認証情報を確認するをご覧ください。

それでも問題が解決しない場合は、Monitoring エージェントを再インストールするをご覧ください。

Compute Engine 認証情報を確認する

Google Cloud コンソールの Compute Engine [VM インスタンス] ページを使用して、Compute Engine VM インスタンスに Monitoring エージェント用の適切な認証情報があることを確認します。認証情報は、通常はすべての新規 Compute Engine VM インスタンスのデフォルトのサービス アカウントに追加されますが、インスタンスの作成時にこれらのデフォルトを上書きできます。

Google Cloud コンソールで、[VM インスタンス] ページに移動します。

[VM インスタンス] に移動

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

  1. 必要に応じて、現在の Google Cloud プロジェクトを Compute Engine VM インスタンスに関連付けられたプロジェクトに変更します。たとえば、[課金を有効にする] のプロンプトが表示された場合は、現在のプロジェクトに Compute Engine VM インスタンスがないことを意味します。
  2. [VM インスタンス] ページで、VM インスタンスの名前をクリックします。VM インスタンスの詳細ページが表示されます。
  3. [VM インスタンスの詳細] ページで、[Cloud API アクセス スコープ] の見出しの下を見ます。
    • 「すべての Cloud API に完全アクセス権を許可」と表示されている場合は、適切な認証情報があります。
    • Stackdriver Monitoring API（Cloud Monitoring API の古い名前）の横に、書き込みのみまたはフル権限があることが表示されている場合、適切な認証情報があります。
    • それ以外の場合、インスタンスのデフォルトのサービス アカウントにエージェントが必要とする認証情報はありません。インスタンスでエージェントを使用するには、秘密鍵サービス アカウント認証情報を追加する必要があります。手順については、認証情報の追加をご覧ください。

デフォルト認証情報が正しい場合は、Linux と Windows へのインストールに進みます。

秘密鍵認証情報を確認する

有効な秘密鍵認証情報が VM インスタンスにインストールされていることを確認するには、まず認証情報ファイルが予期されるロケーションに存在することを確認してから、認証情報ファイル内の情報が有効であることを確認します。以前に有効だった認証情報は、Google Cloud コンソールの [IAM と管理] > [サービス アカウント] セクションを使用して取り消すことができます。有効な認証情報が存在しない場合は、認証情報の追加を参照して、既存の認証情報を置換するか新しい認証情報を追加します。

認証情報は存在するか

秘密鍵サービス アカウント認証情報がインスタンスに存在するかどうかを確認するには、インスタンスで次の Linux コマンドを実行します。

sudo cat $GOOGLE_APPLICATION_CREDENTIALS
sudo cat /etc/google/auth/application_default_credentials.json

どちらかのコマンドで次のようなファイルが表示される場合は、インスタンスに有効な秘密鍵認証情報が存在する可能性があります。両方のコマンドでファイルが表示される場合は、GOOGLE_APPLICATION_CREDENTIALS で示されたファイルが使用されます。

{
  "type": "service_account",
  "project_id": "{your-project-id}",
  "private_key_id": "{your-private-key-id}",
  "private_key": "{your-private-key}",
  "client_email": "{your-project-number}-{your-key}@developer.gserviceaccount.com",
  "client_id": "{your-client-id}",
  "auth_uri": "https://accounts.google.com/o/oauth2/auth",
  "token_uri": "https://accounts.google.com/o/oauth2/token",
  "auth_provider_x509_cert_url": "{x509-cert-url}",
  "client_x509_cert_url": "{client-x509-cert-url}"
}

認証情報ファイルが存在しない場合は、認証情報の追加をご覧ください。

認証情報は有効か

認証情報ファイルで、project_id フィールドは Google Cloud プロジェクトであり、client_email はプロジェクト内のサービス アカウント、private_key_id はサービスの秘密鍵を識別します。この情報を、Google Cloud コンソールの [IAM と管理] > [サービス アカウント] セクションに表示されている情報と照合します。

次のいずれかに該当する場合、認証情報ファイルは有効ではありません。

  • Compute Engine VM インスタンスをチェックしているものの、認証情報ファイル内の Google Cloud プロジェクトがインスタンスを含むプロジェクトではない。
  • Amazon EC2 インスタンスをチェックしているものの、認証情報ファイル内の Google Cloud プロジェクトが、AWS アカウントから指標を送信する Google Cloud プロジェクトではない。
  • リストされたサービス アカウントが存在しない。削除された可能性があります。
  • リストされたサービス アカウントで適切な役割が有効になっていない。少なくとも、指標収集用の roles/monitoring.metricWriter（モニタリング指標ライター）と、ログの書き込みのための roles/logging.logWriter（ログライター）が必要です。
  • 秘密鍵が存在しない。取り消された可能性があります。

サービス アカウントに問題はないものの、秘密鍵が取り消されている場合は、新しい秘密鍵を作成してインスタンスにコピーできます。それ以外の場合は、次の認証情報の追加の説明に従って新しいサービス アカウントを作成する必要があります。

新しい認証情報の生成

認証情報が有効でない場合は、次の操作を行います。

  1. 秘密鍵で承認しなければならないインスタンスを含む接続プロジェクト（アクセス スコープ https://www.googleapis.com/auth/monitoring.write を含めずに作成された Compute Engine インスタンスを含む各プロジェクト）ごとにサービス アカウントを作成し、秘密鍵を生成します（まだ存在しない場合）。手順は次のとおりです。

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

      [設定] に移動

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

    2. [METRIC SCOPE] タブを選択します。
    3. 問題の Compute Engine リソースを含むプロジェクトを特定し、Google Cloud コンソールに移動します。
    4. Google Cloud コンソールの [IAM Service Accounts] ページに移動し、Google Cloud プロジェクトを選択して新しいサービス アカウントを作成し、そのアサービス カウント用の新しい秘密鍵を生成します。

      これらの手順を行うには、次のいずれかを行います。

      • [IAM Service Accounts] ページに移動して、Google Cloud プロジェクトを選択し、サービス アカウントの作成の手順を行います。

        IAM サービス アカウントに移動

      • 次のボタンをクリックして、Google Cloud プロジェクトを選択します。

        サービス アカウントを作成して鍵をダウンロードする

        前のボタンを使用すると、エージェント固有のサービス アカウントの鍵を作成し、ローカル システムにダウンロードするプロセスが自動化されます。必要に応じて、このプロセスによって必要なサービス アカウントも作成され、サービス アカウントに正しい権限が付与されます。エージェント固有のサービス アカウントの名前は stackdriver-1234@PROJECT_ID.iam.gserviceaccount.com のようになります。これらのアクションが完了すると、次のようなダイアログが表示されます。

        サービス アカウントと鍵が作成されたことをユーザーに通知するバナー。

  2. 対象のサービス アカウントに対応するインスタンスで秘密鍵を置き換えます。

    • Linux では、/etc/google/auth/application_default_credentials.json にある秘密鍵を置き換えます。
    • Windows では、C:\ProgramData\Google\Auth\application_default_credentials.json にある秘密鍵を置き換えます。詳細については、秘密鍵をインスタンスにコピーするをご覧ください。

  3. エージェントを再起動する

    • Linux の場合、sudo service stackdriver-agent restart を実行します。
    • Windows では、サービス管理コンソールを開いて Cloud Monitoring サービスを再起動します。

新しい秘密鍵が必要なプロジェクトが複数ある場合は、同じ手順をプロジェクトごとに繰り返します。

秘密鍵が正しいことを確認するには、認証情報は存在するかをご覧ください。特に、以下の点に注意してください。

  • インスタンス上の秘密鍵 JSON ファイルの内容を表示します。たとえば、Linux の場合は sudo cat /etc/google/auth/application_default_credentials.json を実行します。
  • project_id の値が、認証情報を生成したモニター対象プロジェクトのものと一致していることを確認します。

エージェントのデータを確認する

エージェントが指標を正しく送信していることを確認するには、Monitoring API の timeSeries.list メソッドを使用して、VM インスタンスから取得した最近の時系列データを見つけます。このメソッドは、メソッドのドキュメント ページにある API Explorer を使用して呼び出すことができます。データが表示されない場合は、エージェントが間違ったプロジェクトにデータを送信している可能性があります。これを確認するには、プロジェクトと認証情報を確認するをご覧ください。

timeSeries.list メソッドを使用する際の詳細な手順は次のとおりです。

  1. エージェントをインストールした VM インスタンスのインスタンス ID を調べます。

    • Compute Engine インスタンス: Compute Engine でインスタンスの詳細ページに移動します。ページの下部にある [同等の REST] をクリックします。 ID は 19 桁の数字です。

    • Amazon EC2 インスタンス: 各インスタンスの ID はインスタンスのリストに表示されています。ID は i-1a2b3c4d のようになります。

  2. timeSeries.list メソッドのドキュメント ページに移動します。

  3. API Explorer フォームに入力します。

    1. [name] に、VM インスタンスが存在するプロジェクトを指定し、プロジェクト名の前に projects/ を付けます。例: projects/[YOUR_PROJECT_ID]

    2. VM インスタンスからのエージェント指標を選択する次の記述を [filter] に設定します。これをコピーして API Explorer に貼り付けた後、VM インスタンス ID の部分を変更します。

      metric.type = "agent.googleapis.com/memory/bytes_used" AND resource.label.instance_id = "[YOUR-VM-INSTANCE-ID]"

    3. 検索する時間間隔を設定します。約 5 分間隔にします。

      • [interval.endTime] に現在の GMT 時刻を設定します。この時刻は、time.is/GMT で確認できます。次の例のような形式で時刻を指定してください。時刻を引用符で囲まないでください。

        2016-10-31T14:10:00Z

      • 同じ書式を使用して、終了時刻の約 5 分前の時刻を [interval.startTime] に設定します。

    4. その他のフィールドはすべて空白のままにします。

  4. [実行] をクリックします。

次のような出力が表示されます。

{
 "timeSeries": [
  {
   "metric": {
    "labels": {
     "state": "buffered"
    },
    "type": "agent.googleapis.com/memory/bytes_used"
   },
   "resource": {
    "type": "[INSTANCE-TYPE]",
    "labels": {
     "instance_id": "[YOUR-VM-INSTANCE-ID]",
     "zone": "[YOUR-INSTANCE-ZONE]",
     "project_id": "[YOUR-PROJECT-ID]"
    }
   },
   "metricKind": "GAUGE",
   "valueType": "DOUBLE",
   "points": [
    {
     "interval": {
      "startTime": "[START_TIME]",
      "endTime": "[END_TIME]"
     },
     "value": {
      "doubleValue": 27451392
     }
    },
    ...

API 呼び出しによって上記のような VM インスタンスからの時系列データが返された場合、エージェントは正常に動作しています。そのため、この手順はここで終了します。

時系列データが表示されない場合は、次の点を確認してください。

  • API 呼び出しでエラー メッセージが発生した場合、それはエージェントの問題を示すものではありません。API Explorer のフィールドが正しく設定されていることを確認してください。

    • 「引数が無効です」というエラーは、プロジェクト ID、フィルタ、または 2 つのタイムスタンプのスペルと形式に問題があることを示している可能性があります。

      要求されるタイムスタンプ引数は、指定する指標タイプによって異なります。指標タイプは、GAUGE、DELTA、または CUMULATIVE のデータを記録します。詳細については、MetricKind をご覧ください。

      DELTA 指標と CUMULATIVE 指標については、開始時刻と終了時刻の両方が必要であり、終了時刻を開始時間より後に設定する必要があります。これらの種類の指標タイプは、時間の経過に伴って測定された変化を記録するため、開始時刻と終了時刻はゼロ以外の間隔を定義する必要があります。

    • 「Not authorized」エラーは、プロジェクト ID のスペルが間違っていることを示している可能性があります。

    • 「Not found」エラーは、"name" フィールドで必須の projects/ 接頭辞が省略されていることを示している可能性があります。

    問題を修正し、API 呼び出しをもう一度試してみます。

  • API 呼び出しは成功したものの、レスポンスが空 { } の場合は、フィルタと時間間隔が正しいことを確認します。タイムスタンプの書式が間違っていると、データが返されない場合があります。すべてが正しいにもかかわらずデータを取得できない場合は、エージェントが指標データを送信していないか、少なくとも目的のプロジェクトには指標データを送信していません。これは認証情報に問題がある可能性を示しています。詳細については、秘密鍵認証情報を確認するをご覧ください。

Monitoring エージェントを再インストールする

最新バージョンのエージェントをインストールすると、多くの問題が解決する可能性があります。

エージェントがインストールされている Linux VM の特定

  • 次のいずれかのクエリを実行して、エージェントを実行している Linux VM を確認します。

    なお、クエリごとにプロジェクト名を入力し、時間範囲を調整する必要があります。

エージェントを自動的に再起動する

エージェントが実行中かどうかを確認し、クラッシュしている場合にエージェントを再起動するスクリプトをセットアップできます。

たとえば、Linux で次の crontab エントリを作成して、エージェントのステータスを 5 分ごとにチェックできます。

  */5 * * * * /bin/pidof stackdriver-collectd >/dev/null 2>&1 || /usr/sbin/service stackdriver-agent restart >/dev/null 2>&1

既知の問題

以降のセクションでは、Monitoring エージェントに関する既知の問題について説明します。

プロセスデータのアクセスの問題（Windows）

Windows のイベントログに、次のようなエージェントのエラー メッセージが表示される場合があります。

Read access denied for processes: Registry (84), smss.exe (264), csrss.exe (376), wininit.exe (448), csrss.exe (456), services.exe (580), NisSrv.exe (3008), MsMpEng.exe (3624), csrss.exe (7044)

このメッセージは、エージェントがシステム上のこのデータにアクセスできないことを示します。このメッセージが表示されないようにするには、SYSTEM ユーザーに、エラー メッセージに記載されたプロセスおよびサービスのプロセスデータを読み取るための十分な権限を付与します。このデータが必要ない場合は、この情報メッセージを無視してかまいません。

メタデータ キャッシュに関する問題（Linux）

Linux システムのログファイル（Debian / Ubuntu の /var/log/syslog、Red Hat / CentOS / SLES の /var/log/messages）に次のようなエラー メッセージが表示される場合があります。

collectd[25571]: uc_update: Value too old: name = myhost/processes-all/ps_vm;
value time = 1511345468.180; last cache update = 1511345468.180;
write_gcm: wg_update_stats failed.
write_gcm: uc_update returned an error.

これらのメッセージは無害な警告であり、データ損失を示すものではありません。タイムスタンプが一致しない場合に、現在のプロセス プラグインの実装によって生成されます。

無限値データポイントのドロップの問題（Linux）

Linux システムのログファイル（Debian / Ubuntu の /var/log/syslog、Red Hat / CentOS / SLES の /var/log/messages）に次のようなエラー メッセージが表示される場合があります。

write_gcm: can not take infinite value

このメッセージは、不正な形式のデータポイントが 1 つドロップされていることを示しています。これは通常、害のない警告です。無視してかまいません。

メタデータキー スロットルの問題（Linux）

Linux システムのログファイル（Debian / Ubuntu の /var/log/syslog、Red Hat / CentOS / SLES の /var/log/messages）に次のようなエラー メッセージが表示される場合があります。

collectd[7440]:match_throttle_metadata_keys: uc_meta_data_add returned an error
collectd[7440]:match_throttle_metadata_keys: mtg_update_stats failed

このメッセージは、メモリ スロットリングのステータス更新が 1 回失敗していることを示します。これは通常、害のない警告です。ただし、頻繁に発生する場合は、エージェントがメモリ不足に近づいていることを示している可能性があります。

Cloud Monitoring API の割り当て逸脱の問題（Linux）

Linux システムのログファイル（Debian / Ubuntu の /var/log/syslog、Red Hat / CentOS / SLES の /var/log/messages）に次のようなエラー メッセージが表示される場合があります。

collectd[25198]: write_gcm: Unsuccessful HTTP request 429

このメッセージは、Cloud Monitoring API の割り当て上限に到達したことを示しています。割り当て上限の管理については、割り当てガイドをご覧ください。

COLLECTD_INTERVAL が短いためメモリ消費量が多い（Linux）

COLLECTD_INTERVAL がデフォルトの 60 seconds より短く構成されている場合（たとえば 10 seconds）、エージェントのメモリ消費量が多くなることがあります。これは、リクエストを 1 つのスレッドから順次送信するために発生する、エージェントの既知の制限です。軽減するには、COLLECTD_INTERVAL を必要な指標のサブセットにのみ減らすとともに、残りの指標はデフォルトの間隔のままにしてください。

トークン バッファ オーバーフローの問題（Linux）

Linux システムのログファイル（Debian / Ubuntu の /var/log/syslog、Red Hat / CentOS / SLES の /var/log/messages）に次のようなエラー メッセージが表示される場合があります。

write_gcm: Error or buffer overflow when building auth_header
write_gcm: wg_oauth2_get_auth_header failed.
write_gcm: wg_transmit_unique_segment failed.
write_gcm: wg_transmit_unique_segments failed. Flushing.

これらのメッセージは、モニタリング エージェントをアップグレードしてバージョン 6.1.2 以降する必要があることを示しています。

リポジトリの「Origin」値が変更された（Linux）

エージェントをアップグレードまたはインストールするか、Debian/Ubuntu で apt-get update を実行すると、次のようなエラー メッセージが表示されることがあります（Linux）。

E: Repository 'https://packages.cloud.google.com/apt google-cloud-monitoring-buster-all InRelease' changed its 'Origin' value from 'google-cloud-monitoring-buster' to 'namespaces/cloud-ops-agents-artifacts/repositories/google-cloud-monitoring-buster-all'
E: Repository 'https://packages.cloud.google.com/apt google-cloud-monitoring-buster-all InRelease' changed its 'Label' value from 'google-cloud-monitoring-buster' to 'namespaces/cloud-ops-agents-artifacts/repositories/google-cloud-monitoring-buster-all'

このメッセージは、Package Repository のキャッシュがソースと異なっている可能性があることを示しています。この問題を解決するには、次のコマンドを実行します。

apt-get --allow-releaseinfo-change update

その後、アップグレードを実行するか、もう一度インストールします。

削除したエージェントが Google Cloud コンソールで「インストール済み」と報告される

エージェントをアンインストールした後、この変更が Google Cloud コンソールに反映されるまでに 1 時間ほどかかることがあります。

Monitoring エージェントが Windows に表示されないプログラム リストをアンインストールする

Monitoring エージェントが Windows コントロール パネルの [プログラムのアンインストール] リストにない場合は、インストールしたディレクトリから uninstall.exe を実行して、アンインストールします。