-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[APM] Use the outcome field to calculate the transaction error rate chart #74478
Comments
Pinging @elastic/apm-ui (Team:apm) |
Blocked until the agents have implemented the new field. |
@beniwohli is working on the reference implementation for elastic/apm#299 @cauemarcondes and @beniwohli please sync up to ensure we have a smooth end-to-end experience. |
I think this issue is unblocked now that we have specified that we'll use While testing against real data is important, I don't think it blocks the UI implementation. You could fake the data by setting the |
@felixbarny can you confirm that I'll need to use both |
No, to calculate the error rate you only have to account for the transaction errors. The reason is that a transaction can be successful in spite of having an erroneous span. For example, if an API call failed but the server successfully retried or used a fallback. |
Cool, thanks for the explanation. And about the RUM agent ( |
That’s only true for pageload transactions, not Ajax calls. So I wouldn’t hide it. Plus, users may use the API to even mark a pageload transaction as failed. |
For
7.10
the agent team are working on a new field calledoutcome
(elastic/apm#299) which will be available on the Transaction and Span indices. The field represents a success or a failure transaction or span.Possible results:
"failure"
: Indicates that this transaction describes a failed result"success"
: Indicates that this transaction describes a successful result."unknown"
: Indicates that there's no information about the outcome. (Won't be counted as error)Solution
total_number_of_transactions_with_errors / total_number_of_transactions
Fallback:
Should we consider keep the current implementation as a fallback in case of the field is not available?
The text was updated successfully, but these errors were encountered: