Analytics doesn't show the number of response codes accurately because the first report to authrep is different from following reports.
This is the expected behavior; the first call from an APIcast is authrep’d synchronously, this means there is no post_action to be able to report the very first response code.
However, there are some issues about the behavior
- This behavior makes less sense due to the ephemeral nature of pods in a Kubernetes / OpenShift environment.
- The view shows too detailed number when it is not accurate.
- there is no way for users to notice whether there is a missed count of response or not.
- Since this is the "Analytics" view, inaccurate result is not acceptable.
- APIcast does not send response codes when 3scale auth caching mode is None
How to reproduce this issue:
- Set APICAST_RESPONSE_CODES of a APIcast to true
- Deploy the APIcast
- Configure an API to use the APIcast
- Send a request to the APIcast
Actual result:
- the request was not counted in Analytics - Response codes page
*UPDATE*
2 different approaches to fix this have been discussed
1) Report response codes for every single request, so information shown in analytics would be more accurate --> this would have an impact on performance, but it seems for some companies it would be an acceptable trade off
2) If using Prometheus, scope metrics per service, which is being introduced in 3scale 2.6 https://issues.jboss.org/browse/THREESCALE-2150
UPDATE 2
**Another customer faced this issue for the following use case: API requests are always sent with different Bearer tokens and therefore the response codes are never reported, thus resulting in an empty analytics graph.
- is related to
-
THREESCALE-1540 Document intents and limitations about Response Code Tracking
-
- Closed
-
- relates to
-
THREESCALE-1497 APIcast does not send response codes when 3scale auth caching mode is None
-
- Closed
-
- links to