Prometheus metrics for Spring Boot gRPC services

At a glance

What this is: This is a tooling guide for exposing Spring Boot gRPC service metrics to Prometheus, with a practical walkthrough of actuator, scrape configuration, method timing, and exception counting.

Why it matters: It matters to platform and security teams because service telemetry can improve detection and reliability, but broad metric exposure and weak endpoint controls also create an access-governance problem.

👉 Read StackHawk's guide to Prometheus metrics for Spring Boot gRPC services

Context

Prometheus metrics are only useful when the underlying service exposure is deliberate. In this case, the article shows how teams surface gRPC telemetry from Spring Boot services through actuator endpoints, Kubernetes annotations, and Prometheus scrape jobs. The security question is not whether metrics are valuable, but whether observability endpoints are exposed with enough control for the environment they sit in.

For IAM and platform teams, the identity angle is indirect but real: actuator endpoints, scrape access, and internal service telemetry all depend on who or what can reach them. When teams expose everything to make instrumentation easier, they often create a trust boundary that is wider than the application architecture actually needs.

Key questions

Q: How should teams secure Prometheus endpoints in Spring Boot services?

A: Limit actuator exposure to the smallest set of trusted consumers, and do not rely on “internal” network placement as the only safeguard. Use network controls, namespace boundaries, and authentication where feasible so /actuator/prometheus does not become a broadly readable management surface. Metrics are operational data, not public utility data.

Q: Why do observability endpoints create governance issues for platform teams?

A: Because metrics endpoints reveal service behaviour, error patterns, and deployment structure, which can help both operators and attackers map the environment. Once access is broad, the organisation has created a data surface that needs ownership, policy, and review, not just engineering convenience.

Q: What breaks when metric instrumentation is inconsistent across services?

A: Monitoring becomes partial, comparisons become misleading, and incident response loses signal where teams expected coverage. If some handlers are timed and others are not, or exceptions bypass the shared interceptor, you get observability drift. The result is a dashboard that looks complete but does not represent the full service estate.

Q: How can teams tell whether observability is improving identity governance?

A: Teams can tell observability is improving governance when it changes decisions, not just dashboards. Look for fewer unknown access paths, faster investigation of anomalous identity actions, and better prioritisation of recertification and privilege cleanup. If visibility does not change remediation, it is only producing more telemetry.

Technical breakdown

Spring Boot actuator exposure and gRPC telemetry

Micrometer adds application metrics to Spring Boot, while the actuator exposes them over HTTP for collection. In the article’s pattern, both /actuator/metrics and /actuator/prometheus are made available so Prometheus can scrape service-level telemetry. That makes operational visibility easy to bootstrap, but it also means the metrics surface becomes part of the service attack surface. If the endpoints are open beyond the intended cluster boundary, metrics can reveal service names, error patterns, and runtime behaviour that help an attacker map the environment.

Practical implication: restrict actuator exposure to trusted networks and service accounts, not broad internal access.

Kubernetes scrape discovery and label-based collection

Prometheus discovers pods by reading Kubernetes metadata annotations such as prometheus.io/scrape and prometheus.io/path. That pattern is efficient because the application advertises its own scrape location and Prometheus builds targets dynamically from cluster state. The trade-off is governance complexity: scrape permissions, namespace boundaries, and pod labels now influence what telemetry is collected. In larger clusters, this can blur the line between observability and unintended disclosure if the same discovery pattern is reused across teams without policy.

Practical implication: tie scrape permissions and namespace scoping to cluster policy, not local service defaults.

Timed method metrics and exception counters

The article uses @Timed for per-method latency and a shared exception handler to increment counters tagged by exception class. This is a common pattern because it gives both performance and reliability signals without changing business logic. From a security operations perspective, those metrics can also become behavioural indicators, showing sudden failure spikes, abnormal latency, or repeated error classes across services. The main limitation is consistency: if developers forget to annotate methods or route exceptions through shared handlers, the observability model becomes partial and uneven.

Practical implication: standardise metric instrumentation in shared libraries so service coverage does not depend on individual developer discipline.

NHI Mgmt Group analysis

Service telemetry is a governance boundary, not just an engineering convenience. The article treats observability as a lightweight implementation detail, but metrics endpoints are still access-controlled surfaces. Once actuator and Prometheus endpoints are broadly exposed, the organisation has created a new class of internal data access that needs ownership, policy, and review. That is an IAM issue as much as a platform issue, because telemetry access can reveal operational fingerprints that should not be universally visible. Practitioners should treat observability endpoints as governed assets, not defaults.

Prometheus discovery patterns can widen trust faster than teams notice. Kubernetes annotations make scraping easy, but they also make collection implicit. That implicit trust can outgrow the intended namespace or service boundary, especially when multiple teams share cluster patterns. The article is a useful reminder that visibility tooling often scales faster than governance, which is why policy controls around who can publish scrape metadata matter. Practitioners should align telemetry discovery with cluster access policy, not just deployment convenience.

Instrumentation debt becomes operational blind spots. Method-level timing and exception counters only help if they are applied consistently across services. When some gRPC handlers are timed and others are not, or when exceptions bypass the shared handler, the resulting metrics create a false sense of completeness. Observability drift: the gap between what engineers think they are monitoring and what the platform is actually collecting. Practitioners should standardise shared instrumentation patterns so monitoring coverage is measurable, not assumed.

Identity context still matters in a non-identity article. The trust model for metrics collection depends on service accounts, cluster permissions, and endpoint exposure. That means the same governance questions that apply to machine identities also apply here: which workload can scrape what, from where, and under which policy. For identity teams, the practical lesson is to include observability endpoints in access reviews and to treat scrape credentials and discovery permissions as part of the non-human identity surface.

Operational telemetry should support security decisions, not replace them. Latency and exception metrics are useful signals, but they do not tell you whether the service is exposed in ways the architecture did not intend. Teams still need separate checks for endpoint access control, namespace isolation, and credential scope. Practitioners should use metrics to improve detection and reliability while keeping governance controls accountable for exposure management.

What this signals

Observability drift will keep showing up wherever teams treat metrics exposure as an implementation detail instead of a governed access path. The practical signal for security programmes is simple: if you cannot describe who can scrape what, you do not have full control of the telemetry surface. That is why access reviews for service accounts and collectors belong alongside normal platform governance, not after an incident.

This topic also reinforces a broader IAM pattern. Machine-to-machine access often expands through convenience, then persists because no one owns the boundary between deployment automation and runtime visibility. Teams that align service accounts, scrape permissions, and endpoint exposure to policy will get cleaner monitoring and less accidental disclosure. Those that do not will keep confusing uptime telemetry with secure telemetry.

For teams building identity programmes, the useful next step is to map observability endpoints into the same control family as other internal management surfaces. That means documenting which non-human identities can read metrics, which namespaces are discoverable, and where shared libraries standardise behaviour. Once you can answer those questions consistently, metrics become a managed control plane rather than an informal trust zone.

For practitioners

• Scope actuator endpoints deliberately Expose /actuator/metrics and /actuator/prometheus only to the networks, namespaces, or service accounts that truly need them. Treat observability endpoints as internal data surfaces and review them alongside other management interfaces.
• Bind Prometheus scraping to cluster policy Use Kubernetes annotations and scrape jobs with namespace and label constraints so telemetry collection follows intended boundaries. Avoid cluster-wide discovery patterns that make every pod automatically visible to every collector.
• Standardise shared metric instrumentation Put timing and exception counter patterns into common libraries so every gRPC service emits consistent telemetry. That reduces blind spots and makes it easier to compare latency and error rates across services.
• Review scrape access as part of identity governance Include Prometheus collectors, scrape credentials, and service account permissions in regular access reviews. The question is not only whether metrics are present, but which non-human identities can retrieve them.

Key takeaways

• Prometheus visibility for gRPC services is useful, but it creates a governed telemetry surface that should be access-controlled like any other internal management endpoint.
• Kubernetes-based scrape discovery scales quickly, yet it can widen trust boundaries unless namespace and label policies are explicitly enforced.
• Shared metric instrumentation reduces blind spots, but identity and access reviews still need to cover collectors, service accounts, and endpoint exposure.

Key terms

• Observability Drift: The gap between the telemetry a team expects to collect and what the platform actually records. It usually appears when instrumentation is inconsistent across services, shared handlers are bypassed, or scrape coverage is left to local developer habits instead of standard policy.
• Actuator Endpoint Exposure: The practice of publishing Spring Boot management endpoints so metrics and operational data can be collected. In security terms, these endpoints are still access-controlled surfaces and should be treated as internal management interfaces, not harmless implementation details.
• Telemetry Surface: The set of endpoints, credentials, collectors, and discovery rules used to expose operational data. It matters because telemetry often reveals service behaviour, environment structure, and failure patterns, making it part of the access-governance problem rather than a pure monitoring concern.
• Scrape Discovery: The mechanism Prometheus uses to find targets automatically, often by reading Kubernetes annotations and labels. It simplifies operations, but it also means collection boundaries depend on cluster metadata and policy discipline, not only on Prometheus configuration.

What's in the full article

StackHawk's full article covers the implementation detail this post intentionally leaves for the source:

• Exact Spring Boot configuration for exposing actuator metrics and Prometheus endpoints in a gRPC service.
• Full Kubernetes annotation and Prometheus scrape job examples for discovering pods automatically.
• Code patterns for adding method timing and exception counters through shared Micrometer hooks.
• PromQL examples for calculating average method latency and error rates from the exported metrics.

👉 The full StackHawk post includes the actuator setup, scrape configuration, and PromQL examples.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners build the control discipline needed for service accounts, access boundaries, and lifecycle oversight across modern environments.