feat(services): per-endpoint Services page (server_ip:port → models + perf)

[vaderyang]

Summary

New "Services" page in the console that answers "what's 172.16.103.81:9000 serving, and how is it performing?". Aggregates llm_calls by (server_ip, server_port) — one row per LLM serving endpoint with distinct models, wire APIs, error/throughput, TTFT/E2E percentiles, first/last seen.

Why direct-on-llm_calls (not llm_metrics)

The pre-aggregated llm_metrics table's grouping sets stop at server_ip — two vLLM instances on the same host (port 8000 / port 9000) would collapse into one row. For a service view ("is the GLM-5 endpoint healthy?") you need port. Scanning llm_calls is fine in practice: a 7-day window in real production data has tens of thousands of rows and the query completes well under a second.

Backend

• ts_storage::query::ServiceRow + ServicesQuery — one row per endpoint with distinct models, wire APIs, call/error counts, TTFT/E2E avg + p95, total tokens, first/last seen.
• StorageBackend::query_services trait method + DuckDB impl. list_distinct(array_agg(model))[1:32] collects distinct models with a sanity cap; LIST-of-VARCHAR comes back as JSON strings (DuckDB rust bindings have no FromSql for Vec<String>) and gets parsed via the same parse_json_string_list helper that agent_turns.models_used uses.
• GET /api/services?start=&end=&sort_by=&sort_order=&limit= serves it.

Console

• Sidebar adds Services entry between Models and Agent Sessions (Lucide Server icon).
• ServicesPage table:
  • Endpoint (ip:port monospace)
  • Models (chips, max 4 inline, +N more hover-revealed)
  • Wire APIs
  • Calls (with stream %)
  • Error %
  • TTFT avg / p95
  • E2E avg / p95
  • In/Out tokens
  • Last seen (relative)
• Headers click-to-sort in-place — no refetch on resort.
• useServices hook follows the placeholderData: prev pattern — no flash on refresh.

Test plan

• cargo build --workspace clean
• cargo test -p ts-storage-duckdb --lib — 65 pass
• bun test — 111 pass
• bun run build — clean

E2E validation on wuneng coming in a follow-up reply.

🤖 Generated with Claude Code

[github-actions]

Summary

Agent run failed (exit 1). See workflow logs.

---

🤖 Reviewed by vivi • workflow run

[github-actions]

Summary

PR #25 adds a Services page aggregating LLM calls by (server_ip, server_port) endpoint with serving-software classification (vLLM/SGLang/Ollama/etc). The implementation is well-structured with a clean SQL aggregation, a thorough classifier with 22 unit tests, and a proper React table with client-side sorting. However, the query contains a known body-scan hazard that has already been fixed in a subsequent commit (bf4887f) not yet merged into this branch, and there are stale comments referencing the removed openai-compat label. REQUEST_CHANGES — the body-scan issue should block merge; the stale comments are fixable.

Blocking

• server/ts-storage-duckdb/src/metrics.rs:913-920 — Body-scan hazard via arg_max(..., LENGTH(body)). This pattern materializes every request_body/response_body in the time window just to pick the largest one per group. On a 7-day production window with ~662K rows (5+ GB body data), this query will be slow. The repo's canonical fix (commit bf4887f, "perf(services): 10x faster 7d window via top-N body sampling") exists but is not in this branch. The comment claims "fast u64 comparison" but DuckDB still materializes the bodies. Either rebase to include bf4887f or port its top-N row_number approach before merging.

Suggestions

• server/ts-storage/src/query.rs:82-85 — Comment lists openai-compat as a possible app value, but the classifier in apps.rs no longer emits this label (commit 682cd2f removed it in favor of definitive vllm/sglang classification). Update the docstring to match current behavior.

• console/src/types/api.ts:87-91 — Same stale comment. The JSDoc says openai-compat is a possible label, but the Rust classifier now returns vllm as the default uvicorn fallback. Align the comment with reality.

• server/ts-storage-duckdb/src/apps.rs:35 — Table comment says "vLLM is by far the more common openai-compat server" which is fine as context, but "openai-compat" is now a historical term. Consider rewording to "vLLM is by far the more common uvicorn-hosted server" for clarity.

Questions

• Why does the services endpoint query llm_calls directly rather than extending llm_metrics with a server_port grouping tier? The PR message explains it (metrics table stops at server_ip), but is there a plan to add port-level grouping to llm_metrics for future pre-aggregation, or is on-demand llm_calls aggregation intentional for flexibility?

Verified

• Schema mirror: ServiceRow Rust fields (query.rs:54-90) match TS interface ServiceRow (api.ts:70-94). Field names and types align; nullable fields correctly typed.
• Route registration: /services route registered in console/src/app.tsx:40. API route /api/services registered in server/ts-api/src/lib.rs:178 via routes::services::services.
• queryKey completeness: use-services.ts:17 includes start, end, sortBy, sortOrder, limit — all varying inputs.
• Public exports: ts-storage/src/lib.rs:9 uses pub use query::*, exporting ServicesQuery and ServiceRow. ts-storage-duckdb/src/lib.rs:166-168 implements the trait method.
• Caller compatibility: query_services only called by server/ts-api/src/routes/services.rs:67 — signature matches trait.

---

🤖 Reviewed by vivi • workflow run