Splunk APMでエラースパンを分析する 🔗
Splunk APMのエラー検出機能を使用して、システムやアプリケーションの具体的なエラー原因を特定できます。
How Splunk APM detects error spans 🔗
Each span in Splunk APM captures a single operation. Splunk APM considers a span to be an error span if the operation that the span captures results in an error as defined by the following conditions:
スパンの
otel.status_codeフィールドがERRORである場合。otel.status_codeは、Splunk Distribution of the OpenTelemetryのインストルメンテーションで、ネイティブのOTel フィールドspan.statusを使って設定されます。span.statusと、それにしたがってotel.status_codeは、HTTPステータスコードまたはgRPCステータスコードに基づいて設定されます。See OpenTelemetryによるHTTPステータスコードの処理方法 to learn which status code values set
otel.status_codetoERRORin the OpenTelemetry instrumentation.OpenTelemetryのインストルメンテーションでどの
rpc.grpc.status_codeタグ値がotel.status_codeをERRORと設定するかについては、OpenTelemetryによるgRPCステータスコードの処理方法 を参照してください。
スパンの
errorタグが真値（Falseまたは0以外の値）に設定されている場合。
otel.status_code の詳細は、GitHubの「OpenTelemetryの非OTLP形式への変換」の仕様の「スパンステータス」セクション（ https://opentelemetry.io/docs/specs/otel/common/mapping-to-non-otlp/#span-status ）を参照してください。span.status の詳細は、GitHubの「OpenTelemetryのトレースAPI仕様」の「ステータスの設定」セクション（ https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/trace/api.md#set-status ）を参照してください。
OpenTelemetryによるHTTPステータスコードの処理方法 🔗
The following table provides an overview of how HTTP status codes are used to set the span.status field, and subsequently otel.status_code, in OpenTelemetry instrumentation in accordance with OpenTelemetry semantic conventions. To learn more, see the OpenTelemetry semantic conventions for HTTP spans on GitHub https://github.com/open-telemetry/semantic-conventions/blob/main/model/http/spans.yaml.
エラータイプ |
サーバー側のスパン |
クライアント側のスパン |
|---|---|---|
|
スパンに別のエラーがない限り、 |
スパンに別のエラーがない限り、 |
|
サーバー側のエラーとはみなされない。 |
クライアントのエラーとしてカウント。 |
|
|
|
OpenTelemetryによるgRPCステータスコードの処理方法 🔗
gRPCスパンがサービスのエラー率にカウントされるかどうかを判断するために、Splunk APMはOpenTelemetryのインストルメンテーションによって設定された otel.status_code フィールドを調べます。以下のロジックが、OpenTelemetryのセマンティック規約に従ってインストルメンテーションにより適用されます：
コード |
ステータス |
サーバー側のスパン |
クライアント側のスパン |
|---|---|---|---|
0 |
OK |
未設定 |
未設定 |
1 |
CANCELLED |
未設定 |
エラー |
2 |
UNKNOWN |
エラー |
エラー |
3 |
INVALID_ARGUMENT |
未設定 |
エラー |
4 |
DEADLINE_EXCEEDED |
エラー |
エラー |
5 |
NOT_FOUND |
未設定 |
エラー |
6 |
ALREADY_EXISTS |
未設定 |
エラー |
7 |
PERMISSION_DENIED |
未設定 |
エラー |
8 |
RESOURCE_EXHAUSTED |
未設定 |
エラー |
9 |
FAILED_PRECONDITION |
未設定 |
エラー |
10 |
ABORTED |
未設定 |
エラー |
11 |
OUT_OF_RANGE |
未設定 |
エラー |
12 |
UNIMPLEMENTED |
エラー |
エラー |
13 |
INTERNAL |
エラー |
エラー |
14 |
UNAVAILABLE |
エラー |
エラー |
15 |
DATA_LOSS |
エラー |
エラー |
16 |
UNAUTHENTICATED |
未設定 |
エラー |
See the OpenTelemetry specification for information on the handling of gRPC status codes on GitHub https://github.com/open-telemetry/semantic-conventions/blob/main/model/rpc/spans.yaml.
MetricSetでのエラースパンのカウント方法 🔗
エンドポイントレベルのMonitoring MetricSetsを生成するために、Splunk APMはエンドポイントスパン（ span.kind = SERVER または span.kind = CONSUMER のスパン）をエラーメトリクスデータに変換します。スパンがSplunk APMのエラールールによってエラーとみなされた場合、そのスパンは、そのスパンに関連するエンドポイントのMonitoring MetricSetのエラーとしてカウントされます。
サービスレベルのMonitoring MetricSetsは、サービスの各エンドポイントのエラースパンの数に基づいています。
サーバー側とクライアント側のエラーカウント 🔗
Splunk APMは、クライアント側のスパンと呼ばれるクライアントへのリクエストをキャプチャするスパンや、サーバー側のスパンと呼ばれるサービスが受信したリクエストなど、インストルメントされたすべてのサービスからのすべてのスパンをキャプチャします。特定のケースでは、サービスがエラーを返すと、開始スパンと受信スパンの両方にエラーが登録されることがあります。エラーレポートの重複を避けるため、Splunk APMはサーバー側のエラースパンのみをMetricSetsとエラー合計にカウントします。
たとえば、service_a が service_b にコールし、両方のサービスが完全にインストルメントされている場合、Splunk APMは以下の2つのスパンを受信します：
span_1。service_bへのコールを行うservice_aをキャプチャするspan.kind = CLIENTのスパン。span_2。リクエストを受信するservice_bをキャプチャするspan.kind = SERVERのスパン。
service_b が 500 エラーを返した場合、両方のスパンがそのエラーを受信します。エラーの二重カウントを避けるため、Splunk APMはサーバー側のスパン（ span_2 ）のみをMetricSetsおよびエラー合計にエラーとしてカウントします。
エラーと根本原因エラーの違い 🔗
エラーの根本原因を特定するために、Splunk APMはエラーと根本原因エラーを区別します。たとえば、Tag Spotlightのリクエストとエラーのグラフでは、濃い色を付けてエラー合計から根本原因エラーを区別します：
トレース内の特定のスパンでエラーが発生した場合、そのエラーはトレース内の他のスパンに伝搬する可能性があります。How Splunk APM detects error spans に記載されている基準に基づいてエラーを含むと判断されたスパンは、すべてエラースパンとなります。Splunk APMは、エラースパンの連鎖の起点となるエラーを 根本原因エラー として指定します。
例えば、次のスクリーンショットでcheckoutのトレースについて考えてみましょう：
checkout サービスは、authorization サービス、 checkout サービス、および payment サービスにHTTPリクエストを行っています。 payment サービスへのHTTPリクエストの結果、402 「Payment Required」というエラーが発生しています。 payment サービスへのリクエストが失敗したため、 checkout サービスへの開始リクエストと http.Request もエラーになります。
この場合、ソースエラー、つまり根本原因エラーは、payment サービス内の 402 エラーです。checkout および api のサービスに現れる 500 のエラーは、その結果として生じたエラーです。
根本原因エラーカウントは、これらの根本原因エラーのカウントを示し、標準のエラーカウントは、すべての根本原因エラーおよび後続エラーの合計カウントを示します。
Splunk APMでエラーロジックをカスタマイズする 🔗
一部のケースでは、エラーロジックのデフォルトをオーバーライドするようにインストルメンテーションを変更したり、自分にとって重要なエラーを追跡するための別の方法を考案したりする方が良い場合もあります。
4xxステータスコードをエラーとしてカウントする 🔗
デフォルトでは、Splunk APMは、4xx ステータスコードを持つサーバー側のスパンをエラーとしてカウントしません。4xx ステータスコードは、リクエストを処理するサービスの問題に関連するというよりも、リクエスト自体の問題に関連する場合が多いからです。
For example, if a user makes a request to endpoint/that/does/not/exist, the 404 status code the service returns does not mean there’s a problem with the service. Instead, it means there was a problem with the request, which is trying to call an endpoint that doesn’t exist. Similarly, if a user tries to access a resource they don’t have access to, the service might return a 401 status code, which is typically not the result of an error on the server side.
However, depending on your application’s logic, a 4xx status code might represent a meaningful error, particularly for client-side requests. To monitor for 4xx errors, try doing the following:
利用可能な場合は、HTTPステータスコードのスパンタグごとにパフォーマンスを分析する。
インストルメンテーションをカスタマイズして、意味のある
4xxステータスコードを持つスパンのspan.statusをErrorに設定する。
例えば、Kaiがあるサービスから返される 401 エラーの割合についてアラートを出したい場合は、次の手順を実行します：
Index
http.status_codein libraries that support OpenTelemetry semantic conventions version 1.16.0 or lower. Or indexhttp.response.status_codein libraries that support OpenTelemetry semantic conventions version 1.17.0 or higher. See Index span tags to create Troubleshooting MetricSets.Create a custom Monitoring MetricSet on the status code tag for the service’s endpoints to get a time series for each status code. See Create a Monitoring MetricSet with a custom dimension.
全リクエスト数と比較した
401のエラー率に関するアラートを設定する。Splunk APMでディテクターとアラートを設定する を参照してください。
エラーロジックをカスタマイズして5xxステータスコードを破棄する 🔗
デフォルトでは、Splunk APMは 5xx のステータスコードを持つサーバー側のスパンをエラーとしてカウントします。 5xx のエラーは一般的にサービスの利用不可の状況に関連するためです。
例えば、サーバー側のスパンにおける 503 「service too busy」のエラーは、デフォルトでエラーとしてカウントされます。監視しているサービスが公開ウェブサイトのフロントエンドである場合、 503 のエラーに遭遇したユーザーはウェブサイトを利用することができず、ユーザーインタラクションの損失や収益の損失につながります。この場合、 503 は真のエラーです。
しかし、アプリケーションのロジックによっては、5xx コードを意味のあるエラーと考えない可能性もあります。例えば、サービスがバッチプロセッサーである場合、503 のエラーは正常なフロー制御メカニズムで、後でのクライアントによるプロセスの再試行をトリガーするものである可能性があります。503 ステータスコードをエラーとしてカウントするデフォルト設定をオーバーライドするには、503 エラーが問題にならないスパンでは span.status を OK に設定するようにインストルメンテーションを修正することができます。