Update PrometheusAdapter config based on "MetricRules" objects

[eero-t]

Component(s)

No response

What is missing? Please describe.

Operator updating PrometheusAdapter config based on available MetricRules objects, similarly to how it already updates Prometheus config based on PodMonitor and ServiceMonitor objects.

Describe alternatives you've considered.

When one would want to automate installation of some component and its associated application metric rules...

• Helm refuses to overwrite existing config as it's already "owned" by another chart (kube-prometheus one), so user would need to manually edit the config
• User needs to restart PrometheusAdapther after config has been updated

This is rather aggravating and unfriendly. Operator providing automation for updating adapter config would IMHO make custom/external metrics much more usable!

Environment Information.

Environment

Kubernetes Version: 1.30
Prometheus-Operator Version: see https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack

[dosubot]

Hello, @eero-t! I'm here to assist you with any bugs, questions, or contributions you have. Let's work together to solve this issue.

The Prometheus Operator currently updates Prometheus configurations based on PodMonitor and ServiceMonitor objects using the podMonitorSelector and serviceMonitorSelector fields in the Prometheus custom resource definition (CRD) ^[1].

However, it does not automatically update the PrometheusAdapter configuration based on MetricRules objects. This means users often face challenges such as Helm refusing to overwrite existing configurations owned by another chart, necessitating manual edits and restarts of the PrometheusAdapter after updates.

Automating the update of the PrometheusAdapter configuration based on MetricRules objects would indeed enhance usability for custom/external metrics, making the process more user-friendly and reducing manual intervention.

To continue talking to Dosu, mention @dosu.

[ArthurSens]

For context, Prometheus Operator automates the deployment and configuration of Prometheus and related components, so far we've been automating components that we see as essential for a Prometheus-based monitoring stack, e.g. Alertmanager.

Prometheus-Adapter can be seen as Prometheus-related component, but I wouldn't say its essential for a Prometheus-based monitoring stack. At this point in time, I'd be against adding extra complexity to this codebase to support a component that is not widely used.

Let's keep the issue open though! If we see big demand from the community, it means I'm wrong :)

[eero-t]

Prometheus-Adapter can be seen as Prometheus-related component, but I wouldn't say its essential for a Prometheus-based monitoring stack. At this point in time, I'd be against adding extra complexity to this codebase to support a component that is not widely used.

Fair enough, but I would have thought most of the functionality to already be there:

• Monitoring creation & deletion of listed (monitor) object types
• Marshaling new monitor objects to internal structs & logging errors if that fails
• Maintaining list/map of those & creating new config when that changes
• Updating config for relevant Prometheus pod

And to need just minor changes & additions to support new object type, one containing these members: https://github.com/kubernetes-sigs/prometheus-adapter/blob/master/docs/sample-config.yaml ?

[nicolastakashi]

IIRC we already mentioned in the past about the deprecation of Prometheus Adapter, especially because it can be easily replaced by KEDA.

Maybe @slashpai can refresh me what we discussed in the past.

[simonpasquier]

Moved to https://github.com/prometheus-operator/kube-prometheus since it's more an ask for kube-prometheus than prometheus-operator itself.

[simonpasquier]

I second @ArthurSens that the Prometheus operator isn't the right place to support Prometheus adapter. Its API surface is already large enough + I have doubts about the future of the Prometheus adapter.

[simonpasquier]

https://docs.google.com/document/d/1FE4AQ8B49fYbKhfg4Tx0cui1V0eI4o3PxoqQPUwNEiU/edit#heading=h.sxa3e6gwwwq4 (notes from 2022-12-08)

prometheus-metrics-adapter: should we consider archiving? There’s now a good replacement, KEDA, with bigger scope (https://keda.sh/docs/1.4/scalers/prometheus/). Hasn’t been well-maintained, project needs a rewrite because the codebase is hard to understand, UX is suboptimal, debugging is very complex and tedious. Maybe write a migration guide rather than cleaning up KSM.