トラブルシューティング

このドキュメントでは、Error Reporting の一般的なトラブルシューティングのシナリオについて説明します。

Error Reporting API に送信されたエラーイベントが表示されない

Error Reporting API を使用して、エラーイベントを Google Cloud プロジェクトに送信します。ただし、これらのイベントは [Error Reporting] ページには表示されません。

この問題を解決するには、次の操作を行います。

  1. Error Reporting API が有効になっていることを確認します。

    Enable the required API.

    Roles required to enable APIs

    To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

    Enable the API

  2. Cloud Shell を開き、Google Cloud CLI を使用して、エラー イベントをプロジェクトに送信できることを確認します。

    1. 次のコマンドを実行します。

      gcloud beta error-reporting events report --service Manual --service-version test1 \
  --message "java.lang.TestError: msg
    at com.example.TestClass.test(TestClass.java:51)
    at com.example.AnotherClass(AnotherClass.java:25)"

    2. [Error Reporting] ページに移動し、TestError: msg というタイトルのエラーがページに表示されていることを確認します。

      Error Reporting に移動

    3. [ログ エクスプローラ] ページに移動し、ログエントリで TestError を検索します。ログエントリは自動的に作成されます。

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

  3. アプリケーションがエラーイベントを report エンドポイントに送信し、アプリケーションがリクエスト本文を ReportedErrorEvent オブジェクトとしてフォーマットしていることを確認します。ログエントリが作成されていることも確認する必要があります。Error Reporting API を使用すると、適切な形式のエラー メッセージを含むログエントリが自動的に生成され、Cloud Logging に書き込まれます。これらのログエントリは、logName が次のようにフォーマットされたログに書き込まれます。

    projects/PROJECT_ID/clouderrorreporting.googleapis.com%2Freported_errors

エラーイベントが表示されるが、Error Reporting API が無効になっている

Error Reporting API を無効にした。ただし、 Google Cloud コンソールの [エラーレポート] ページにはエラーイベントが表示されています。

これは想定された挙動です。エラーイベントは、report エンドポイントに対して行われた Error Reporting API 呼び出しに応じて作成されます。ただし、Error Reporting がログデータを分析できる場合にも、エラーイベントが推測されます。

エラー イベントがログデータから推測されない

Error Reporting がログデータをスキャンしてエラー イベントを推測することを想定しています。ただし、ログエントリにエラーデータが記録されていても、[Error Reporting] ページにはエラーイベントが表示されません。

この状況を解決するには、次の操作を行います。

  1. Error Reporting がログエントリを分析できることを確認します。

    Error Reporting は Cloud Logging 上に構築されたグローバル サービスであり、次のすべての条件が満たされる場合にログエントリを分析できます。

    • Assured Workloads が無効になっている。詳細については、Assured Workloads の概要をご覧ください。
    • ログエントリを保存するすべてのログバケットで、顧客管理の暗号鍵（CMEK）が無効になっている。Error Reporting は、CMEK が有効になっているログバケットにログエントリを保存できません。ログバケットの CMEK 構成を確認する方法については、鍵の有効化を確認するをご覧ください。
    • ログバケットが次のいずれかの条件を満たしている。
      • ログバケットがログエントリの元のプロジェクトに保存されている。
      • ログエントリがプロジェクトに転送され、そのプロジェクトがそれらのログエントリを、所有するログバケットに保存した。

    構成したシンクのリストを表示するには、次のコマンドを実行します。

    gcloud logging sinks list

    このコマンドでは、次のような出力が返されます。

    NAME               DESTINATION                                                                                                FILTER
_Default           logging.googleapis.com/projects/my-team-project/locations/global/buckets/_Default                          NOT LOG_ID("cloudaudit.googleapis.com/activity") AND NOT LOG_ID("externalaudit.googleapis.com/activity") AND NOT LOG_ID("cloudaudit.googleapis.com/system_event") AND NOT LOG_ID("externalaudit.googleapis.com/system_event") AND NOT LOG_ID("cloudaudit.googleapis.com/access_transparency") AND NOT LOG_ID("externalaudit.googleapis.com/access_transparency")
_Required          logging.googleapis.com/projects/my-team-project/locations/global/buckets/_Required                         LOG_ID("cloudaudit.googleapis.com/activity") OR LOG_ID("externalaudit.googleapis.com/activity") OR LOG_ID("cloudaudit.googleapis.com/system_event") OR LOG_ID("externalaudit.googleapis.com/system_event") OR LOG_ID("cloudaudit.googleapis.com/access_transparency") OR LOG_ID("externalaudit.googleapis.com/access_transparency")
logs-from-samples  logging.googleapis.com/projects/my-team-project/locations/global/buckets/sample-bucket                     (empty filter)
regional_logs      logging.googleapis.com/projects/my-team-project/locations/europe-west1/buckets/bucket_for_regional_logs    (empty filter)
test-logs          logging.googleapis.com/projects/team-b-project/locations/global/buckets/test-bucket                        (empty filter)

    この例では、ログエントリのソース Google Cloud プロジェクトは my-team-project です。結果として次のようになります。

    • Error Reporting は、ログエントリをルーティングするプロジェクトと同じプロジェクトによってログバケットが保存されるため、_Default、_Required、logs-from-samples の各シンクによってルーティングされるログエントリを分析できます。
    • my-team-project のシンクはログエントリを別のプロジェクトのログバケットにルーティングするため、Error Reporting は test-logs という名前のログバケットに保存されているログエントリを分析できません。

  2. Google Cloud CLI を使用して、エラー イベントを生成するログエントリを書き込めることを確認します。

    1. 次のコマンドを実行します。

      gcloud logging write --payload-type=json test-errors-log \
  '{"serviceContext":
    {"service": "manual-testing"},
    "message": "Test Error\n at /test.js:42:42",
    "context": {"httpRequest":
      {"url": "/test","method": "GET","responseStatusCode": 500}}}'

    2. [ログ エクスプローラ] ページに移動し、ログエントリで Test Error を検索します。

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

      このログエントリは gcloud CLI によって生成されます。ログエントリがエラー グループに関連付けられていない場合は、1 分ほど待ってからページを更新します。エラー イベントは、ログエントリが取り込まれた後に検出されます。

    3. [Error Reporting] ページに移動し、Test Error というタイトルのエラーが表示されていることを確認します。

      Error Reporting に移動

  3. ログ エクスプローラ ページに移動し、アプリケーションが正しい形式のログエントリを書き込んでいることを確認します。

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

    ご使用のアプリケーションから送信された例外データを含むログエントリを見つけ、形式を確認します。形式が正しくない場合は、アプリケーションを更新します。

ログエントリにスタック トレースが含まれているが、エラー イベントが作成されない

message フィールドにスタック トレースを含むログエントリを生成します。ただし、Error Reporting ページには対応するエラーイベントが表示されません。

この問題を解決するには、次のことを試してください。

  • jsonPayload に stack_trace フィールドまたは exception フィールドが含まれていないことを確認します。これらのフィールドが存在する場合、message フィールドは評価されません。

  • スタック トレースの構造が、サポートされているプログラミング言語形式のいずれかであることを確認します。サポートされていない形式が使用されている場合、スタック トレースは Error Reporting によってキャプチャされません。

詳細については、エラー イベントを報告するようにログエントリをフォーマットするをご覧ください。