Prometheus Go Code Review

Review Checklist

• Metric types match measurement semantics (Counter/Gauge/Histogram)
• Labels have low cardinality (no user IDs, timestamps, paths)
• Metric names follow conventions (snake_case, unit suffix)
• Histograms use appropriate bucket boundaries
• Metrics registered once, not per-request
• Collectors don't panic on race conditions
• /metrics endpoint exposed and accessible

Hard gates (sequenced)

Complete in order before recording a finding. Skip gates that clearly do not apply to the diff.

1. Evidence scope — Enumerate the files you are reviewing that touch Prometheus (prometheus/client_golang, promauto, promhttp, or MustRegister). Pass: you have a concrete path list (from the diff or an explicit file set); no repo-wide claim without at least one path.

2. Label cardinality — For each *Vec or labeled metric in scope, list label names and where values come from (constants, bounded codes, vs request-derived strings). Pass: no label uses unbounded values (e.g. raw user_id, full URL path, timestamps) unless the code uses a bounded mapping and you cite it.