What problem does it solve? Adding latency metrics for new REST endpoints in a Spring Boot service often means scattering timing logic across controllers and filters, producing inconsistent tags and duplicated code. This Skill provides a canonical Filter + Recorder + Parser architecture where every request is measured once by a single OncePerRequestFilter, routed by a registry to a use-case-specific MetricsRecorder, and tagged by pluggable parsers — so adding a new endpoint metric requires exactly one new class. ## Core Features & Use Cases - Single measurement point: One MetricsFilter measures elapsed time for every request in a try/finally block, so failed requests are still recorded, and actuator paths are excluded. - Open/closed metric extension: A MetricsRecorderRegistry auto-discovers all MetricsRecorder beans via Spring constructor injection; new metrics are purely additive with zero changes to the filter or registry. - Structured, safe tagging: Parsers extract HTTP method, response status, and authenticated client ID, always returning non-blank sentinel values so Prometheus never rejects a metric; SLO histogram buckets are defined once in MetricsTimerHelper. - Use Case: You need a latency timer for a new /api/v1/entities/{id}/convert endpoint tagged by target format. Add one constant, one URI pattern entry, one TargetFormatParser, and one ConvertEntityMetricsRecorder — nothing else changes. ## Quick Start Apply the request-metrics skill to add a Micrometer timer metric for a new REST endpoint in my Spring Boot service, following the Filter, Recorder, and Parser package structure.
