> ## Documentation Index
> Fetch the complete documentation index at: https://docs.inputapi.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Request observability

> Correlate application and gateway requests, timing, and completion states.

## Correlate a request

The gateway's `middleware/request-id.go` generates an ID and returns `X-Gateway-Request-Id` plus the compatibility header `X-Oneapi-Request-Id`. Prefer the former. Rejections generated by a reverse proxy may have neither header. Do not treat a client-supplied header with the same name as a gateway-approved correlation ID.

Keep an application business-request ID and associate each attempt's returned gateway ID with it. Multiple SDK retries are multiple HTTP requests; one HTTP request can also contain internal gateway channel attempts. Application attempt counts do not measure internal attempts.

| Suggested field | Meaning and limitations |
| - | - |
| Application request ID / attempt | Correlates a business operation with explicit new requests |
| Gateway request ID | Helps operators locate logs; it is not an authentication credential |
| Protocol / method / path template | Record fixed routes such as `/v1/chat/completions`; avoid sensitive query parameters in raw URLs |
| Model / HTTP status | Use controlled fields; validate business results even after HTTP 200 |
| Headers / first event / total latency | Measure separately; receiving headers does not mean displayable content arrived |
| Completion outcome | Distinguish normal completion, refusal, tool calls, truncation, cancellation, and failure |

The [read-only diagnostic script](/en/guides/rate-limits) demonstrates safe metadata logging. It records cumulative elapsed time when headers arrive, does not measure first-token or model inference latency, and does not call generation endpoints.

## Production logging

Use monotonic clocks for durations and timestamps with time zones to locate events. Streams may begin with roles, empty deltas, or tool arguments; measure the relevant first event only when usable data arrives. Success metrics must wait for the protocol's completion conditions, rather than treating EOF or the first data item as success.

Allowlist business-log fields. Exclude API keys, Authorization, Cookie, complete prompts / outputs, Base64 media, native signatures, compacted ciphertext, and signed download URLs. Do not print raw SDK exceptions or full HTTP response bodies. Confirm body retention, access controls, and retention periods with the operator; `store: false` does not mean every component disables logging.

## Minimal support record

1. Time and time zone, deployment environment, SDK name and version.
2. Method and path template, model, HTTP status, and sanitized error type.
3. Application attempt count, gateway request ID, and whether partial output or a task ID arrived.
4. A minimal reproducible request structure with placeholders for business content and credentials; share task IDs only through approved support channels.
5. Expected and actual behavior, for example “expected completed text, received `finish_reason=length`.”

Start with [troubleshooting](/en/guides/troubleshooting) and [protocol boundaries](/en/guides/protocol-compatibility). A successful log entry describes its own request; it does not certify every model or channel.

[阅读中文](/zh/guides/observability)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.