Citizens report slow permit lookups through API Gateway in front of an Oracle Function. Which metric pair best separates gateway overhead from time spent in the Function backend?
Select an answer to reveal the explanation.
Short Explanation
Gateway Latency is the whole front-door stopwatch; IntegrationLatency is how long the Function or HTTP backend alone held the baton. Comparing them shows whether the doorway or the back office is slow.
Full Explanation
API Gateway metrics in the oci_apigateway namespace separate front-door time from backend time. Latency covers gateway processing plus integration plus internal work—the citizen’s end-to-end wait through the gateway path. IntegrationLatency focuses on time spent in the Oracle Function or HTTP backend after the gateway hands off. Comparing the two for slow permit lookups shows whether delay is mostly doorway overhead or mostly the Function itself, which is the triage fork municipal operators need.
Looking only at oci_oke unschedulable-pod counts answers Kubernetes scheduling pressure on workers, not gateway-versus-Function latency for an already-reachable Functions backend. Audit log entries for IAM policy updates record who changed policies; they do not measure request duration split. APM RUM session replay focuses on browser-side user sessions; it is not the metric pair that separates API Gateway overhead from Function IntegrationLatency on the server path.
Exam caveat: high Latency with modest IntegrationLatency points at gateway or client-facing path cost; both high often means the Function (or its dependencies) dominate—confirm with dimensions and backend metrics before rewriting gateway config alone. Operational check: chart Latency and IntegrationLatency for the same gateway deployment and time window as the citizen complaints, then open Function duration/errors only if IntegrationLatency accounts for most of the Latency.