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

このページは、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」と表示されている場合、Cloud Marketplace からのイメージを実行している可能性があります。Cloud Marketplace では Monitoring エージェントがデフォルトで無効になっています。この動作は、google-monitoring-enable インスタンス メタデータキー(値は 0)によって制御されています。エージェントを再び有効化するには、このキーを削除するか、値を 1 に設定します(インスタンス メタデータの設定をご覧ください)。

      エージェントがメタデータによって無効化されていない場合は、エージェントを再インストールしてください。 エージェントを再インストールするをご覧ください。

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

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

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

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

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

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

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

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

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

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

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

エージェントからアクセスや認証に関するエラーが報告される場合や、エージェントが正しく実行されているようであってもデータがなかったり、アラート ポリシーが意図したとおりに機能しなかったりする場合は、指定先のプロジェクトが正しいかどうかを含め VM インスタンスの認証情報が正しいことを確認する必要があります。

  • Monitoring にデータが送信されているかどうかを確認するには、時系列データの一部を読み込んでみます。その手順については、エージェントとプロジェクトの接続を確認するをご覧ください。データが表示される場合、エージェントに問題はありません。

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

  • Amazon EC2 VM インスタンスを使用している場合や Google Compute Engine インスタンスで秘密鍵認証情報を使用している場合は、認証情報が無効であるか、違うプロジェクトの認証情報である可能性があります。AWS アカウントの場合は、エージェントで使用されるプロジェクトが AWS コネクタ プロジェクト(通常は "AWS Link..." という名前)であることが必要です。認証情報の詳細については、エージェントの承認をご覧ください。認証情報を確認するには、秘密鍵認証情報を確認するをご覧ください。

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

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

エージェントが指標を正しく送信していることを確認するには、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 メソッドのドキュメント ページに移動します。

    timeSeries.list ページを開く

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

    1. [name] に、VM インスタンスが存在するプロジェクトを指定し、プロジェクト名の前に projects/ を付けます。例: projects/[YOUR_PROJECT_ID]。Amazon EC2 インスタンスの場合、Amazon アカウント用の AWS コネクタ プロジェクトを使用する必要があります。通常、これには "AWS Link" で始まる名前が付けられています。

    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": "[GCP-OR-AWS-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 つのタイムスタンプのスペルと形式に問題があることを示している可能性があります。

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

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

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

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

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

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

Compute Engine 認証情報を確認する

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

Compute Engine インスタンスのページに移動

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

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

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

有効な秘密鍵認証情報が VM インスタンスにインストールされていることを確認するには、まず認証情報ファイルが必要な場所に存在することを確認してから、認証情報ファイル内の情報が有効であることを確認します。以前に有効だった認証情報は、Cloud Console の [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 は GCP プロジェクト、client_email はプロジェクト内のサービス アカウント、private_key_id はサービス アカウントの秘密鍵を示します。この情報を、Cloud Console の [IAM と管理] > [サービス アカウント] セクションに表示されている情報と照合します。

次のいずれかに該当する場合、認証情報ファイルは無効です。

  • Compute Engine インスタンスをチェックしているが、認証情報ファイル内の GCP プロジェクトがインスタンスを含むプロジェクトではない。
  • Amazon EC2 インスタンスをチェックしていますが、認証情報ファイル内の GCP プロジェクトが、AWS アカウントのコネクタ プロジェクト(名前は AWS Link...)ではありません。
  • リストされたサービス アカウントが存在しない。削除された可能性があります。
  • リストされたサービス アカウントで適切な役割が有効になっていない。少なくとも、Monitoring エージェントの roles/monitoring.metricWriter(モニタリング指標の書き込み)と Logging エージェントの roles/logging.logWriter(ログの書き込み)が必要です。
  • 秘密鍵が存在しない。取り消された可能性があります。

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

新しい認証情報の生成

認証情報が有効でない場合:

  1. 秘密鍵で承認しなければならないインスタンスを含む接続プロジェクト(すべての AWS コネクタ プロジェクトと、モニタリング スコープなしで作成された Compute Engine インスタンス)ごとに、サービス アカウントを作成して秘密鍵を生成します(それらがまだ存在しない場合)。手順は次のとおりです。

    1. ワークスペースに接続されているプロジェクトのリストを確認するには、[Monitoring] に移動してください。

      [モニタリング] に移動

    2. Monitoring のナビゲーション パネルで、[設定] を選択し、[概要] タブを選択します。

      • AWS の場合は、対象のプロジェクト用の Cloud Console に直接移動するリンクを使用します。
      • GCP の場合は、対象の Compute Engine リソースを含むプロジェクトを特定し、Cloud Console に移動します。
    3. Cloud Console から IAM の [サービス アカウント] ページに移動します。

    4. 新しいサービス アカウントを作成し、そのアカウント用の新しい秘密鍵を生成します。

      最も簡単な方法は、正しい構成を持つ秘密鍵をダウンロードすることです。この鍵を取得するには、現在のページの URL の末尾に &createStackdriverServiceAccount を付加します。詳細については、サービスアカウントを作成するをご覧ください。

  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 の値が、認証情報を生成したモニター対象プロジェクトのものと一致していることを確認します。

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

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

エージェントがインストールされている 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

既知の問題

  • データアクセスの問題を処理する(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;
    

    このメッセージは、現在のプロセス プラグインの実装によってトリガーされる無害な警告であり、データの損失を示すものではありません。

  • 無限値データポイントのドロップの問題(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 回失敗していることを示します。エージェントがメモリ不足になっている可能性があります。

  • Monitoring API の割り当て逸脱の問題(Linux):

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

    collectd[25198]: write_gcm: Unsuccessful HTTP request 429
    

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