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 に送信する場合は、ユーザー定義指標への変換を検討してください。

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

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

プロジェクトと認証情報の確認

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

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

  • Amazon EC2 VM インスタンスを使用している場合、または Compute Engine インスタンスで秘密鍵の認証情報を使用している場合は、認証情報が無効であるか、異なるプロジェクトの認証情報である可能性があります。AWS アカウントの場合は、エージェントで使用されるプロジェクトが AWS コネクタ プロジェクトであることが必要です。認証情報の詳細については、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 APIs に完全アクセス権を許可」と表示されている場合は、適切な認証情報があります。
    • 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 アカウントの AWS コネクタ プロジェクトではない。
  • リストされたサービス アカウントが存在しない。削除された可能性があります。
  • リストされたサービス アカウントで適切なロールが有効になっていない。少なくとも、指標収集用の roles/monitoring.metricWriter（モニタリング指標の書き込み）と、ログの書き込みのための roles/logging.logWriter（ログ書き込み）が必要です。
  • 秘密鍵が存在しない。取り消された可能性があります。

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

新しい認証情報の生成

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

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

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

      [設定] に移動

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

    2. [SUMMARY] タブを選択します。
      • AWS の場合は、リンクを使用して、AWS コネクタ プロジェクトの Google Cloud コンソールに直接移動します。
      • Google Cloud の場合は、問題の Compute Engine リソースを含むプロジェクトを特定し、Google Cloud コンソールに移動します。
    3. 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] のようにします。Amazon EC2 インスタンスの場合は、Amazon アカウントの AWS コネクタ プロジェクトを使用する必要があります。

    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. [Execute] をクリックします。

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

{
 "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 指標の場合は、開始時刻と終了時刻の両方が必要です。また、終了時刻が開始時間より後の時間になっている必要があります。この種類の指標タイプは、時間の経過に伴って測定された変化を記録するため、開始時刻と終了時刻にはゼロ以外の間隔を定義する必要があります。

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

    • 「見つかりませんでした」というエラーは、[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.

これらのメッセージは、Monitoring エージェントをアップグレードしてバージョンを 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 時間ほどかかることがあります。

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

Windows コントロール パネルの [プログラムのアンインストール] のリストに Monitoring エージェントが表示されない場合は、インストールしたディレクトリで uninstall.exe を実行してアンインストールを行ってください。