Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should the stage tag for component_errors_total be removed? #17538

Open
tobz opened this issue May 30, 2023 · 0 comments
Open

Should the stage tag for component_errors_total be removed? #17538

tobz opened this issue May 30, 2023 · 0 comments
Labels
domain: observability Anything related to monitoring/observing Vector source: internal_metrics Anything `internal_metrics` source related type: tech debt A code change that does not add user value.

Comments

@tobz
Copy link
Contributor

tobz commented May 30, 2023

Context

During some internal discussion around the purpose of stage tag for error events, the question came up around whether or not that tag should be removed entirely.

The error event already dictates specifying an error_type tag, which, in practice, is already fairly descriptive: out_of_order, acknowledgement_failed, invalid_metric, and so on. The stage tag is ostensibly meant to indicate where in the component the error occurred -- receiving, processing, and sending mapping roughly to a component getting events in, processing them as necessary, and then sending those events out -- but in general, the specificity of error_type can generally inform what stage the error occurred in.

Even further, the stage tag generally doesn't actually facet the metrics, which is to say, during a cursory search, I could not find an example where the same error_type is emitted in a component but at multiple, distinct stages. We're specifying and emitting stage seemingly for no actual benefit to breaking down the error metric any further than the error_type.

Question / Proposal

Should we simply drop the stage tag from the specification for component errors? This would greatly simplify the emission of those events in the codebase, and remove an unnecessary additional tag that otherwise pollutes the tag set for internal metrics.

@tobz tobz added domain: observability Anything related to monitoring/observing Vector source: internal_metrics Anything `internal_metrics` source related labels May 30, 2023
@jszwedko jszwedko added the type: tech debt A code change that does not add user value. label Jun 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
domain: observability Anything related to monitoring/observing Vector source: internal_metrics Anything `internal_metrics` source related type: tech debt A code change that does not add user value.
Projects
None yet
Development

No branches or pull requests

2 participants