POC instrumentation: structured logging, real health checks, inference timing #6

New Issue

2026-09-01T21:35:55Z

Ty commented

2026-09-01 21:35:55 +00:00

Summary

Add the minimum instrumentation needed to debug UAT smoke tests by hand. No new infrastructure — config and a few log lines only.

Scope (POC required)

Health endpoint — GET /api/health must check database connectivity and image-volume writability, not just process liveness.
Structured JSON logging — every request carries a request ID threaded end to end (phone → FastAPI → Woo). Levels: info for lifecycle events, error for hard failures. LOG_LEVEL env var, default info; flip to debug only while actively tuning.
Inference logging — every Call 1 and Call 2 invocation records latency, model, and confidence score.
Existing tables — confirm sync_log (Woo publish attempts, payload hashes) and inference_log are actually written and queryable.

Non-goals

No metrics endpoint, no alerting, no tracing, no error-tracking service. Those land in the V1 issue.

Acceptance

A failed UAT publish is traceable by grepping one request ID across phone, server, and Woo logs.
Health returns non-200 when the DB or volume is unreachable.
Inference calls are visible with timing in the logs.

## Summary Add the minimum instrumentation needed to debug UAT smoke tests by hand. No new infrastructure — config and a few log lines only. ## Scope (POC required) 1. **Health endpoint** — `GET /api/health` must check database connectivity and image-volume writability, not just process liveness. 2. **Structured JSON logging** — every request carries a request ID threaded end to end (phone → FastAPI → Woo). Levels: info for lifecycle events, error for hard failures. `LOG_LEVEL` env var, default `info`; flip to `debug` only while actively tuning. 3. **Inference logging** — every Call 1 and Call 2 invocation records latency, model, and confidence score. 4. **Existing tables** — confirm `sync_log` (Woo publish attempts, payload hashes) and `inference_log` are actually written and queryable. ## Non-goals No metrics endpoint, no alerting, no tracing, no error-tracking service. Those land in the V1 issue. ## Acceptance - A failed UAT publish is traceable by grepping one request ID across phone, server, and Woo logs. - Health returns non-200 when the DB or volume is unreachable. - Inference calls are visible with timing in the logs.

Ty added this to the POC milestone 2026-09-01 23:49:44 +00:00

Ty referenced this issue

2026-09-03 02:36:57 +00:00

Test plan: POC acceptance test cases for all milestone issues #19

Ty commented

2026-09-03 02:46:45 +00:00

Doc changes applied:

OPENAPI: health endpoint returns db_reachable, volume_writable, status can be degraded, returns non-200 on DB/volume failure
ARCHITECTURE §10: new instrumentation section covering structured JSON, request IDs, log level, inference timing, queryable logs
DEPLOYMENT §6: new logging section with Docker JSON-file driver config, LOG_LEVEL env var, retention policy
DATA-MODEL inference_log: added model, latency_ms, confidence_score columns

Test cases needed once implementation exists:

Health checks — GET /api/health returns non-200 when DB unreachable; returns non-200 when image volume unreachable; returns degraded when Woo unreachable but DB/volume OK.
Structured JSON — every request produces a JSON log line with request ID, timestamp, method, path, status code, duration.
Request ID threading — same request ID appears in logs for phone → FastAPI → Woo calls.
Inference timing — inference_log table records latency, model, and confidence score for each Call 1.
Log rotation — Docker JSON-file driver rotates logs at configured max-size/max-file cap.
Queryable logs — sync_log and inference_log tables are written and queryable via SQLite.

Doc changes applied: - OPENAPI: health endpoint returns `db_reachable`, `volume_writable`, `status` can be `degraded`, returns non-200 on DB/volume failure - ARCHITECTURE §10: new instrumentation section covering structured JSON, request IDs, log level, inference timing, queryable logs - DEPLOYMENT §6: new logging section with Docker JSON-file driver config, LOG_LEVEL env var, retention policy - DATA-MODEL inference_log: added `model`, `latency_ms`, `confidence_score` columns Test cases needed once implementation exists: 1. **Health checks** — GET /api/health returns non-200 when DB unreachable; returns non-200 when image volume unreachable; returns degraded when Woo unreachable but DB/volume OK. 2. **Structured JSON** — every request produces a JSON log line with request ID, timestamp, method, path, status code, duration. 3. **Request ID threading** — same request ID appears in logs for phone → FastAPI → Woo calls. 4. **Inference timing** — inference_log table records latency, model, and confidence score for each Call 1. 5. **Log rotation** — Docker JSON-file driver rotates logs at configured max-size/max-file cap. 6. **Queryable logs** — sync_log and inference_log tables are written and queryable via SQLite.

grokbot_ty commented

2026-09-24 18:54:54 +00:00

Verified in main @ 0c00d25: health endpoint (app.py:156), request_id threading (:31-48), LOG_LEVEL (:57), inference latency logging (inference.py:337,508), inference_log written. Done.

Verified in main @ 0c00d25: health endpoint (app.py:156), request_id threading (:31-48), LOG_LEVEL (:57), inference latency logging (inference.py:337,508), inference_log written. Done.

grokbot_ty closed this issue

2026-09-24 18:54:54 +00:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Ty_Tech/SlabUploader#6