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 コンソールのナビゲーション パネルで、[ロギング] を選択してから、[ログ エクスプローラ] を選択します。

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

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

    • Compute Engine VM インスタンスの場合は、VM インスタンスが含まれている Google Cloud プロジェクトを選択します。
    • Amazon EC2 VM インスタンスの場合は、AWS アカウントを Google Cloud サービスにリンクする AWS コネクタ プロジェクトを選択します。

  3. ウィンドウのタブで、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. Google Cloud コンソールのナビゲーション パネルで、[ロギング] を選択してから、[ログ エクスプローラ] を選択します。

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

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

    • Compute Engine VM インスタンスの場合は、VM インスタンスが含まれている Google Cloud プロジェクトを選択します。
    • Amazon EC2 VM インスタンスの場合は、AWS アカウントを Google Cloud サービスにリンクする AWS コネクタ プロジェクトを選択します。

  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 コンソールのナビゲーション パネルで、[Compute Engine] を選択してから、[VM インスタンス] を選択します。

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

  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 エージェントに関連するスコープを示します。

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

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

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

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

  1. Google Cloud コンソールのナビゲーション パネルで、[Compute Engine] を選択してから、[VM インスタンス] を選択します。

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

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

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

    [ID]-compute@developer.gserviceaccount.com

  4. Google Cloud コンソールのナビゲーション パネルで [IAM] を選択します。

    [IAM] に移動

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

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

    • 編集者が表示されている場合、その役割はすべてのエージェントに適切です。編集者は、Compute Engine のサービス アカウントに割り当てられるデフォルトのロールです。
    • ログ書き込みが表示されている場合は、これは 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 プロジェクトが、AWS アカウントのコネクタ プロジェクト（名前は AWS Link...）ではありません。
  • リストされたサービス アカウントが存在しない。削除された可能性があります。
  • 一覧表示されたサービス アカウントのロールが正しく設定されていません: 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

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

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

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

その他の一般的な問題

次の表に、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 インスタンスにインストールする必要があります。 認証情報のインストールについては、Logging エージェントを認可するをご覧ください。
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]
または Logging エージェントを認可するを参照して認証情報を修正または置換してください。
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_eventlog と windows_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 以降にアップグレードします。

ログ内の 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 コンソールで「インストール済み」と報告される

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

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

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