Unit 15.03: Instrumenting and bounding it

Instrumentation and bounds are decided before the first real request.

Twelve fields, four bounds, two health checks

What is logged, what is never logged, what is bounded and what is alerted.

The code prints the plan.

import json

instrumentation = {
    "per_request": ["request_id", "method", "path", "status", "latency_ms",
                    "caller", "model", "prompt_version", "input_tokens",
                    "output_tokens", "usd", "refused_reason"],
    "never_logged": ["request body", "model output", "api key"],
    "bounds": {"max_input_chars": 4000, "daily_usd": 50.0,
               "request_timeout_s": 30, "rate_limit_per_minute": 60},
    "health": {"/healthz": "process alive", "/readyz": "dependencies reachable"},
    "alerts": {"5xx rate": "> 1%", "p95 latency": "> 2000ms",
               "daily spend": "> 80% of budget"},
}
print(json.dumps(instrumentation, indent=2))

print(f"\n{len(instrumentation['per_request'])} fields per request, none of them content")
print("Every bound is enforced in code, not documented as an intention.")

Every bound is enforced in code rather than documented as an intention. The input limit, the daily budget, the request timeout and the rate limit are all things the service refuses to exceed.

The never_logged list is short and absolute. It matches a guarantee from the scope, which is what makes it a contract term rather than a preference.

The mistake this prevents

The mistake is adding instrumentation after the first incident, using whatever would have helped with that one. The next incident is different, and these fields are cheap enough to add together.

Takeaway

Decide the logged fields, the never-logged list, the bounds and the alerts before the first real request. Every bound must be enforced, not intended.

Mark complete