There are a few reasons, why one may want to provide a custom configuration to Prometheus instances, instead of having the Prometheus Operator generate the configuration based on
Note that custom configurations are not the primary goal the Prometheus Operator is solving. Changes made in the Prometheus Operator, may affect custom configurations in a breaking way. Additionally the Prometheus Operator attempts to generate configurations in a forward and backward compatible way, with custom configurations, this is up to the user to manage gracefully.
Use cases include:
Note that because the Prometheus Operator does not generate the Prometheus configuration in this case, any fields of the Prometheus resource, which influence the configuration will have no effect, and one has to specify this explicitly. The features that will not be supported, meaning they will have to be configured manually:
serviceMonitorSelector: Auto-generating Prometheus configuration from
ServiceMonitorobjects. This means, that creating
ServiceMonitorobjects is not how a Prometheus instance is configured, but rather the raw configuration has to be written.
alerting: Alertmanager discovery as available in the Prometheus object is translated to the Prometheus configuration, meaning this configuration has to be done manually.
In order to enable to specify a custom configuration, the
serviceMonitorSelector field has to be left empty. When the
serviceMonitorSelector field is empty, the Prometheus Operator will not attempt to manage the
Secret, that contains the Prometheus configuration. The
Secret, that contains the Prometheus configuration is called
prometheus-<name-of-prometheus-object>, in the same namespace as the Prometheus object. Within this
Secret, the key that contains the Prometheus configuration is called