Change Details

### Description Because we are working with Enterprise, we have higher expectations for performance and response rates. Because of this, we need the ability to quickly identify and resolve bottle necks within the overall calculation flow to ensure we stay within their defined SLOs. ### Conditions of acceptance [] On the median response latency, add an indicator for a 400ms limit so that we can see if the average is trending towards our hard limit. [] Track the # of requests that exceed the 400ms limit, including both logging the specific requests and a graphana graph [] Implement tracking for subcalls, so that we can identify latency bottlenecks within the call structure. [] Implement timing metrics (in lieu of open telemetry) for every round trip we perform in our system

### Description Because we are working with Enterprise, we have higher expectations for performance and response rates. Because of this, we need the ability to quickly identify and resolve bottle necks within the overall calculation flow to ensure we stay within their defined SLOs. Currently, they commit to delivering a response within 500ms to their customers. We must ensure that we are comfortably below that limit so that Attribution API response values can be pulled and included in the Enterprise structured responses. This monitoring will also help quantify general risk to Wikimedia projects, as we will know where bottlenecks may affect production performance. ### Conditions of acceptance [] On the median response latency, add an indicator for a 400ms limit so that we can see if the average is trending towards our hard limit. [] Track the # of requests that exceed the 400ms limit, including both logging the specific requests and a graphana graph [] Implement tracking for subcalls, so that we can identify latency bottlenecks within the call structure. [] Implement timing metrics (in lieu of open telemetry) for every round trip we perform in our system

### Description Because we are working with Enterprise, we have higher expectations for performance and response rates. Because of this, we need the ability to quickly identify and resolve bottle necks within the overall calculation flow to ensure we stay within their defined SLOs. Currently, they commit to delivering a response within 500ms to their customers. We must ensure that we are comfortably below that limit so that Attribution API response values can be pulled and included in the Enterprise structured responses. This monitoring will also help quantify general risk to Wikimedia projects, as we will know where bottlenecks may affect production performance. ### Conditions of acceptance [] On the median response latency, add an indicator for a 400ms limit so that we can see if the average is trending towards our hard limit. [] Track the # of requests that exceed the 400ms limit, including both logging the specific requests and a graphana graph [] Implement tracking for subcalls, so that we can identify latency bottlenecks within the call structure. [] Implement timing metrics (in lieu of open telemetry) for every round trip we perform in our system