Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update PrometheusAdapter config based on "MetricRules" objects #2504

Open
eero-t opened this issue Sep 5, 2024 · 7 comments
Open

Update PrometheusAdapter config based on "MetricRules" objects #2504

eero-t opened this issue Sep 5, 2024 · 7 comments

Comments

@eero-t
Copy link

eero-t commented Sep 5, 2024

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

Copy link

dosubot bot commented Sep 5, 2024

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
Copy link
Member

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
Copy link
Author

eero-t commented Sep 5, 2024

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
Copy link

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 simonpasquier transferred this issue from prometheus-operator/prometheus-operator Sep 6, 2024
@simonpasquier
Copy link
Contributor

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

@simonpasquier
Copy link
Contributor

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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants