Monitoring with Prometheus and Grafana

This guide covers the metrics exposed by the rate limiter, how to scrape them with Prometheus, and how to build Grafana dashboards that surface rate-limit behavior.

Prerequisites

• Actuator and Prometheus endpoint enabled in the Spring Boot service
• Access to the /actuator/prometheus endpoint

Metrics endpoint

The service exposes Prometheus metrics at:

GET /actuator/prometheus

You should see JVM metrics, HTTP server metrics, and custom rate-limiter metrics in Prometheus text format.

Prometheus scrape configuration

Create a scrape job that targets the service.

global:
  scrape_interval: 15s
  evaluation_interval: 15s

scrape_configs:
  - job_name: "rate-limiter"
    metrics_path: "/actuator/prometheus"
    scrape_interval: 5s
    static_configs:
      - targets: ["rate-limiter:8080"]
    labels:
      application: "rate-limiter"
      environment: "production"

If you run Prometheus in Docker and the app runs on the host, replace rate-limiter:8080 with host.docker.internal:8080 (or the host IP for Linux).

Key metrics to watch

The most useful metrics for rate limiting are:

• rate_limiter_requests_total{algorithm,allowed}
• rate_limiter_decision_time_seconds{algorithm}
• http_server_requests_seconds_count{status,uri,method}
• redis_up (if you export Redis metrics)

Use rate_limiter_requests_total to measure allow/deny rates per algorithm and to detect sudden spikes in throttling.

Grafana dashboards

Request rate and rejection rate

rate(http_server_requests_seconds_count[1m])
  by (uri)

rate(http_server_requests_seconds_count{status="429"}[1m])
  by (uri)

These charts show total request volume and the rate of 429 responses by endpoint. A sharp increase in 429s usually indicates a limit change or a traffic spike.

Algorithm performance

increase(rate_limiter_requests_total{allowed="true"}[5m])
  / increase(rate_limiter_requests_total[5m])
  by (algorithm)

rate_limiter_decision_time_seconds{quantile="0.95"}
  by (algorithm)

This highlights the success ratio per algorithm and the p95 decision time. Rising decision time often indicates Redis latency or memory pressure.

JVM and process health

jvm_memory_used_bytes{area="heap"} / jvm_memory_max_bytes{area="heap"}
process_cpu_usage
jvm_gc_pause_seconds_max

These metrics help spot JVM memory pressure or GC pauses that can affect response latency.

Cardinality and label hygiene

Be careful with uri labels. High cardinality can exhaust Prometheus memory. Prefer grouping by path template or prefix, or drop the label for high-volume endpoints.

If you see Prometheus heap growth or millions of series, reduce label cardinality before tuning anything else.

What to verify

• /actuator/prometheus is reachable and returns metrics.
• Prometheus can scrape the service without authentication failures.
• Grafana dashboards show stable series counts and reasonable latency.