docs(proposals): add configurable access log fields proposal (#799)

[henschwartz]

Summary

• Adds the What?/Why? proposal for #799 to make HTTP access_log fields selectable (default = today’s fixed set) and to add emit-time conditions (duration, status class, path) that compose with sample_rate.
• Keeps scope on the access-log filter record shape and emission gates; explicitly separated from process logging (Non-blocking log writer with file rotation #797/Dynamic log level adjustment via admin API #798), the broader Customizable Access Log Format #126 format/sink epic, TCP tcp_access_log, and tap (Live request tap API (SSE streaming) #792).
• Leaves How? out of this PR per proposal process; open questions (replace vs add fields, header encoding, overlap with pipeline conditions) stay for direction review.

Test plan

• Confirm What?/Why? cover field selection, headers/trace_id, conditions-then-sampling, and flat filter YAML
• Confirm Non-Goals

[praxis-bot]

PR Review

Adds the What?/Why? proposal for #799 to make HTTP access_log fields selectable and add emit-time conditions.

Overall Assessment

Well-structured proposal that accurately describes the current access_log filter behavior (verified against source), clearly delineates scope with thorough non-goals, and asks the right open questions. One gap between stated Goals and graduation criteria.

Severity	Count
Critical	0
Large	0
Medium	1

[tkan145]

Hi, I have a question. When #126 is implemented, will it override what's currently in this proposal? Assuming we're going to use something like CEL for #126, then passing context to render the log, I think that would make the selectable fields in this proposal obsolete as you can do something like

 "custom_logging": "[{{time_local}}] {{host}}:{{server_port}} {{remote_addr}}:{{remote_port}} \"{{request}}\" {{status}} {{body_bytes_sent}} ({{request_time}})

[henschwartz]

Hi @tkan145, #126 is the bigger piece custom log lines (e.g. CEL), more sinks, per-route formats. #799 is smaller, same JSON access log as today, but you choose which fields go in and when to emit (slow requests, 5xx, certain paths), still with sample_rate. So #126 doesn’t cancel this. A template in #126 could eventually replace “pick these fields,” but #799 still gives useful gating and validation without a template engine. We already call out in Non-Goals that full custom formats stay in #126.

[praxis-bot]

PR Re-Review (5 new commits)

Re-review after 5 new commits since the previous review.

Previous Finding Status

The previous medium finding (missing graduation criteria for trace_id/span_id and config validation) was addressed in 43ac56eb. Both criteria were added to the frontmatter and align with the corresponding goals.

New Commits Reviewed

Commit	Summary
950b0982	Merge from main
df4de1fd	CI retrigger (no content)
43ac56eb	Addresses bot review -- adds graduation criteria
bb40b497	Merge from main

Assessment

No new issues found. The substantive change (commit 43ac56eb) adds the two requested graduation criteria cleanly:

1. trace_id and span_id presence/absence tied to OTel state
2. Invalid field names, empty header lists, invalid status classes, and out-of-bounds sample_rate rejected at config load time

All eight goals now have corresponding graduation criteria. Verified the proposal's description of current behavior (hardcoded field set, deterministic every-Nth sampling) against filter/src/builtins/http/observability/access_log.rs -- accurate.

Severity	Count
Critical	0
Large	0
Medium	0
Small	0

[tkan145]

Thank you for the explanation.

[praxis-bot]

PR Review (1 new commit)

Re-review after 1 new commit (b6fc9698, merge from main) since the previous review at bb40b497.

Previous Finding Status

The original Medium finding (missing graduation criteria for trace_id/span_id and config validation) was resolved in 43ac56eb and confirmed in the prior re-review. No regression.

Verification

Verified the proposal's description of current behavior against filter/src/builtins/http/observability/access_log.rs:

• Field list: all 10 hardcoded fields (method, path, client_ip, status, duration_ms, cluster, upstream, request_id, request_body_bytes, response_body_bytes) match emit_access_log (lines 121--137)
• Sampling: deterministic every-Nth via AtomicU64 counter + is_multiple_of (lines 103--110), consistent with the proposal's "every-Nth" language and the Non-Goals deferral of probabilistic sampling
• Config surface: only sample_rate with deny_unknown_fields, matching the proposal's "operators can only tune sample_rate" statement

All 8 goals have corresponding graduation criteria. Non-Goals (7 items) and Open Questions (6 items) are comprehensive. Format matches the proposal template and peer proposals.

Assessment

No new issues found. No content changes in the new commit.

Severity	Count
Critical	0
Large	0
Medium	0