3.1. Configuration File #

The main configuration file is located in /etc/pgpro-otel-collector/basic.yml and is used by default. It consists of the following main sections:

  • Receiver parameters

  • Processor parameters

  • Exporter parameters

  • Pipeline parameters

  • Additional and optional parameters

Sections can be arranged in any order. At the top level, the configuration file structure looks as follows:

receivers:
  # Section for specifying receivers responsible for data collection
processors:
  # Section for specifying processors responsible for the intermediate processing of the data
exporters:
  # Section for describing exporters responsible for sending data
service:
  pipelines:
    # Section for specifying pipelines from the start of the data collection to its transmission

Depending on the administrator's goals, the configuration file can be extended with the following components and their parameters.

Receivers:

  • the postgrespro receiver for collecting Postgres Pro metrics

  • the file_log receiver and the resource and attributes processors for collecting Postgres Pro logs

  • the host_metrics receiver for collecting metrics from the operating system

    Important

    hostmetrics has been renamed to host_metrics to comply with the component naming convention. The deprecated alias is still supported but produces warnings and will be completely removed in future releases. Update your configuration accordingly.

  • the journald receiver and the resource, attributes, batch, and transform processors for collecting logs from the systemd journal

  • the otlp receiver for collecting metrics and logs in the OTLP format

Exporters:

  • the kafka exporter for sending logs and metrics to Apache Kafka

  • the otlp_http exporter for sending data to an OTLP-compatible storage

    Important

    otlphttp has been renamed to otlp_http to comply with the component naming convention. The deprecated alias is still supported but produces warnings and will be completely removed in future releases. Update your configuration accordingly.

  • the prometheus exporter for publishing data in the format compatible with Prometheus

  • the prometheus_remote_write exporter for sending metrics to Prometheus-compatible systems via the remote write protocol

Additionally, all added components must be organized into a pipeline in the service.pipelines section.

At the more detailed level, the configuration file structure looks as follows:

exporters:
  otlp_http/logs:
    # Setting up the otlp_http exporter for sending logs
  otlp_http/metrics:
    # Setting up the otlp_http exporter for sending metrics
  prometheus:
    # Setting up the prometheus exporter for publishing metrics
processors:
  attributes/convert:
    # Setting up the attributes processor for processing log records
  resource:
    # Setting up the resource processor for processing log records
receivers:
  postgrespro:
    # Setting up a receiver for collecting metrics from DBMS
  file_log:
    # Setting up a receiver for collecting logs
  host_metrics:
    # Setting up a receiver for collecting metrics from the operating system
  journald:
    # Setting up a receiver for collecting logs from the systemd journal
service:
  extensions: []
  pipelines:
    # Pipeline for log collection, processing and transmission
    logs:
      receivers:
        - file_log
        - journald
      processors:
        - resource
        - attributes/convert
      exporters:
        - otlp_http/logs
    # Pipeline for collecting, processing, and sending metrics
    metrics:
      receivers:
        - postgrespro
        - host_metrics
      processors:
      exporters:
        - prometheus
        - otlp_http/metrics

The OpenTelemetry Collector architecture allows using the same component multiple times. For example, you can use several copies of the postgrespro receiver to collect metrics from different DBMS instances. Similarly, numerous copies of the otlp_http exporter can be used for exporting metrics and logs to various storages, ensuring the data stream branching.

To specify several copies of the components, use the component/name notation, where:

  • component is the name of the component (receiver, processor, or exporter)

  • name is an additional custom name

The component/name notation is needed for forming the component unique IDs, which are then used in pipelines. For example: otlp_http/logs_main, postgrespro/primary, postgrespro/standby.

An example of using several copies of the same component:

receivers:
  # ...
processors:
  # ...
exporters:
  # Two copies of the otlp_http exporter are used for sending data to different destinations
  otlp_http/logs_elastic:
    endpoint: https://elastic.example.org
  otlp_http/logs_ppem:
    endpoint: https://ppem.example.org
service:
  extensions: []
  pipelines:
    logs:
      receivers:
        # ...
      processors:
        # ...
      # After the log records are collected and processed, they are transmitted in two directions
      exporters:
        - otlp_http/logs_elastic
        - otlp_http/logs_ppem

Thus, by populating the configuration file, you can flexibly define the parameters for collecting, processing, and sending data.

The collector functionality can be expanded with auxiliary configuration files located in the /usr/share/doc/pgpro-otel-collector/examples directory. Special attention should be paid to the postgrespro receiver: it supports a wide range of data collection tools, but only the minimal set is included in the configuration by default, most of the plugins being disabled. Before enabling any plugins, ensure that statistics are available on the database instance side.

Warning

Enabling extra plugins can lead to high overhead (data collection costs) and should be considered carefully.