according to Prometheus-operator documentation we should be able to supply our additional configuration easily via secret file. Does anybody actually succeed this step? I have several questions:
file_sd_configs:
and if so how to supply those files into prometheus manifest file?Regardless of those questions I have hard time to add the additional configuration. I basically followed exact steps from documentation, and here is my observations:
cat prometheus-additional.yaml
- job_name: "prometheus-custom"
static_configs:
- targets: ["localhost:9090"]
kubectl create secret generic additional-scrape-configs --from-file=prometheus-additional.yaml
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
name: prometheus
spec:
replicas: 2
resources:
requests:
memory: 400Mi
additionalScrapeConfigs:
name: additional-scrape-configs
key: prometheus-additional.yaml
kubectl apply -f prometheus.yaml
kubectl logs prometheus-prometheus-0 -c prometheus
level=info ts=2019-12-05T18:07:30.217852541Z caller=main.go:302 msg="Starting Prometheus" version=" (version=2.7.1, branch=HEAD, revision=62e591f928ddf6b3468308b7ac1de1c63aa7fcf3)"
level=info ts=2019-12-05T18:07:30.217916972Z caller=main.go:303 build_context="(go=go1.11.5, user=root@f9f82868fc43, date=20190131-11:16:59)"
level=info ts=2019-12-05T18:07:30.217971648Z caller=main.go:304 host_details="(Linux 4.19.3-300.fc29.x86_64 #1 SMP Wed Nov 21 15:27:25 UTC 2018 x86_64 prometheus-prometheus-0 (none))"
level=info ts=2019-12-05T18:07:30.217994128Z caller=main.go:305 fd_limits="(soft=1048576, hard=1048576)"
level=info ts=2019-12-05T18:07:30.218236509Z caller=main.go:306 vm_limits="(soft=unlimited, hard=unlimited)"
level=info ts=2019-12-05T18:07:30.219359123Z caller=main.go:620 msg="Starting TSDB ..."
level=info ts=2019-12-05T18:07:30.219487263Z caller=web.go:416 component=web msg="Start listening for connections" address=0.0.0.0:9090
level=info ts=2019-12-05T18:07:30.230944675Z caller=main.go:635 msg="TSDB started"
level=info ts=2019-12-05T18:07:30.231037536Z caller=main.go:695 msg="Loading configuration file" filename=/etc/prometheus/config_out/prometheus.env.yaml
level=info ts=2019-12-05T18:07:30.23125837Z caller=main.go:722 msg="Completed loading of configuration file" filename=/etc/prometheus/config_out/prometheus.env.yaml
level=info ts=2019-12-05T18:07:30.231294106Z caller=main.go:589 msg="Server is ready to receive web requests."
level=info ts=2019-12-05T18:07:33.568068248Z caller=main.go:695 msg="Loading configuration file" filename=/etc/prometheus/config_out/prometheus.env.yaml
level=info ts=2019-12-05T18:07:33.568305994Z caller=main.go:722 msg="Completed loading of configuration file" filename=/etc/prometheus/config_out/prometheus.env.yaml
And, when I logged into prometheus pod I don't see any additional configuration either, and when I check my prometheus web console I don't see any of my configurations.
Prometheus can reload its configuration at runtime. If the new configuration is not well-formed, the changes will not be applied. A configuration reload is triggered by sending a SIGHUP to the Prometheus process or sending a HTTP POST request to the /-/reload endpoint (when the --web.enable-lifecycle flag is enabled).
The service file tells systemd to run Prometheus as the prometheus user, with the configuration file located in the /etc/prometheus/prometheus. yml directory and to store its data in the /var/lib/prometheus directory.
The difference between stable/prometheus and stable/prometheus-operator is that Operator has built-in Grafana with a set of ready for use dashboards and set of ServiceMonitors to collect metrics from a cluster's services such as the CoreDNS, API Server, Scheduler, etc.
The operator uses ServiceMonitors to define a set of targets to be monitored by Prometheus. It uses label selectors to define which Services to monitor, the namespaces to look for, and the port on which the metrics are exposed.
Turns out, the prometheus-operator still relies on serviceMonitorSelector: {} part of the manifest file according to this ticket. Therefore in order to add additional configuration we need to have the following manifest: where prometheus-config.yaml will contain prometheus scrape rules and deployed via secrets to prometheus cluster.
If you are using this version or later, use the additional scrape configs feature rather than the method described here. Before going down this rabbit hole, be warned that I am presenting a temporary work around until Prometheus Operator has better support for your use case that requires custom configuration.
However, since v0.19.0, this hack is not longer needed. Prometheus Operator now allows you to include additional configs that will be merged with the configs that Prometheus Operator automatically generates. If you are using this version or later, use the additional scrape configs feature rather than the method described here.
If you are running the Prometheus Operator (e.g. with kube-prometheus-stack) then you can specify additional scrape config jobs to monitor your custom services. An additional scrape config uses regex evaluation to find matching services en masse, and targets a set of services based on label, annotation, namespace, or name.
Turns out, the prometheus-operator still relies on serviceMonitorSelector: {}
part of the manifest file according to this ticket. Therefore in order to add additional configuration we need to have the following manifest:
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
name: prometheus
spec:
replicas: 2
resources:
requests:
memory: 400Mi
additionalScrapeConfigs:
name: prometheus-config
key: prometheus-config.yaml
serviceMonitorSelector: {}
where prometheus-config.yaml
will contain prometheus scrape rules and deployed via secrets to prometheus cluster. I also found empirically that current prometheus-operator does not support file_sd_configs
in prometheus configuration (sad) and someone need to write full rules in prometheus-config.yaml
file.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With