From 3abd22bef808d3fcf40ed1c387e706a24b81bc41 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Juan=20=C3=81lvarez?= Date: Tue, 8 Sep 2020 11:14:53 +0200 Subject: [PATCH 1/2] Update outcome spec --- specs/agents/tracing-spans.md | 2 ++ specs/agents/tracing-transactions.md | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/specs/agents/tracing-spans.md b/specs/agents/tracing-spans.md index 66a0dc76..1ffca84d 100644 --- a/specs/agents/tracing-spans.md +++ b/specs/agents/tracing-spans.md @@ -10,6 +10,8 @@ The only semantic difference is that client errors set the `outcome` to `"failur Agents should try to determine the outcome for spans created by auto instrumentation, which is especially important for exit spans (spans representing requests to other services). +If an agent doesn't report the `outcome` (or reports `null`), the APM Server will set it based on `http.response.status_code`. If the status code is not available, then it will be set to `"unknown"`. + While the transaction outcome lets you reason about the error rate from the service's point of view, other services might have a different perspective on that. For example, if there's a network error so that service A can't call service B, diff --git a/specs/agents/tracing-transactions.md b/specs/agents/tracing-transactions.md index 53e16222..e9cf7f30 100644 --- a/specs/agents/tracing-transactions.md +++ b/specs/agents/tracing-transactions.md @@ -11,7 +11,7 @@ Transactions are created either by the built-in auto-instrumentation or an agent The `outcome` property denotes whether the transaction represents a success or a failure from the perspective of the entity that produced the event. The APM Server converts this to the [`event.outcome`](https://www.elastic.co/guide/en/ecs/current/ecs-allowed-values-event-outcome.html) field. This property is optional to preserve backwards compatibility. -If an agent doesn't report the `outcome` (or reports `null`), the APM Server sets the outcome to `"unknown"`. +If an agent doesn't report the `outcome` (or reports `null`), the APM Server will set it based on `context.http.response.status_code`. If the status code is not available, then it will be set to `"unknown"`. - `"failure"`: Indicates that this transaction describes a failed result. \ Note that client errors (such as HTTP 4xx) don't fall into this category as they are not an error from the perspective of the server. From 4841864de9a304e5fe65bb06941b80f40fc99563 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Juan=20=C3=81lvarez?= Date: Wed, 9 Sep 2020 08:12:54 +0200 Subject: [PATCH 2/2] Update specs/agents/tracing-spans.md Co-authored-by: Andrew Wilkins --- specs/agents/tracing-spans.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specs/agents/tracing-spans.md b/specs/agents/tracing-spans.md index 1ffca84d..2028fb9d 100644 --- a/specs/agents/tracing-spans.md +++ b/specs/agents/tracing-spans.md @@ -10,7 +10,7 @@ The only semantic difference is that client errors set the `outcome` to `"failur Agents should try to determine the outcome for spans created by auto instrumentation, which is especially important for exit spans (spans representing requests to other services). -If an agent doesn't report the `outcome` (or reports `null`), the APM Server will set it based on `http.response.status_code`. If the status code is not available, then it will be set to `"unknown"`. +If an agent doesn't report the `outcome` (or reports `null`), the APM Server will set it based on `context.response.status_code`. If the status code is not available, then it will be set to `"unknown"`. While the transaction outcome lets you reason about the error rate from the service's point of view, other services might have a different perspective on that.