1.9 KiB
1.9 KiB
pg1-instrumented-metrics: Security & Architecture Audit
Scope
Audit of the instrumented metrics pipeline addition. Focus areas: information exposure, resource exhaustion, and architectural fit.
Findings
Information Exposure
| Risk | Assessment |
|---|---|
| Signal type names exposed in /metrics | Low -- Signal type names are application-defined, not user data. Already exposed via schema. |
| User IDs in UserSignalTimestampMap | None -- User IDs are stored in memory only, never serialized to /metrics or /diagnostics output. |
| /diagnostics endpoint | Low -- Feature-gated behind metrics. Same access model as /metrics (unauthenticated, firewall-protected). Existing warning in http.rs covers non-loopback binding. |
Resource Exhaustion
| Risk | Assessment |
|---|---|
| Per-type counter DashMap growth | Mitigated -- Bounded at 256 entries. Beyond 256 types, new types are silently dropped. |
| UserSignalTimestampMap growth | Mitigated -- Bounded at 10,000 entries. Sampling-based eviction keeps memory bounded at ~240KB. |
| Prometheus output size | Low -- Per-type counters add at most 256 lines. Percentile gauges add 18 lines (6 metrics x 3 percentiles). |
Architectural Fit
- Follows existing MetricsState pattern (Arc-shared atomics, feature-gated)
- No cross-layer violations (metrics code stays in db/metrics/)
- No new dependencies
- Consistent use of
Relaxedordering for statistical counters - /diagnostics follows same HTTP server pattern as /healthz and /metrics
Thread Safety
UserSignalTimestampMapusesDashMap(lock-free shard reads)- Per-type counter
DashMap<String, AtomicU64>is safe for concurrent access - Eviction races are benign (worst case: slightly over cap, converges on next write)
Verdict
APPROVE -- No security concerns. Resource usage is properly bounded. Architecture is consistent with existing patterns.