# Request/HTTP logs + structured log filters (level · status · method · path · instance)

bex's logs API sources **application** logs only: `type=request`/`build` return an empty page (not an error), and Render's structured filters (`level`, `statusCode`, `method`, `path`, `instance`, `host`, `direction`) plus the MCP `list_log_label_values` discovery tool are accepted-but-unhonored / absent (documented divergence in docs/ADR006-bex-api.md, ADR010-observability.md). Render's dashboard Logs tab and public `/v1/logs` treat request logs as first-class (Pro+ on Render).

The gap needs a **structured log pipeline**, not just adapter plumbing:

- **Request logs** — bex already scrapes Traefik for request _metrics_; the access-log stream (method/path/status/latency per request) would have to be shipped to the log store and tagged, then surfaced through the existing `QueryLogs` verb + `type=request`.
- **Structured app-log fields** — `level` etc. require parsing/labeling raw pod stdout (or a logging-agent that emits structured lines).
- **Label-values discovery** — once labels exist, add MCP `list_log_label_values` + GraphQL/REST filter-suggestion reads (mirrors the metrics `metricsFilters` pattern already shipped).

Source: `docs/ADR018-render-parity.md` audit (w1/m13, 2026-07-08). Goal: pillar 1 (Render parity) + observability (w3). Promote to a milestone once the log backend strategy (w3/001) settles whether a structured store/agent is in scope; request logs likely gate on that decision.
