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 認証情報を確認するをご覧ください。
エージェントが承認に失敗した場合は、秘密鍵の認証情報が欠落しているか無効かどうかを確認します。

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

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

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

検索バーを使用してこのページを検索する場合は、小見出しが「Logging」の結果を選択します。
ページの上部で、VM インスタンスが含まれているプロジェクトを選択します。
- Compute Engine VM インスタンスの場合は、VM インスタンスが含まれている Google Cloud プロジェクトを選択します。
- Amazon EC2 VM インスタンスの場合は、AWS アカウントを Google Cloud サービスにリンクする AWS コネクタプロジェクトを選択します。
ウィンドウのタブで、VM インスタンスのリソースを選択します。
- Compute Engine の場合は、[GCE VM インスタンス] を選択します。
- Amazon EC2 の場合は、[AWS EC2 インスタンス] を選択します。
- [syslog]（Linux）、[syslog]（Windows）、または [syslog] を選択します。

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

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

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

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

Linux インスタンス

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

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 [...]

VM インスタンスで次のコマンドを実行して、テストログメッセージを送信します。
```
logger "Some test message"
```

Windows インスタンス

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

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

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

両方のサービスのステータスを確認します。実行する必要があるサービスがわかっている場合は、そのサービス名を使用できます。
```
Get-Service StackdriverLogging,fluentdwinsvc
```
サービスが実行されていない場合は、エラーメッセージが表示されます。実行中の場合は、次のような出力が表示されます。
```
Status    Name                DisplayName
------    ----                -----------
Running  StackdriverLogging   Cloud Logging
```
両方のサービスにクエリを送信すると、次の 1 つのエラーメッセージと 1 つの Running ステータスが表示されます。
- Running ステータスが表示されない場合、Logging エージェントは実行されていません。
- StackdriverLogging が実行中であることが表示された場合は、最新のエージェントバージョンが実行されています。具体的なバージョンを確認するには、バージョンを取得するをご覧ください。
- fluentdwinsvc が実行中であることが表示された場合は、最新バージョンにエージェントをアップグレードする必要があります。
管理者権限が必要: いずれかのエージェントバージョンが実行されている場合は、次の PowerShell コマンドを実行してテストログメッセージを送信します。
```
New-EventLog   -LogName Application -Source "Test Source"
Write-EventLog -LogName Application -Source "Test Source" -EntryType Information -EventID 1 -Message "Testing 123 Testing."
```

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

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

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

検索バーを使用してこのページを検索する場合は、小見出しが「Logging」の結果を選択します。
ページの上部で、VM インスタンスが含まれているプロジェクトを選択します。
- Compute Engine VM インスタンスの場合は、VM インスタンスが含まれている Google Cloud プロジェクトを選択します。
- Amazon EC2 VM インスタンスの場合は、AWS アカウントを Google Cloud サービスにリンクする AWS コネクタプロジェクトを選択します。
ウィンドウのタブで、VM インスタンスのリソースを選択します。
- Compute Engine の場合は、[GCE VM インスタンス] を選択します。
- Amazon EC2 の場合は、[AWS EC2 インスタンス] を選択します。
- [syslog]（Linux）、[syslog]（Windows）、または [syslog] を選択します。
テストメッセージを含むログエントリがあります。その場合、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 サービスアカウントを削除して、再度追加します。

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

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

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

検索バーを使用してこのページを検索する場合は、小見出しが [Compute Engine] の結果を選択します。
VM インスタンスの名前をクリックします。インスタンスの詳細ページが表示されます。
[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 権限を提供しない場合があります。

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

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

検索バーを使用してこのページを検索する場合は、小見出しが [Compute Engine] の結果を選択します。
VM インスタンスの名前をクリックします。インスタンスの詳細ページが表示されます。
ページで [サービスアカウント] という見出しを探します。インスタンスのデフォルトのサービスアカウントが表示されます。次のようになります。
```
[ID]-compute@developer.gserviceaccount.com
```
Google Cloud コンソールの [IAM] ページに移動します。
[IAM] に移動

検索バーを使用してこのページを検索する場合は、小見出しが [IAM と管理者] である結果を選択します。
[プリンシパル別に表示] を選択します。ユーザー、グループ、サービスアカウントの一覧が表示されます。[Role] 列に、プロジェクトの各メンバーのロールが表示されます。
インスタンスのデフォルトサービスアカウントの行に、1 つ以上の役割が表示されます。
- 編集者が表示されている場合、その役割はすべてのエージェントに適切です。組織のポリシーの構成によっては、デフォルトのサービスアカウントに編集者のロールが自動的に付与される場合があります。
- ログ書き込みが表示されている場合は、これは Logging エージェントに十分なロールです。書き込み権限を含む他の Logging ロールについては、Cloud Logging のアクセス制御をご覧ください。
- モニタリング指標の書き込みが表示されている場合、これは Monitoring エージェントに十分な役割です。書き込み権限を含む他のモニタリングロールについては、Cloud Monitoring のアクセス制御をご覧ください。

問題を是正する

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

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

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

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

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

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

Linux

/etc/google/auth/application_default_credentials.json

Windows

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

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

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

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

有効な秘密鍵認証情報が 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 プロジェクトであり、project_id はプロジェクト内のサービスアカウント、project_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

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

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

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

問題が認証情報に関連していない場合は、スキップして、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 インスタンスに必要な権限が誰かに取り消された場合などです。

エラー	原因	解決方法
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 インスタンスにインストールする必要があります。	認証情報のインストールについては、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 Console で「インストール済み」と報告される

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

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

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

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

チェックリスト

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

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

Linux インスタンス

Windows インスタンス

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

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

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

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

問題を是正する

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

問題を是正する

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

Linux

Windows

認証情報は存在するか

認証情報は有効か

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

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

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

その他の一般的な問題

ログ スループットの制限

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

ログが重複しています

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

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

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

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

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

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

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

ログスループットの制限

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

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