Include occurrence in error telemetry events#173
Open
gaggle wants to merge 3 commits intoelixir-error-tracker:mainfrom
Open
Include occurrence in error telemetry events#173gaggle wants to merge 3 commits intoelixir-error-tracker:mainfrom
gaggle wants to merge 3 commits intoelixir-error-tracker:mainfrom
Conversation
The :new error event now carries the occurrence in its metadata so consumers can inspect context (e.g. to distinguish genuinely new errors from noise) without a separate database query.
When a previously-resolved error re-occurs, the :unresolved event now carries the triggering occurrence so consumers can inspect its context (e.g. to decide whether to re-alert). Manual unresolves (via the UI) emit occurrence: nil since there is no new occurrence involved.
Reflect that :new and :unresolved error events now include the occurrence in their metadata, and document the nullable semantics for manual unresolves.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hi @crbelaus,
We're a team that uses ErrorTracker, and we rely on its telemetry events to drive our alerting.
First off, thank you for building and maintaining this library, it's been great to use and work with!
We ran into a situation where the
:newand:unresolvederror events didn't carry enough information for us to make good alerting decisions. Specifically, we want to tell whether an error is genuinely new vs arepeat, and when a previously-resolved error comes back we want to use alert routing based on the the occurrence's
context.The
[:error_tracker, :occurrence, :new]event does carry the occurrence, but it fires for every occurrence regardless of whether the error is new, returning, or already known. So it wasn't the right signal for our use case.We've been running a fork with these changes for a while and it's worked well for us. We wanted to offer this upstream in case you find the direction acceptable. We're happy to adjust the approach if you'd prefer
a different shape or semantics, please consider this a humble proposal rather than a prescription.
Changes
The
:newand:unresolvederror telemetry events now include the:occurrencein their metadata::newevents carry the first occurrence, so consumers can inspect its context immediately.:unresolvedevents (previously-resolved error re-occurs) carry the triggering occurrence.:unresolvedevents (manual unresolve via UI) carryoccurrence: nilsince no new occurrence is involved.The
:resolvedevent is unchanged (no occurrence is relevant there).Test plan
:occurrencein:newevent metadata.occurrence: nilfor manual unresolves.--warnings-as-errors