Logging エージェントをトラブルシューティングする

このページでは、Logging エージェントのインストールまたは操作に関連する一般的な問題のトラブルシューティングについて説明します。

チェックリスト

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

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

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

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

    Get-Service -Name StackdriverLogging
    

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

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

    sudo service google-fluentd status
    

    エージェントが実行されていない場合は、次のコマンドを使用して再起動しなければならないことがあります。

    sudo service google-fluentd restart
    

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

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

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

  • Windows では、バージョン v1-9 以降の Logging エージェントのログが C:\Program Files (x86)\Stackdriver\LoggingAgent\fluentd.log に保存されます。

    以前のバージョンのエージェントのログを取得する方法はありません。

  • Linux では、Logging エージェントは fluentd パッケージであり、メッセージが /var/log/google-fluentd/google-fluentd.log に記録されます。

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

    • API アクセスまたは認証の問題が発生した場合は、Compute Engine の認証情報の確認に進みます。

• エージェントが正常に実行されているように見えても、データを取得できていない場合、エージェントが正しいプロジェクトにデータを送信していることを確認してください。後述の Compute Engine 認証情報を確認するをご覧ください。

• エージェントが承認に失敗した場合は、秘密鍵の認証情報が欠落しているか無効かどうかを確認します。

エージェントのインストールを確認する

インストールに成功したことを確認するには、ログ エクスプローラでエージェントのテスト ログエントリを確認します。

1. Google Cloud コンソールで、[ログ エクスプローラ] ページに移動します。

   [ログ エクスプローラ] に移動

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

2. ページの上部で、VM インスタンスが含まれているプロジェクトを選択します。

   • Compute Engine VM インスタンスの場合は、VM インスタンスが含まれている Google Cloud プロジェクトを選択します。
   • Amazon EC2 VM インスタンスの場合は、ログを送信する Google Cloud プロジェクトを選択します。

3. ウィンドウのタブで、VM インスタンスのリソースを選択します。

   • Compute Engine の場合は、[GCE VM インスタンス] を選択します。
   • Amazon EC2 の場合は、[AWS EC2 インスタンス] を選択します。
   • [syslog]（Linux）、[fluent.info]（Windows）、または [すべてのログ] を選択します。

「Successfully sent gRPC to Logging API」というログエントリがある場合、エージェントのインストールは完了しています。このメッセージは、エージェントがインストールされたときに 1 回だけ、エージェントの再起動時に毎回生成されます。

ログ エクスプローラの詳細については、ログ エクスプローラの使用をご覧ください。

エージェントをテストする

エージェントが動作していないと思われる場合は、実行されていることを確認し、Logging にテスト メッセージを送信してみます。

テスト メッセージを見つける

テスト メッセージの送信後に、それをログ エクスプローラで探します。

1. Google Cloud コンソールで、[ログ エクスプローラ] ページに移動します。

   [ログ エクスプローラ] に移動

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

2. ページの上部で、VM インスタンスが含まれているプロジェクトを選択します。

   • Compute Engine VM インスタンスの場合は、VM インスタンスが含まれている Google Cloud プロジェクトを選択します。
   • Amazon EC2 VM インスタンスの場合は、ログを送信する Google Cloud プロジェクトを選択します。

3. ウィンドウのタブで、VM インスタンスのリソースを選択します。

   • Compute Engine の場合は、[GCE VM インスタンス] を選択します。
   • Amazon EC2 の場合は、[AWS EC2 インスタンス] を選択します。
   • [syslog]（Linux）、[fluent.info]（Windows）、または [すべてのログ] を選択します。

4. テスト メッセージを含むログエントリがあります。その場合、Logging エージェントは正常に動作しています。

Compute Engine の認証情報を確認する

秘密鍵の認証情報を使用せずに Compute Engine VM インスタンスでエージェントを実行する場合、インスタンスには適切なアクセス スコープが必要です。また、インスタンスで使用されるサービス アカウント ID には適切な IAM 権限が必要です。

VM インスタンスを作成する場合は、デフォルトのスコープとサービス アカウントの設定だけでエージェントを実行できます。非常に古いインスタンスや、デフォルトの設定を変更したインスタンスの場合、適切な認証情報がない可能性があります。

デフォルトの認証情報の読み込みに失敗する

Logging ログファイルに Could not load the default credentials エラーがある場合、エージェントが Compute Engine メタデータ サーバーに接続できていない可能性があります。

次のようなエラーが表示されます。

Starting google-fluentd 1.8.4: /opt/google-fluentd/embedded/lib/ruby/gems/2.6.0/gems/googleauth-0.9.0/lib/googleauth/application_default.rb:74:in `get_application_default': Could not load the default credentials. Browse to (RuntimeError) https://developers.google.com/accounts/docs/application-default-credentials for more information.

この問題の原因の 1 つとして、VM にカスタム プロキシが設定されていることが考えられます。これを解決するには、プロキシの設定手順を参照して、Compute Engine メタデータ サーバー（metadata.google.internal または 169.254.169.254）がプロキシを経由しないようにします。エラーが解決しない場合は、VM からデフォルトの Compute Engine サービス アカウントを削除して、再度追加します。

アクセス スコープを確認する

アクセス スコープを確認するには、次の操作を行います。

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

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

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

2. VM インスタンスの名前をクリックします。インスタンスの詳細ページが表示されます。

3. [Cloud API アクセス スコープ] セクションで、[詳細] をクリックして API のリストを表示します。次のエントリを探します。

   1. 「このインスタンスは、すべての Google Cloud サービスに対する完全な API アクセス権を持っています。」と表示されている場合、アクセス スコープは適切です。
   2. Stackdriver Logging API（Cloud Logging API の旧称）の横に [書き込みのみ] または [フル 権限が付与されている場合、インスタンスのアクセス スコープは Cloud Logging エージェントに適切です。
   3. Stackdriver Monitoring API（Cloud Monitoring API の古い名前）の横に、書き込みのみまたはフル権限があることが表示されている場合、インスタンスのアクセス スコープは Cloud Logging エージェントに適切です。

問題を是正する

Compute Engine インスタンスに適切なアクセス スコープがない場合は、必要なアクセス スコープをインスタンスに追加します。

次の表は、Logging エージェントと Monitoring エージェントに関連するスコープを示します。

デフォルトのサービス アカウントの権限を確認する

Compute Engine VM インスタンスのアクセス スコープが適切であっても、インスタンスのデフォルト サービス アカウントがエージェントに適切な IAM 権限を提供しない場合があります。

デフォルトのサービス アカウントの権限を確認するには、デフォルトのサービス アカウントを探します。

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

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

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

2. VM インスタンスの名前をクリックします。インスタンスの詳細ページが表示されます。

3. ページで [サービス アカウント] という見出しを探します。インスタンスのデフォルトのサービス アカウントが表示されます。次のようになります。

   [ID]-compute@developer.gserviceaccount.com
   

4. Google Cloud コンソールの [IAM] ページに移動します。

   [IAM] に移動

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

5. [プリンシパル別に表示] を選択します。ユーザー、グループ、サービス アカウントの一覧が表示されます。[Role] 列に、プロジェクトの各メンバーのロールが表示されます。

6. インスタンスのデフォルト サービス アカウントの行に、1 つ以上の役割が表示されます。

   • 編集者が表示されている場合、その役割はすべてのエージェントに適切です。組織のポリシーの構成によっては、デフォルトのサービス アカウントに編集者のロールが自動的に付与される場合があります。
   • ログ書き込みが表示されている場合は、これは Logging エージェントに十分なロールです。書き込み権限を含む他の Logging ロールについては、Cloud Logging のアクセス制御をご覧ください。
   • モニタリング指標の書き込みが表示されている場合、これは Monitoring エージェントに十分な役割です。書き込み権限を含む他のモニタリングロールについては、Cloud Monitoring のアクセス制御をご覧ください。

問題を是正する

デフォルトのサービス アカウントに十分なロールがない場合は、[IAM と管理] > [IAM] ページの順に移動して、サービス アカウントのロールを編集してみてください。エージェントの承認に必要な Logging ロールまたは Monitoring ロールを追加します（Logging の場合はログ書き込み、Monitoring の場合はモニタリング指標の書き込み）。

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

Compute Engine VM インスタンスでは、適切な権限を持つデフォルト以外のサービス アカウントを使用するようにエージェントを構成できます。AWS EC2 VM インスタンスでは、このようなサービス アカウントを使用するようにエージェントを構成する必要があります。

この方法でエージェントを構成するには、該当するサービス アカウントの秘密鍵の認証情報を作成し、エージェントに渡す必要があります。

1. 秘密鍵の認証情報を含むファイルの名前が格納されている環境変数 GOOGLE_APPLICATION_CREDENTIALS を検索します。

2. この環境変数が存在しない場合は、デフォルトの場所で認証情報を探します。

   Linux

   /etc/google/auth/application_default_credentials.json
   

   Windows

   C:\ProgramData\Google\Auth\application_default_credentials.json
   

3. デフォルトの場所に認証情報が含まれていない場合、エージェントはメタデータ サーバーのアプリケーションのデフォルト認証情報を使用します。

次の情報は、秘密鍵の認証情報の問題を診断するのに役立ちます。

1. 秘密鍵は適切な場所にあるか
2. 秘密鍵はサービス アカウントに対して有効か
3. エージェントに必要な役割がサービス アカウントに付与されているか

有効な秘密鍵認証情報が VM インスタンスにインストールされていることを確認するには、まず認証情報ファイルが予期されるロケーションに存在することを確認してから、認証情報ファイル内の情報が有効であることを確認します。

認証情報は存在するか

秘密鍵サービス アカウント認証情報がインスタンスに存在するかどうかを確認するには、インスタンスで次の 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}"
}

認証情報の構成間に不一致があると、エージェントがサービスで要求されるものとは異なる認証情報を使用する可能性があります。たとえば、ログインシェルの GOOGLE_APPLICATION_CREDENTIALS でカスタムの認証情報の場所を設定しているが、エージェントのサービス構成でその変数を設定していない場合、サービスはカスタムの場所ではなくデフォルトの場所を探します。

認証情報の環境変数を確認または変更するには、/etc/default/google-fluentd で GOOGLE_APPLICATION_CREDENTIALS にアクセスするか、設定します。

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

認証情報は有効か

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

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

• Compute Engine インスタンスをチェックしていますが、認証情報ファイル内の Google Cloud プロジェクトはインスタンスを含むプロジェクトではありません。
• Amazon EC2 インスタンスをチェックしていますが、認証情報ファイル内の Google Cloud プロジェクトが、ログを送信する Google Cloud プロジェクトではありません。
• リストされたサービス アカウントが存在しない。削除された可能性があります。
• 一覧表示されたサービス アカウントのロールが正しく設定されていません: Cloud Logging エージェントのログ書き込みと Cloud Monitoring エージェントの Monitoring Metric Writer
• 秘密鍵が存在しない。取り消された可能性があります。

認証情報は、Google Cloud コンソールの [IAM と管理] > [サービス アカウント] セクションを使用して取り消すことができます。有効な認証情報が存在しない場合は、認証情報の追加を参照して、既存の認証情報を置換するか新しい認証情報を追加します。

サービス アカウントに問題はないものの、秘密鍵が取り消されている場合は、新しい秘密鍵を作成してインスタンスにコピーできます。サービス アカウントキーの作成をご覧ください。

それ以外の場合は、認証情報の追加の説明に従って新しいサービス アカウントを作成する必要があります。

ログの除外クエリを確認する

現在の除外クエリを表示して、探しているログが誤って除外されていないか確認します。

ファイアウォールを確認する

インスタンスが logging.googleapis.com にアクセスできるかどうかを確認するには、インスタンスで次の Linux コマンドを実行します。

curl -sSL 'https://logging.googleapis.com/$discovery/rest?version=v2' | head

ファイアウォールがアウトバウンド トラフィックをブロックすると、このコマンドの完了までに時間がかかることがあります。ファイアウォールの問題を示す出力例:

curl: (7) Failed to connect to 2607:f8b0:4001:c03::5f: Network is unreachable

アウトバウンド トラフィックのルールを設定する方法については、ファイアウォール ルールをご覧ください。

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

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

• 問題が認証情報に関連していない場合は、スキップして、Linux と Windows へのインストールに進みます。

• エージェントと必要な認証情報のインストール方法の詳細については、Logging エージェントをインストールするをご覧ください。

その他の一般的な問題

次の表に、Cloud Logging エージェントで発生する可能性がある一般的な問題とその修正方法を示します。

Linux の場合、Logging エージェントはエラーを /var/log/google-fluentd/google-fluentd.log に記録します。Windows では、Logging エージェントは C:\Program Files (x86)\Stackdriver\LoggingAgent\fluentd.log（バージョン v1-9 以降）にエラーを記録します。エラークラス Google::APIClient::ClientError は、権限または API アクセスに問題があることを示します。

エージェントが正常に実行された後でも、エラーが発生する場合があります。たとえば、プロジェクトや VM インスタンスに必要な権限が誰かに取り消された場合などです。

ログ スループットの制限

Logging エージェントが処理できる最大ログ スループットは、CPU の制限を受けます。ログ スループットが増加すると、CPU 使用率が高くなる傾向があります。ただし、デフォルトの構成では、エージェントが使用できる CPU コアは 1 つだけです。そのため、ログ スループットが急増すると、エージェントが CPU 使用率の上限に達する場合があります。急増が一時的なものである場合、Logging エージェントはログをバッファリングして、後でこれを処理します。ログ スループットが常に高い場合、ログがバッファをオーバーフローして最終的に失われる可能性があります。

通常、各ログエントリが 1,000 バイトの未加工テキストで、追加の形式処理が含まれていない場合、Logging エージェントは 1 秒あたり約 5,500 件のログエントリで 1 コアの CPU 上限に達します。ログエントリに JSON や正規表現の解析などの高度な処理が必要な場合は、1 秒あたりの最大ログエントリが少なくなることがあります。

より高いログ スループットが必要な場合は、Ops エージェントの使用を検討してください。Linux で、1,000 バイトの未加工のテキストで、追加の処理を伴わないログエントリの場合、Ops エージェントは 1 秒あたり約 160,000 のログエントリを処理できます。

最大ログサイズを超えています

1 つ以上のログエントリが最大サイズ限度を超えている場合は、fluentd ログに次のようなエントリが表示されることがあります。

Dropping 1 log message(s) error_class="Google::Apis::ClientError" error="Invalid request"

または

Dropping 1 log message(s) error="3:Log entry with size 1000515 bytes exceeds maximum size of 112640 bytes" error_code="3"

このエラーを解決するには、ログエントリのサイズが上限を超えないよう制限します。たとえば、次のサンプルコードを入力すると、mytag タグが付いたログが削除され、message フィールドにデータが格納されます。

# Cloud Logging only supports log entries that are up to 256 KiB in size.
# Trim the entries to just under that size to avoid dropping them.
<filter [MY_TAG]>
  @type record_transformer
  enable_ruby true
  <record>
    message ${record['message'].length > 256000 ? "[Trimmed]#{record['message'][0..256000]}..." : record['message']}
  </record>
</filter>

ログが重複しています

LogEntry.insertID がエージェント内の処理パイプラインに追加されます。insertID が重複したログで異なる場合、ログがログファイルから複数回記録されることを意味します。これは、ログ ローテーションが存在する場合、または pull ファイルが欠落しているか破損している場合に発生します。この問題が起こる可能性を減らすには、任意の in_tail 入力の位置ファイルが、/var/log フォルダ、またはログ ローテーションが有効になっているその他のフォルダ内に存在しないように構成します。

また、ロギング パイプラインは LogEntry.timestamp フィールドでログの重複排除を行います。ログエントリの実際のタイムスタンプが正しく解析されていることを確認してください。ログエントリの元のタイムスタンプを解析するように Fluentd が設定されていない場合、Fluentd はログエントリを処理する際にその時間を使用します。そのため、入力が複数回読み取られる場合、ログ行のタイムスタンプが同じであっても、Fluentd に異なるタイムスタンプを使用した異なるログエントリとして扱われる場合があります。

監査ログエラーが繰り返される: Data points cannot be written more than 24h in the past

バージョン 1.8.5～1.9.3 に影響する既知の問題により、エージェントが 24 時間以上実行されている場合、次のようなログがデータアクセス監査ログに繰り返し表示されます。

Field timeSeries[0].points[0].interval.end_time had an invalid value of "2021-10-20T20:16:34.010866-07:00": Data points cannot be written more than 24h in the past.

この問題を解決するには、エージェントを 1.9.4 以降にアップグレードします。

ログ内の Unicode 文字はスペースまたは「�」で置き換えられます。

デフォルトでは、in_tail 入力は入力ファイルが ASCII でエンコードされていることを想定しているため、ASCII 以外の文字はすべてスペースに置き換わります。UTF-8 でエンコードされたファイルを実際に取り込むには、in_tail の構成で 2 つのオプションを指定する必要があります。

<source>
  @type tail
  …

  encoding UTF-8
  from_encoding UTF-8
</source>

両方のオプションが必要です。encoding オプションのみを指定すると、取り込まれたログの ASCII 以外の文字は「�」に置き換わります。

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

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

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

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