Prometheus v3.12.0 Hardens Security and Expands Cloud Discovery 🔗
Latest release fixes critical vulnerabilities, enhances PromQL with start-timestamp functions, and adds service discovery for major cloud providers.
Why this leads today Prometheus’s ongoing development ensures reliable metrics and alerting for production systems, maintaining its role as essential, battle-tested infrastructure for cloud-native observability at scale.
Prometheus, the Cloud Native Computing Foundation’s cornerstone monitoring system, has released v3.12.0 with a focus on security hardening and operational resilience.
The update addresses two significant vulnerabilities: a denial-of-service flaw in remote-write snappy decompression that could allow malformed requests to crash the server, and a secret exposure leak in the STACKIT service discovery integration where credentials were inadvertently exposed via the /-/config HTTP endpoint. Both issues have been patched, with the remote-write fix enforcing a 32MB limit on decompressed payload size and the STACKIT SD now redacting sensitive fields from configuration outputs.
Beyond security, the release deepens Prometheus’ query capabilities. Experimental start-timestamp support—first introduced in v3.11—has been refined, with updates to core functions like rate(), irate(), increase(), and resets() to better handle time series with non-uniform start times. Four new experimental PromQL functions—start(), end(), range(), and step()—are now available, giving developers finer-grained control over temporal boundaries in alerts and recording rules. These changes are particularly valuable for teams running long-running batch jobs or ephemeral workloads where traditional scrape intervals don’t align cleanly with metric collection windows.
Service discovery has also expanded, adding native support for DigitalOcean Managed Databases and Outscale VM instances, alongside IPv6 and external ID enhancements for AWS EC2 discovery. The TSDB layer received performance optimizations, including constant-time head chunk lookup and improved mmap efficiency, reducing CPU overhead during high-cardinality workloads. A new UI feature allows administrators to directly delete time series and clean tombstones from the web interface—a long-requested operational tool for managing metric retention and compliance.
Despite its maturity, Prometheus remains architecturally opinionated: it is designed for reliability and simplicity over horizontal scale-out. Its pull-based model and lack of distributed storage mean that while single-node autonomy is a strength, scaling beyond a few hundred thousand time series often requires federation, remote storage adapters, or careful sharding—trade-offs that teams must be evaluated early in adoption. The project’s steady commit cadence and large open-issue count (848) reflect ongoing maintenance, but also hint at the complexity of balancing backward compatibility with evolving cloud-native demands.
The catch: Prometheus excels at infrastructure and service monitoring but is not optimized for high-cardinality event logging or distributed tracing—use cases better served by complementary systems like Loki or Tempo, which increases operational overhead when full observability is required.
- Monitoring Kubernetes cluster health and resource utilization
- Alerting on latency spikes in microservices via PromQL rules
- Collecting custom metrics from batch jobs using the Pushgateway intermediary
Source: prometheus/prometheus — based on the README and release notes.