Few Parameters for Prometheus Configuration for Siebel CRM Monitoring

Prometheus has a vast number of configuration options which can be used depending on specific business requirements. Of those, we want to highlight a few that need careful balance between processing and storage needs vs latency of how soon metrics information is available in Prometheus from the exporters:

  • Scraping Interval: Defines how often Prometheus collects metrics.
  • Retention Policy: Dictates how long to store metrics in the time series database of Prometheus.
  • Evaluation Interval: Defines how often Prometheus evaluates rules.

These parameters are available in the SCM Git Repository in the file /flux-crm/apps/base/siebel_observability/prometheus.yaml.

In the sample section below, inside prometheus.yaml file, these define config variables global in scope that is, parameters that are valid in all other configuration contexts. They also serve as defaults for other configuration sections. Individual target specific configurations are also possible to be configured. Refer to Prometheus documentation for more details.

values:
   server:
      global:
         scrape_interval: 1m
         scrape_timeout: 10s
         evaluation_interval: 1m
      retention: "15d"

A scrape_config section specifies a set of targets and parameters describing how to scrape them. In the general case, one scrape configuration specifies a single job. In advanced configurations, this may change.

Targets may be statically configured via the static_configs parameter. Includes parameters like target IP address, scrape interval and more. Defined in

  • Git repository: <namespce>-helmcharts
  • File: <namespce>-helmcharts/prometheus/templates/configMap.yaml under prometheus.yml section

Here is a sample section containing these parameters:

prometheus.yml: |-
   scrape_configs:
      - job_name: jmx-exporter
        scrape_interval: 5s
        kubernetes_sd_configs:
        - role: endpoints
          namespaces:
            names:
            - {{ .Release.Namespace }}
        relabel_configs:
        - action: keep
          source_labels:
          - __meta_kubernetes_endpoint_port_name
          regex: jmx-metrics 

Targets can be dynamically discovered using one of the supported service-discovery mechanisms. For example, Kubernetes service discovery, DNS-based service discovery and so on.

Note: Once you update any file in any helmchart, you have to increment "version" in the respective Chart.yaml for the deployed state to get reconciled to your declared state in the yaml files.

For the latest Prometheus configuration options, refer Prometheus product documentation.