3 ms·
This seems especially important if you want to offer Prometheus as SaaS. Your customers won't want to run their own Prometheus installs (that's what they pay
by slgeorge 8y ago
This seems especially important if you want to offer Prometheus as SaaS.
Your customers won't want to run their own Prometheus installs (that's what they pay you for, after all),
and asking customers to open their firewalls so that your Prometheus can discover and scrape their
infrastructure is probably a non-starter.
At Weaveworks we provide Prometheus as a SaaS using Cortex, which is how the project was started. For our service we have an agent that installs a Prometheus agent (and some other ones) on the customers K8s cluster.
The upsides of running the agent on their side is that they benefit from Prometheus' automatic service discovery. They can also use standard Prometheus configuration and scrapers to get the full capabilities for their environment.
There are also situations where the user wants to continue to run their own Prometheus, but down sample and send a limited number of metrics for long-term storage in the Weave Cloud SaaS. This can be done with one line in a standard Prometheus.
It's true that running the agent takes resources, I think the benefits are worth it. For most people the key question is getting the full value from their metrics data to enable better development and operations.
[NOTE]: Full Disclosure I work at Weaveworks where we provide Prometheus-as-a-Service (https://www.weave.works/features/prometheus-monitoring/ https://www.weave.works/features/prometheus-monitoring/)