Expose Prometheus Metrics from Dropwizard in Minutes

Problem: Observability in a Dropwizard Microservice

When a microservice grows, you need a lightweight way to surface JVM health, request latency, and custom business counters. Dropwizard already ships a metrics library, but many teams wonder how to surface those metrics to a Prometheus‑based monitoring stack without writing adapters.

Thesis: Dropwizard’s /metrics Endpoint Is Prometheus‑Ready

The /metrics endpoint outputs metrics in the text exposition format that Prometheus expects. By wiring the built‑in MetricsBundle into your application you get out‑of‑the‑box observability with minimal code.

Step 1 – Enable the Metrics Bundle

In your Application subclass, add the bundle during bootstrap. Dropwizard 2.x uses the same API as 1.x, so the snippet works for both:

public class MyService extends Application<MyConfiguration> {
    @Override
    public void initialize(Bootstrap<MyConfiguration> bootstrap) {
        bootstrap.addBundle(new MetricsBundle());
    }
    // ...
}

Run with java -jar myservice.jar server config.yml. The bundle registers JVM metrics (GC, thread counts, heap usage) and exposes them on /metrics. No extra configuration files are needed.

Step 2 – Register a Custom Counter

Dropwizard’s MetricRegistry is a singleton accessible via the Environment object. Create a counter that increments each time a specific endpoint is hit:

public class StatsResource {
    private final Counter requestCounter;

    public StatsResource(Environment env) {
        this.requestCounter = env.metrics().counter("api.requests.total");
    }

    @GET
    @Path("/stats")
    public Response getStats() {
        requestCounter.inc();
        return Response.ok("Stats collected").build();
    }
}

Register StatsResource in your Application:

public void run(MyConfiguration config, Environment env) {
    env.jersey().register(new StatsResource(env));
}

Step 3 – Verify Prometheus‑Compatible Output

From a terminal run:

curl -s http://localhost:8080/metrics | head -n 20

You should see lines like:

# HELP api_requests_total Total number of API requests
# TYPE api_requests_total counter
api_requests_total 42

Prometheus scrapes the same URL. Add a job to prometheus.yml:

scrape_configs:
  - job_name: dropwizard
    static_configs:
      - targets: ["localhost:8080"]

Reload Prometheus and confirm the target appears healthy. The /metrics/graph endpoint in Dropwizard also renders a simple HTML graph for manual inspection.

Trade‑Off: Minor Overhead vs. Full Observability

Collecting and serializing metrics adds CPU and memory usage. In high‑throughput services the overhead can reach a few percent of total CPU. Measure with jstat or Prometheus process_cpu_seconds_total before and after enabling the bundle to quantify the impact. If you notice a measurable slowdown, prune unused metrics or batch counter increments.

Actionable Next Steps

• Secure the /metrics endpoint with basic auth or network policies to prevent leaking internal state.
• Use Dropwizard’s HealthCheck API to surface health metrics (/health) alongside /metrics.
• Instrument additional custom gauges or histograms for latency or request size as needed.
• Set up alerts in Prometheus or Alertmanager based on metric thresholds you care about.

With these steps you have a fully Prometheus‑compatible metrics surface for a Dropwizard service, enabling consistent observability across your microservice ecosystem.