トラブルシューティング

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

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

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

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

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

    Error Reporting API を有効にする。

    API を有効にするために必要なロール

    API を有効にするには、serviceusage.services.enable 権限を含む Service Usage 管理者 IAM ロール(roles/serviceusage.serviceUsageAdmin)が必要です。詳しくは、ロールを付与する方法をご覧ください。

    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 を無効にしました。ただし、[**Error Reporting**] ページ コンソールの Google Cloud エラーイベントが表示されます。

これは想定された挙動です。エラーイベントは、 `report` エンドポイントに対して行われた Error Reporting API 呼び出しに応じて作成されます。reportただし、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_Requiredlogs-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] ページに該当するエラーイベントが表示されません。

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

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