From 9b2707af611d324052caebc0cdce3d987d9eaacc Mon Sep 17 00:00:00 2001 From: Jade Guiton Date: Wed, 18 Dec 2024 15:10:46 +0100 Subject: [PATCH 1/3] Updated Pipeline Instrumentation RFC to add a "rejected" outcome --- docs/rfcs/component-universal-telemetry.md | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/docs/rfcs/component-universal-telemetry.md b/docs/rfcs/component-universal-telemetry.md index 4a721fbad1b..5f5b661d4b1 100644 --- a/docs/rfcs/component-universal-telemetry.md +++ b/docs/rfcs/component-universal-telemetry.md @@ -90,11 +90,20 @@ The location of these measurements can be described in terms of whether the data component to which the telemetry is attributed. Metrics which contain the term "produced" describe data which is emitted from the component, while metrics which contain the term "consumed" describe data which is received by the component. -For both metrics, an `outcome` attribute with possible values `success` and `failure` should be automatically recorded, corresponding to -whether or not the corresponding function call returned an error. Specifically, consumed measurements will be recorded with `outcome` as -`failure` when a call from the previous component the `ConsumeX` function returns an error, and `success` otherwise. Likewise, produced -measurements will be recorded with `outcome` as `failure` when a call to the next consumer's `ConsumeX` function returns an error, and -`success` otherwise. +For both metrics, an `outcome` attribute with possible values `success`, `failure`, and `rejected` should be automatically recorded, +corresponding to whether or not the corresponding function call returned an error, and whether the error originates from the next +component(s) in the pipeline, or from one further downstream. + +Specifically, a call to `ConsumeX` is recorded with: +- `outcome = success` if the call returns `nil`; +- `outcome = failure` if the call returns a regular error; +- `outcome = rejected` if the call returns an error tagged as coming from downstream. +After inspecting the error, the instrumentation layer should tag it as coming from downstream before returning it to the parent component. + +The upstream component which called `ConsumeX` will have this `outcome` attribute applied to its produced measurements, and the downstream +component that `ConsumeX` was called on will have the attribute applied to its consumed measurements. + +Errors should be "tagged as coming from downstream" the same way permanent errors are currently handled: they can be wrapped in a `type downstreamError struct { err error }` wrapper error type, then checked with `errors.As`. Note that care may need to be taken when dealing with the `multiError`s returned by the `fanoutconsumer`. (If PR #11085 introducing a single generic `Error` type is merged, an additional `downstream bool` field can be added to it to serve the same purpose.) ```yaml otelcol.receiver.produced.items: From a3b3bb9869486b532c7ad4a1e8b654c71b9a8b49 Mon Sep 17 00:00:00 2001 From: Jade Guiton Date: Wed, 8 Jan 2025 16:30:00 +0100 Subject: [PATCH 2/3] Simplified wording --- docs/rfcs/component-universal-telemetry.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/rfcs/component-universal-telemetry.md b/docs/rfcs/component-universal-telemetry.md index 5f5b661d4b1..a2cc5b62c4b 100644 --- a/docs/rfcs/component-universal-telemetry.md +++ b/docs/rfcs/component-universal-telemetry.md @@ -91,8 +91,8 @@ component to which the telemetry is attributed. Metrics which contain the term " while metrics which contain the term "consumed" describe data which is received by the component. For both metrics, an `outcome` attribute with possible values `success`, `failure`, and `rejected` should be automatically recorded, -corresponding to whether or not the corresponding function call returned an error, and whether the error originates from the next -component(s) in the pipeline, or from one further downstream. +based on whether the corresponding function call returned successfully, returned an internal error, or propagated an error from a +component further downstream. Specifically, a call to `ConsumeX` is recorded with: - `outcome = success` if the call returns `nil`; From 98db301ae9d33ecd10aa800e0fa9474aa3f0e80b Mon Sep 17 00:00:00 2001 From: Jade Guiton Date: Mon, 20 Jan 2025 14:33:17 +0100 Subject: [PATCH 3/3] Changed `rejected` to `refused` + minor wording change --- docs/rfcs/component-universal-telemetry.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/rfcs/component-universal-telemetry.md b/docs/rfcs/component-universal-telemetry.md index a2cc5b62c4b..cc4993a4efe 100644 --- a/docs/rfcs/component-universal-telemetry.md +++ b/docs/rfcs/component-universal-telemetry.md @@ -90,20 +90,20 @@ The location of these measurements can be described in terms of whether the data component to which the telemetry is attributed. Metrics which contain the term "produced" describe data which is emitted from the component, while metrics which contain the term "consumed" describe data which is received by the component. -For both metrics, an `outcome` attribute with possible values `success`, `failure`, and `rejected` should be automatically recorded, +For both metrics, an `outcome` attribute with possible values `success`, `failure`, and `refused` should be automatically recorded, based on whether the corresponding function call returned successfully, returned an internal error, or propagated an error from a component further downstream. Specifically, a call to `ConsumeX` is recorded with: - `outcome = success` if the call returns `nil`; - `outcome = failure` if the call returns a regular error; -- `outcome = rejected` if the call returns an error tagged as coming from downstream. +- `outcome = refused` if the call returns an error tagged as coming from downstream. After inspecting the error, the instrumentation layer should tag it as coming from downstream before returning it to the parent component. The upstream component which called `ConsumeX` will have this `outcome` attribute applied to its produced measurements, and the downstream component that `ConsumeX` was called on will have the attribute applied to its consumed measurements. -Errors should be "tagged as coming from downstream" the same way permanent errors are currently handled: they can be wrapped in a `type downstreamError struct { err error }` wrapper error type, then checked with `errors.As`. Note that care may need to be taken when dealing with the `multiError`s returned by the `fanoutconsumer`. (If PR #11085 introducing a single generic `Error` type is merged, an additional `downstream bool` field can be added to it to serve the same purpose.) +Errors should be "tagged as coming from downstream" the same way permanent errors are currently handled: they can be wrapped in a `type downstreamError struct { err error }` wrapper error type, then checked with `errors.As`. Note that care may need to be taken when dealing with the `multiError`s returned by the `fanoutconsumer`. If PR #11085 introducing a single generic `Error` type is merged, an additional `downstream bool` field can be added to it to serve the same purpose instead. ```yaml otelcol.receiver.produced.items: