Add request failed metric #881
Merged
Conversation
This file contains 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
ankur22
force-pushed
the
fix/1261-failed-request-metric
branch
2 times, most recently
from
94d450c
to
e124756
Compare
ankur22
force-pushed
the
fix/1261-failed-request-metric
branch
from
01d0210
to
015ee2e
Compare
dgzlopes
approved these changes
May 25, 2023
This metric is predefined in k6. When a request completes we want to measure how many of these failed. This is based on the status code of the response. If the code is outside of the 200-399 range, it is deemed to have failed. The default status code range was taken from k6. The opposite is also possible to determine, we can work out which requests succeeded since the value of the metric will be 0.
This commit helps us move away from the k6 http_req_failed metric to a browser prefixed one. It is custom to the browser module allowing the user to measure k6 vs browser http_req_failed metrics separately.
Co-authored-by: ka3de <daniel.jimenez@grafana.com>
ankur22
force-pushed
the
fix/1261-failed-request-metric
branch
from
6221bb9
to
ae0319a
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Description of changes
When a request completes we want to measure how many of these failed. This is based on the status code of the response. If the code is outside of the 200-399 range, it is deemed to have failed. The default status code range was taken from k6.
The opposite is also possible to determine, we can work out which requests succeeded since the value of the metric will be 0.
We're using a custom metric named
browser_http_req_failed, instead of the builtin k6http_req_failed. There was a concern that if the browser module worked with the builtin k6 metric, then the results would be skewed for both modules and therefore meaningless. This is due to the fact that the implementation of http could differ. Users are also likely to want to understand their API http failures differently to their browser level http failures.The shape of the data is free to be moulded the best way that works for the browser module use case. I tested to see whether the cache values varied, which they did, so I've left them in. We can adjust the metrics and labels as we see fit once we have a better idea of what users require.
Testing
To test this change, influxdb will need to installed or another suitable backend time series database. Once installed, run a test that you know will navigate to a website which has failing dependencies (e.g. an image that doesn't load). You should see something like this in the
http_req_failedtable:You should also see metric in the end summary: