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

[APM] Use the outcome field to calculate the transaction error rate chart #74478

Closed
cauemarcondes opened this issue Aug 6, 2020 · 8 comments · Fixed by #75528
Closed

[APM] Use the outcome field to calculate the transaction error rate chart #74478

cauemarcondes opened this issue Aug 6, 2020 · 8 comments · Fixed by #75528
Assignees
Labels
blocked Team:APM All issues that need APM UI Team support v7.10.0

Comments

@cauemarcondes
Copy link
Contributor

cauemarcondes commented Aug 6, 2020

For 7.10 the agent team are working on a new field called outcome (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?

@cauemarcondes cauemarcondes added [zube]: (7.10) Planned for release Team:APM All issues that need APM UI Team support v7.10.0 labels Aug 6, 2020
@cauemarcondes cauemarcondes self-assigned this Aug 6, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/apm-ui (Team:apm)

@cauemarcondes
Copy link
Contributor Author

Blocked until the agents have implemented the new field.

@felixbarny
Copy link
Member

@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.

@felixbarny
Copy link
Member

I think this issue is unblocked now that we have specified that we'll use event.outcome to determine whether or not an event is a failure.

While testing against real data is important, I don't think it blocks the UI implementation. You could fake the data by setting the event.outcome on existing documents.

@cauemarcondes
Copy link
Contributor Author

@felixbarny can you confirm that I'll need to use both Transaction and Span indices to calculate the error rate since both will have event.outcome?

@felixbarny
Copy link
Member

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.

@cauemarcondes
Copy link
Contributor Author

No, to calculate the error rate you only have to account for the transaction errors.

Cool, thanks for the explanation.

And about the RUM agent (As there's no browser API to get the status code of a page load, the RUM agent always reports "unknown" for those transactions.), should I hide the error rate on its page?

@felixbarny
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blocked Team:APM All issues that need APM UI Team support v7.10.0
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants