Google Managed Prometheus unable to set scrape_config? #545
-
|
Is it possible when using managed collection to define I've been scouring the docs and CRDs, but I'm not sure if I'm missing something, or if this just isn't possible. There doesn't appear to be a way using any of the CRDs Our use case is that we're using a third-party service, who exposes a metrics endpoint for us to scrape. |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 1 reply
-
|
The scrape config interface for managed collection is intentionally restricted to PodMonitorings and ClusterPodMonitorings for scalabilty and supportability reasons; if we allowed arbitrary scraping there is no way we could guarantee an SLA for managed collection. If your third party service exposes metrics on a pod within a cluster (or can appear as that way) then yes, you could use managed collection, otherwise you'll have to use one of the other collection options (self-deployed collection or OTel) for this use case. There's no harm in running more than one collection option at a time. |
Beta Was this translation helpful? Give feedback.
-
|
It seems like you're running into limitations with Google Managed Prometheus regarding defining scrape_config resources. Unfortunately, from my understanding, there isn't a direct way to configure scrape_configs other than using podMonitoring or operatorConfig CRDs. If your use case involves scraping metrics from a third-party service, one alternative approach could be to explore whether the third-party service supports Prometheus metrics natively or if other integration options are available. Additionally, consider reaching out to Google Cloud support for further assistance or clarification on this matter. Just to let you know, the availability of certain features or configurations may vary depending on the specific managed service provider and their implementation of Prometheus. |
Beta Was this translation helpful? Give feedback.
-
|
Are you an AI? |
Beta Was this translation helpful? Give feedback.
The scrape config interface for managed collection is intentionally restricted to PodMonitorings and ClusterPodMonitorings for scalabilty and supportability reasons; if we allowed arbitrary scraping there is no way we could guarantee an SLA for managed collection. If your third party service exposes metrics on a pod within a cluster (or can appear as that way) then yes, you could use managed collection, otherwise you'll have to use one of the other collection options (self-deployed collection or OTel) for this use case. There's no harm in running more than one collection option at a time.