Prometheus Exporter#

Installation#

The Prometheus exporter app can be installed using EDA App Store or by running the app-install workflow with kubectl:

apiVersion: core.eda.nokia.com/v1
kind: Workflow
metadata:
  name: prom-exporter-install
  namespace: eda-system
spec:
  type: app-installer
  input:
    app: prom-exporter
    catalog: eda-catalog-builtin-apps
    operation: install
    vendor: nokia
    version:
      type: semver
      value: v2.0.0

cat << 'EOF' | kubectl apply -f -
apiVersion: core.eda.nokia.com/v1
kind: Workflow
metadata:
  name: prom-exporter-install
  namespace: eda-system
spec:
  type: app-installer
  input:
    app: prom-exporter
    catalog: eda-catalog-builtin-apps
    operation: install
    vendor: nokia
    version:
      type: semver
      value: v2.0.0
EOF

Configuration#

After installing the app you can configure the metrics you wish to be exported by defining an EDB path (also referred to as jsPath) and, optionally, a fields list and a where EQL statement. You can check what is returned by the path using the EDA Query UI or edactl.

At every scrape request the app will retrieve the configured paths and fields and automatically generate the metric name, its labels and its value based on the path, fields and values received back from EDA.

If your use case requires additional customizations, the app supports:

• Renaming metric names using regex and replacement patterns.
• Adding static or dynamic labels to metrics.
• Mapping non-numeric values to Prometheus-compatible numeric values.

Scrape requests from Prometheus must be directed to the URL https://EDA_API_ADDRESS/core/httpproxy/v1/prometheus-exporter/metrics.

Export Custom Resource#

The app is configured using an Export Custom Resource (CR) from the prom.eda.nokia.com API group that groups a list of exports together.

Each export definition includes:

• Path^Required: The EDB path to export, e.g., .namespace.node.srl.interface.statistics.
• Fields: A list of fields to expose as part of the metric. If not defined all fields under the configured path are exposed.
• Where: A filter clause for querying, e.g., oper-state = down or .interface.name != "mgmt0".
• Prefix: A prefix to prepend to all metrics exposed by this definition.
• Metric Name: Customization of metric names using regex and replacements.
• Labels: Static or dynamic labels to add to metrics.
• Mappings: Rules to map non-numeric values to numeric equivalents.

Here is an example of a Prometheus exporter custom resource:

apiVersion: prom.eda.nokia.com/v1alpha1
kind: Export
metadata:
  name: replaced-metrics
  namespace: eda-system
spec:
  exports:
    - path: .namespace.node.srl.interface.statistics
      metricName:
        regex: namespace_node_srl_(\w+)_statistics_(\w+)
        replacement: "${1}_${2}"

Metric customization#

The resulting Prometheus metrics are autogenerated based on the returned paths, fields and values. A metric is composed of the following parts:

• Name
• Labels
• Value

Name#

Metric names are derived from the provided jsPath and fields. For example:

• jsPath: .namespace.node.srl.interface.statistics
• Field: out-octets

The resulting metric name will be generated by following this process:

1. Strip the leading . (period) from the jsPath.

2. Remove all keys from the jsPath.

3. Replace all . (period) with an _ (underscore) in the jsPath

4. Replace every - (hyphen) with _ (underscore) in the jsPath and field name

5. Join the resulting jsPath and field name with and _ (underscore)

Customization#

Metric names can be customized to suit user needs in a simple or advanced way.

Simple#

Use the prefix field in the CR to add a prefix to all metric names.

apiVersion: prom.eda.nokia.com/v1alpha1
kind: Export
metadata:
  name: prefixed-metrics
  namespace: eda-system
spec:
  exports:
    - path: .namespace.node.srl.interface.statistics
      prefix: eda

The above configuration produces metrics starting with eda_ prefix. For example, the metric namespace_node_srl_interface_statistics_out_octets becomes: eda_namespace_node_srl_interface_statistics_out_octets.

Advanced#

Use the metricName field to apply regex-based transformations which has two components:

• Regex: Defines the pattern to match in the metric name.
• Replacement: Defines how the matched pattern should be replaced.

For example, if the metric name namespace_node_srl_interface_statistics_out_octets is too long, you can shorten it to interface_out_octets:

apiVersion: prom.eda.nokia.com/v1alpha1
kind: Export
metadata:
  name: replaced-metrics
  namespace: eda-system
spec:
  exports:
    - path: .namespace.node.srl.interface.statistics
      metricName:
        regex: namespace_node_srl_(\w+)_statistics_(\w+)
        replacement: "${1}_${2}"

Labels#

Labels add context and categorization to metrics. They are generated automatically from the jsPath keys and their values. For each key in the jsPath, a label name is a created using the path element name and the key name joined using an _.

In addition to jsPath-based labels, two types of additional labels can be defined:

Static Labels#

Predefined name-value pairs that are the same for all metrics in an export. The CR in the example below will result in metrics with 2 additional labels env=prod and region=us-west-1 added:

apiVersion: prom.eda.nokia.com/v1alpha1
kind: Export
metadata:
  name: static-labels-metric
  namespace: eda-system
spec:
  exports:
    - path: .namespace.node.srl.interface.statistics
      labels:
        static:
          - name: env
            value: prod
          - name: region
            value: us-west-1

Dynamic Labels#

Labels generated based on data from a specific path (EDB path/jsPath) and field, with optional regex transformations. Example:

apiVersion: prom.eda.nokia.com/v1alpha1
kind: Export
metadata:
  name: dynamic-labels-metric
  namespace: eda-system
spec:
  exports:
    - path: .namespace.node.srl.interface.statistics
      labels:
        dynamic:
          - path: .namespace.node.srl.interface
            field: description
          - path: .namespace.node.srl.platform.chassis
            field: type

The above example generates metrics based on the given path and adds 2 labels:

1. the interface description for which the metric is exposed
2. node's chassis type

Values#

Metric values are derived directly from the data at the specified path and field. If the raw value is not a numeric type that Prometheus can ingest, mappings are required to convert the value.

apiVersion: prom.eda.nokia.com/v1alpha1
kind: Export
metadata:
  name: mapped-values-metric
  namespace: eda-system
spec:
  exports:
    - path: .namespace.node.srl.interface
      fields:
        - admin-state
        - oper-state
      mappings:
        - source: "up"
          destination: "2"
        - source: "down"
          destination: "1"
        - source: "enable"
          destination: "2"
        - source: "disable"
          destination: "1"

The above Export maps non-numeric values from the fields into numeric values that can be ingested by Prometheus. The mapping rules are:

• up → 2
• down → 1
• enable → 2
• disable → 1

Metrics grouping#

Metrics grouping in the Prometheus exporter allows for efficient organization and selective scraping of metrics by Prometheus. Here's how it works:

By default, Prometheus scrapes all exported metrics from the endpoint: https://EDA_API_ADDRESS/core/httpproxy/v1/prometheus-exporter/metrics
This endpoint aggregates metrics from all Export CRs defined in the system.

Group-Specific Metrics Scraping#

To provide more control over which metrics are scraped, you can assign CRs to specific groups. When a group is specified in the CR, Prometheus can scrape only the metrics belonging to that group using a targeted endpoint: https://EDA_API_ADDRESS/core/httpproxy/v1/prometheus-exporter/metrics/{group}

Where {group} is the name of the group specified in the CR.

Groups are defined in the spec.group field of an Export CR. For example:

apiVersion: prom.eda.nokia.com/v1alpha1
kind: Export
metadata:
  name: metrics-grouping
  namespace: eda-system
spec:
  group: group1
  exports:
    - path: .namespace.node.srl.interface.statistics

cat << 'EOF' | kubectl apply -f -
apiVersion: prom.eda.nokia.com/v1alpha1
kind: Export
metadata:
  name: metrics-grouping
  namespace: eda-system
spec:
  group: group1
  exports:
    - path: .namespace.node.srl.interface.statistics
EOF

Use Cases for Grouping#

1. Selective Scraping:
   If you want Prometheus to scrape only specific metrics (e.g., metrics related to networking or storage), you can group the relevant CRs and use the group-specific endpoint.

2. Performance Optimization:
   By grouping metrics, you can reduce the load on the Prometheus server and the exporter by scraping only the necessary data.

3. Access Control:
   Different teams or systems can be assigned specific groups, ensuring each team accesses its relevant metrics.

Usage Examples#

Check out EDA Telemetry demo lab for Prometheus exporter usage examples.