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

このページは、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 の割り当てを超過している可能性があります。使用可能な割り当ては、GCP Console の [API とサービス] > [ダッシュボード] から確認できます。[Monitoring API] を選択します。

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

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

      • 「Unsupported collectd plugin/type combination」または「Unsupported collectd id」のエラーがログに記録されている場合は、サポートされていないエージェント指標を送信している可能性があります。これはエージェントのいずれかのサードパーティ製アプリケーションの構成を変更した場合に起こることがあります。変更を元に戻すには、特定のプラグインの構成を再インストールします。手順については、該当するドキュメント ページをご覧ください。エージェントを使用してその指標を 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. Try it!」 セクションで、[Authorize requests using OAuth 2.0] スイッチをクリックします。変更せずにフォームを受け入れて、[Authorize] をクリックします。

  4. 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. その他のフィールドはすべて空白のままにします。

  5. [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 つのタイムスタンプのスペルと書式を確認します。「承認されていません」というエラーは、プロジェクト ID のスペルが間違っていることを意味している場合があります。「見つかりませんでした」というエラーは、「名前」フィールドに必要な projects/ 接頭辞を省略したことを示している場合があります。問題を修正し、API 呼び出しをもう一度試してみます。

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

Compute Engine 認証情報を確認する

GCP Console の [Compute Engine] > [VM インスタンス] ページを使用して、Monitoring エージェントに関する適切な認証情報が Compute Engine VM インスタンスに存在することを確認します。認証情報は、通常はすべての新規 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. Stackdriver Monitoring API の横に書き込みのみまたはフルの権限が示されている場合は、適切な認証情報があります。
    3. それ以外の場合、インスタンスのデフォルトのサービス アカウントにエージェントが必要とする認証情報はありません。インスタンスでエージェントを使用するには、秘密鍵サービス アカウント認証情報を追加する必要があります。手順については、認証情報の追加をご覧ください。

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

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

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

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

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

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

新しい認証情報の生成

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

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

    1. このページから、ワークスペースに接続されているプロジェクトのリストを開きます。
      • AWS の場合は、対象のプロジェクト用の Cloud Console に直接移動するリンクを使用します。
      • GCP の場合は、対象の Compute Engine リソースを含むプロジェクトを特定し、Cloud Console に移動します。
    2. Cloud Console から IAM の [サービス アカウント] ページに移動します。
    3. 新しいサービス アカウントを作成し、そのアカウント用の新しい秘密鍵を生成します。

      最も簡単な方法は、正しい構成を持つ秘密鍵をダウンロードすることです。この鍵を取得するには、現在のページの 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 では、サービス管理コンソールを開いて Stackdriver Monitoring サービスを再起動します。

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

秘密鍵が正しいことを確認するには、認証情報は存在するかをご覧ください。具体的には、次のことを確認します。

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

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

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

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

ご不明な点がありましたら、Google のサポートページをご覧ください。