Request-ID based logging + structured JSON logging defaults #48

New issue

Closed

opened 2026-09-16 06:13:38 +00:00 by ginjiruu · 0 comments

ginjiruu commented

2026-09-16 06:13:38 +00:00

Owner

Problem

The bridge's serving paths (the gRPC ext_authz OIDC and Exchange Check services, the plain-HTTP callback/logout listener) log without any per-request correlation ID. A single Check or callback can emit several log lines (e.g. No App resolved for the Host plus the deny, or a bearer validation failure), and with concurrent requests interleaved there is no way to group the lines belonging to one request.

Separately, the manager defaults to the zap development encoder (Development: true in cmd/main.go) — console output. In the cluster we want structured JSON logs by default.

Plan

Attach a request ID to every served request:
- gRPC (OIDC + Exchange Check): a unary server interceptor that honors an incoming x-request-id metadata key and generates one (16 random bytes, base64url) when absent. The ID is carried on the request context logger and echoed back in the response metadata.
- HTTP (callback/logout): middleware that honors an incoming X-Request-Id header, generates one when absent, sets it on the response, and carries it on the request context logger.
The ID is attached to the context logger under the requestID key, so every existing logf.FromContext(ctx) line in the flows picks it up without call-site changes.
Structured JSON by default: zap.Options{Development: false} (JSON encoder, Info level, stacktraces on errors). --zap-devel still switches to the console development encoder for local use.

## Problem The bridge's serving paths (the gRPC ext_authz OIDC and Exchange Check services, the plain-HTTP callback/logout listener) log without any per-request correlation ID. A single Check or callback can emit several log lines (e.g. `No App resolved for the Host` plus the deny, or a bearer validation failure), and with concurrent requests interleaved there is no way to group the lines belonging to one request. Separately, the manager defaults to the zap **development** encoder (`Development: true` in `cmd/main.go`) — console output. In the cluster we want structured JSON logs by default. ## Plan - Attach a request ID to every served request: - **gRPC (OIDC + Exchange Check)**: a unary server interceptor that honors an incoming `x-request-id` metadata key and generates one (16 random bytes, base64url) when absent. The ID is carried on the request context logger and echoed back in the response metadata. - **HTTP (callback/logout)**: middleware that honors an incoming `X-Request-Id` header, generates one when absent, sets it on the response, and carries it on the request context logger. - The ID is attached to the context logger under the `requestID` key, so every existing `logf.FromContext(ctx)` line in the flows picks it up without call-site changes. - **Structured JSON by default**: `zap.Options{Development: false}` (JSON encoder, Info level, stacktraces on errors). `--zap-devel` still switches to the console development encoder for local use.

ginjiruu referenced this issue from a pull request that will close it,

2026-09-16 06:19:59 +00:00

feat: request-ID based logging and structured JSON logging defaults #49

ginjiruu closed this issue

2026-09-16 12:56:07 +00:00