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

このページでは、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 インスタンス メタデータキー(値は 0)によって制御されています。エージェントを再び有効化するには、このキーを削除するか、値を 1 に設定します(インスタンス メタデータの設定をご覧ください)。

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

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

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

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

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

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

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

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

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

    • Compute Engine VM インスタンスの場合は、VM インスタンスを含む Cloud プロジェクトを選択します。
    • Amazon EC2 VM インスタンスの場合は、AWS アカウントを Google Cloud サービスにリンクする [AWS コネクタ プロジェクト][aws-connector] を選択します。
  2. ウィンドウのタブで、VM インスタンスのリソースを選択します。

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

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

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

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

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

Linux インスタンス

次の手順は、Linux が実行されている Compute Engine インスタンスと Amazon EC2 VM インスタンスの両方に適用されます。

  1. VM インスタンスで次のコマンドを実行して、Logging エージェントが実行されていることを確認します。

    ps ax | grep fluentd
    

    出力は次のようになります。

     2284 ?        Sl     0:00 /opt/google-fluentd/embedded/bin/ruby /usr/sbin/google-fluentd [...]
     2287 ?        Sl    42:44 /opt/google-fluentd/embedded/bin/ruby /usr/sbin/google-fluentd [...]
    
  2. VM インスタンスで次のコマンドを実行して、テストログ メッセージを送信します。

    logger "Some test message"
    

Windows インスタンス

Logging エージェントには、次の 2 つの Windows サービス名があります。

  • バージョン v1-5 以降の場合は StackdriverLogging
  • それよりも前のバージョンの場合は fluentdwinsvc

1 つのエージェント サービスのみを実行してください。PowerShell を使用して、VM インスタンスで次のコマンドを実行します。

  1. 両方のサービスのステータスを確認します。実行する必要があるサービスがわかっている場合は、そのサービス名を使用できます。

    Get-Service StackdriverLogging,fluentdwinsvc
    
  2. サービスが実行されていない場合は、エラー メッセージが表示されます。実行中の場合は、次のような出力が表示されます。

    Status    Name                DisplayName
    ------    ----                -----------
    Running  StackdriverLogging   Cloud Logging
    
  3. 両方のサービスにクエリを送信すると、次の 1 つのエラー メッセージと 1 つの Running ステータスが表示されます。

    • Running ステータスが表示されない場合、Logging エージェントは実行されていません。
    • StackdriverLogging が実行中であることが表示された場合は、最新のエージェント バージョンが実行されています。具体的なバージョンを確認するには、バージョンを取得するをご覧ください。
    • fluentdwinsvc が実行中であることが表示された場合は、最新バージョンにエージェントをアップグレードする必要があります。
  4. 管理者権限が必要: いずれかのエージェント バージョンが実行されている場合は、次の PowerShell コマンドを実行してテストログ メッセージを送信します。

    New-EventLog   -LogName Application -Source "Test Source"
    Write-EventLog -LogName Application -Source "Test Source" -EntryType Information -EventID 1 -Message "Testing 123 Testing."
    

テスト メッセージの検索

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

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

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

    • Compute Engine VM インスタンスの場合は、VM インスタンスを含む Cloud プロジェクトを選択します。
    • Amazon EC2 VM インスタンスの場合は、AWS アカウントを Google Cloud サービスにリンクする [AWS コネクタ プロジェクト][aws-connector] を選択します。
  2. ウィンドウのタブで、VM インスタンスのリソースを選択します。

    • Compute Engine の場合は、[GCE VM インスタンス] を選択します。
    • Amazon EC2 の場合は、[AWS EC2 インスタンス] を選択します。
    • [syslog](Linux)、[fluent.info](Windows)、または [すべてのログ] を選択します。
  3. テスト メッセージを含むログエントリがあります。その場合、Logging エージェントは正常に動作しています。

Compute Engine 認証情報を確認する

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

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

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

Logging のログファイルに Could not load the default credentials のエラーが発生した場合、エージェントが Compute Engine メタデータ サーバーに接続できていない可能性があります。この問題の原因の 1 つとして、VM にカスタム プロキシが設定されていることが考えられます。これを解決するには、プロキシの設定手順を参照して、Compute Engine メタデータ サーバー(metadata.google.internal または 169.254.169.254)がプロキシを経由しないようにします。ログ全体は次のようになります。

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. [Compute Engine] > [VM インスタンス] のページを開きます。

    [インスタンス] ページを開く

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

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

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

問題を解決する

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

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

アクセス スコープ エージェントの権限
https://www.googleapis.com/auth/logging.write Logging エージェントに必要な権限
https://www.googleapis.com/auth/monitoring.write Monitoring エージェントに必要な権限

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

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

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

  1. プロジェクトの Compute Engine ダッシュボードを開きます。

    Compute Engine インスタンスのページを開く

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

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

    [ID]-compute@developer.gserviceaccount.com
    
  4. プロジェクトの [IAM と管理] > [IAM] ページに移動します。[プロジェクト「PROJECT_NAME」の権限] というページ見出しが表示されます。

    [IAM] ページを開く

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

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

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

問題を解決する

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

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

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

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

  1. 秘密鍵の認証情報を含むファイルの名前が格納されている環境変数 GOOGLE_APPLICATION_CREDENTIALS を検索します。
  2. この環境変数が存在しない場合は、標準ファイルで認証情報を探します。

Linux

 /etc/google/auth/application_default_credentials.json

Windows

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

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

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

有効な秘密鍵認証情報が 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...)ではありません。
  • リストされたサービス アカウントが存在しない。削除された可能性があります。
  • 一覧表示されたサービス アカウントのロールが正しく設定されていません: Cloud Logging エージェントのログ書き込みと Cloud Monitoring エージェントの Monitoring Metric Writer
  • 秘密鍵が存在しない。取り消された可能性があります。

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

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

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

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

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

インスタンスが 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

下り(外向き)トラフィックの設定方法については、ファイアウォール ルールをご覧ください。

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

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

その他の一般的な問題

次の表に、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 インスタンスに必要な権限が誰かに取り消された場合などです。

エラー 原因 解決方法
The agent's installer on Windows fails to run(Windows 上でエージェントのインストーラの実行に失敗します) インストーラをシステム ディレクトリにダウンロードした可能性があります。 インストーラを C:\Users\[USERID]\ など、システム以外のディレクトリに移動します。
Project has not enabled the API(プロジェクトで API が有効化されていません) プロジェクトで Cloud Logging API が有効になっていません。 API Console に移動して、Cloud Logging API のステータスを ON に変更します。
Request had invalid credentials(リクエストの認証情報が無効です)
または
Unable to fetch access token (no scopes configured?)(アクセス トークンを取得できません(スコープ未構成?))
VM インスタンスに適切な認証情報がありません。Amazon EC2 VM を使用している場合は、エージェントをインストールする前に認証情報を VM インスタンスにインストールする必要があります。 エージェントの承認の説明に沿って、認証情報をインストールします。
Authorization failed(承認に失敗しました) Logging エージェント用の秘密鍵承認認証情報が正しく構成されていません。 秘密鍵認証情報の確認をご覧ください。
呼び出し元に権限がありません プロジェクトで承認に使用しているサービス アカウントに十分な権限がありません。これは、Compute Engine または App Engine の中で使用されるデフォルトのサービス アカウントのこともあれば、秘密鍵承認用に使用されるユーザー定義のサービス アカウントのこともあります。このアカウントには編集者のロールが必要です。 プロジェクトの IAM ページでサービス アカウントの権限を変更します。必要であれば、インスタンスのサービス アカウントとアクセス スコープを変更するの手順で既存の VM のアクセス スコープを変更できます。
Cannot obtain project ID(プロジェクト ID を取得できません) Cloud Logging エージェントがサービス アカウントの秘密鍵の認証情報ファイルからプロジェクト ID を取得できません。 エージェントのプロジェクト ID を追加またはオーバーライドするには、VM インスタンス上でエージェントの構成ファイル /etc/google-fluentd/google-fluentd.conf を編集します。<match **> セクションに次の行を追加してください。
project_id [YOUR_PROJECT_ID]
またはエージェントの承認を参照して認証情報を修正または置換してください。
Window Logging agent stops ingesting event logs from some channels(Window Logging エージェントが一部のチャネルのイベントログの取り込みを停止します) Logging エージェントが稼働中で、他のチャネルからのエージェント ログとイベントログの取り込みの最中でも、Logging エージェントは、特定のチャネルからのイベントログの取り込みに、通知なく失敗する場合があります。この理由は、このプレゼンテーションで説明したように、windows_eventlog プラグインにいくつかの問題があるためです。この問題は、Windows_eventlog2 を使用することで解決します。 注: windows_eventlog2 プラグインのデータ形式は、windows_eventlog プラグインと下位互換性がありません。これらのログ用に設定された BigQuery または Google Cloud Storage エクスポート パイプラインがある場合、それに応じて調整する必要があります。windows_eventlogwindows_eventlog2 によって提供されるログエントリの比較をご覧ください。windows_eventlog2 を使用するには、まず Logging エージェントを停止してから、こちらのサンプル構成ファイルのような構成ファイルに置き換える必要があります。最後に、Logging エージェントを起動します。
Logging agent stops ingesting logs in the presence of logrotate(logrotate が存在するときに、Logging エージェントがログの取り込みを停止します) logrotate が copytruncate に設定されている場合、Logging エージェントが入力ファイル内での現在の場所を見失うことがあります。 logrotate によってファイルの切り捨てではなくファイルの移動が行われるよう、nocopytruncate を設定することをおすすめします。copytruncate を設定したままにする場合は、対応策として定期的にエージェントを再起動してください。postrotate を設定してエージェントを再起動することもできます。
error_class=Errno::EADDRINUSE error="Address already in use - bind(2) for 0.0.0.0:24231" VM 上で実行される複数の Logging エージェント インスタンスがあります。 ps -aux | grep "/usr/sbin/google-fluentd" を使用して実行中のエージェント プロセスを表示し(表示されるのは、スーパーバイザー 1 つとワーカー 1 つの 2 つのみ)、sudo netstat -nltp | grep :24231 を使用して、ポートを占有する実行中のプロセスを表示します。必要に応じて、古いインスタンスを強制終了します。
Logging agent fails to start due to errors from lib/fluent/config/types.rb(lib/fluent/config/types.rb のエラーにより、Logging エージェントの起動に失敗します) Logging エージェントの構成で、正規表現の構文が不正な正規表現パーサー セクションを使用しているため、部分式呼び出しが無効となり、Starting google-fluentd 1.8.6: /opt/google-fluentd/embedded/lib/ruby/gems/2.6.0/gems/fluentd-1.11.2/lib/fluent/config/types.rb:92: warning: invalid subexp call などのエラーが発生しています。 エージェントの構成ファイルで、不適切な形式の正規表現を見つけて修正します。ヒント: regex または parse を検索します。

ログ スループットの制限

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 以降にアップグレードしてください。

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

エージェントをアンインストールした後、Google Cloud Console がこの変更を報告するまでに最大で 1 時間かかることがあります。