A citizen’s failed dog-license renewal hit API Gateway then an Oracle Function. Which field is the documented way to join gateway and function log lines for that same client call?
Select an answer to reveal the explanation.
Short Explanation
opcRequestId is the shared ticket stub stamped on the gateway and the function for one client call. Wildcard the shared prefix and both log trails line up.
Full Explanation
Cross-service correlation for a citizen call that hit API Gateway then an Oracle Function centers on data.opcRequestId. For Functions, that field identifies the invocation. When API Gateway fronts the function, documentation describes using a wildcard on the shared prefix of data.opcRequestId so gateway and function log lines for the same client call join in Logging Search. That is the supported join key for this gateway-to-function path—not pod identity or secret OCIDs.
The OKE Pod UID identifies a Kubernetes pod on a worker; it does not join API Gateway and Functions log lines for a Functions-backed call. The Vault secret OCID used at cold start may appear in secret-access contexts but is not the documented request-correlation field across gateway and function logs. A Streaming partition key from an unrelated alarm destination has no role as the join key for those HTTP/function log lines.
Exam caveat: prefix wildcards help when gateway and function share a request-id prefix pattern—verify you are matching the same citizen call’s id shape, not a different request’s full id. Operational check: capture data.opcRequestId from the failed dog-license gateway log line, search Functions logs with the documented shared-prefix wildcard, and confirm both sides of the renewal failure appear in one correlated set.