https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/proposals/accepted/Recent content in Accepted Proposals on Prometheus OperatorHugo -- gohugo.ioen-UShttps://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/proposals/accepted/shard-autoscaling/Mon, 01 Jan 0001 00:00:00 +0000https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/proposals/accepted/shard-autoscaling/Owners: Arthur Sens Nicolas Takashi Status: Accepted Related Tickets: #4927 #4946 #4967 Other docs: n/a This document aims to address existing issues preventing users from leveraging the Horizontal Pod Autoscaler (HPA) in conjunction with Prometheus sharding. Why Pitfalls of the current solution Goals Non-Goals Audience How Scale subresource Graceful scale-down of Prometheus Servers Scaling up after scaling down Graceful scale-down of Prometheus Agents Scale-down alternatives Action Plan Why # Managing Prometheus instances with highly variable workloads can be quite challenging.https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/proposals/accepted/agent-daemonset/Mon, 01 Jan 0001 00:00:00 +0000https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/proposals/accepted/agent-daemonset/Owners: haanhvu Status: Accepted Related Tickets: #5495 Other docs: n/a This proposal is about designing and implementing the deployment of Prometheus Agent as DaemonSet. Currently, Prometheus Agent can only be deployed as StatefulSet, which could be considered as “cluster-wide” strategy, meaning one or several high-availability Prometheus Agents are responsible for scraping metrics of the whole cluster. Though this works well for many use cases, some use cases may indeed prefer a “node-specific” strategy (DaemonSet), where Prometheus Agent pods scale with the nodes and only scrape the metrics from the targets located on the same node.https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/proposals/accepted/scrapeconfig-graduation/Mon, 01 Jan 0001 00:00:00 +0000https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/proposals/accepted/scrapeconfig-graduation/Owners: mviswanathsai Status: Accepted Related Tickets: Graduate The ScrapeConfig CRD To v1beta1 Other docs: ScrapeConfig Design Proposal Kubernetes API versioning Why # The goal of this proposal is to pave the way to graduate the ScrapeConfig CRD in the Prometheus Operator to beta. We aim to do this by building a 1:1 relationship with the Prometheus scrape_config. By enhancing the Service Discovery support, aligning the CRD fields, and standardizing configurations.https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/proposals/accepted/remote-write/Mon, 01 Jan 0001 00:00:00 +0000https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/proposals/accepted/remote-write/Owners: @superbrothers Status: Accepted Related Tickets: #6508 Other docs: n/a TL;DR # This design doc proposes RemoteWrite CRD, which enables cluster admins to delegate the ability to configure Prometheus remote_rewrite configuration to application developers/operators. Why # The Prometheus remote_write configuration is defined in the Prometheus CRD. Currently, the configuration data generation is the responsibility of cluster admins. Goals # The main goal is to enable application developers/operators to self-service the remote write, and configure how the client sends metrics to the remote endpoint.https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/proposals/accepted/zone-aware-sharding/Mon, 01 Jan 0001 00:00:00 +0000https://deploy-preview-154--sleepy-hopper-0fdb6b.netlify.app/docs/proposals/accepted/zone-aware-sharding/Owners: arnecls Status: Accepted Related Tickets: #6437 Other docs: Well known kubernetes labels AWS zone names GCP zone names Shard Autoscaling design proposal. This proposal describes how we can implement zone-aware sharding by adding support for custom labels and zone configuration options to the existing Prometheus configuration resources. Why # When running large, multi-zone clusters, Prometheus scraping can lead to an increase in inter-zone traffic costs. A solution would be to deploy 1 Prometheus shard per zone and configure each shard to scrape only the targets local to its zone.