pgpro-otel-collector can be run by an unprivileged user. In some cases, however, read access to the log directory and log files may be required on the operating system side for collecting logs from the DBMS instance.
To read the logs, it is sufficient to use the group under
which the DBMS instance is running. To do this, the group
needs to be granted read access to log files, and then the
user under which the collector is running should be added to
the same group. Typically, this is the
postgres group.
Grant read permissions to the group (the directory path may vary):
sudo chmod g+rx /var/log/postgresql/ sudo chmod g+r /var/log/postgresql/*
Add the user otelcol to the group
postgres:
sudo usermod --groups=postgres otelcol
Now the collector should be able to read the existing log files.
Additionally, it is necessary to adjust the DBMS instance
configuration so that new log files are created with the required
access permissions. This is achieved by modifying the
log_file_mode parameter and reloading the configuration.
The parameter can be updated either directly in the configuration file,
via ALTER SYSTEM, or through automation tools and IaC
(Infrastructure as Code) solutions.
In the example below, the change is made by connecting to the
DBMS instance and using ALTER SYSTEM:
psql -U postgres -c 'ALTER SYSTEM SET log_file_mode TO "0640"' psql -U postgres -c 'SELECT pg_reload_conf()'
The DBMS user setup consists of the following steps:
Creating and configuring the privileges of the DBMS user under which the collector connects to the DBMS instance.
Setting up HBA authorization rules that will allow the collector to connect to the DBMS instance.
Configuring additional privileges for function execution; this step is optional and is only required if you actually want to enable the collection of the corresponding data.
Set a password when creating a user:
sudo -u postgres createuser --pwprompt otelcol
To set up permissions, connect to the DBMS instance and run the following commands:
GRANT pg_monitor TO otelcol;
When using plugins that require connections to other databases (such as collecting tables, indexes, or bloat), the HBA (Host-Based Authentication) rules must be aligned with the collector rules:
The databases listed in the plugin configuration must be allowed in the HBA configuration.
If the collector is configured to collect data from all databases, then HBA rules should allow connection to all of them.
PostgreSQL DBMS supports a wide variety of authentication methods. When setting up HBA rules, focus on the method that is used in your case.
The example below shows how to set up access to the database
postgres using the
scram-sha-256 method.
vi pg_hba.conf local postgres otelcol scram-sha-256 host postgres otelcol 127.0.0.1/32 scram-sha-256
In this example, the connection capability is limited to only
the postgres database; if the collector is
configured to collect data from other databases, the
corresponding allowing rules must be added to the HBA
configuration.
Reload the DBMS instance configuration for the changes to take effect:
sudo -u postgres psql -c 'SELECT pg_reload_conf()'
Different types of collected data require access to various internal functions. Access to these functions is restricted for general users, as they can reveal confidential information. Therefore, granting access should be coordinated with the company's security policies.
See Section 3.1 for information about the access privileges required for seamless operation.
The connection parameters for the DBMS instance are managed
in the postgrespro receiver configuration of the
collector configuration file. The user credentials should be
specified in the endpoint,
database, username, and
password parameters (it is possible to pass
the password through an environment variable):
receivers:
postgrespro:
transport: tcp
endpoint: localhost:5432
database: postgres
username: otelcol
password: ${env:POSTGRESQL_PASSWORD}
You can set up TLS (Transport Layer Security) when using exporters. Each exporter can be configured separately, while the configuration format remains the same for all. For more details, refer to the OpenTelemetry documentation.
An example of the otlphttp exporter
configuration:
exporters:
otlphttp:
endpoint: "https://ppem.example.org"
tls:
insecure: false
ca_file: server.crt
cert_file: client.crt
key_file: client.key
min_version: "1.1"
max_version: "1.2"
Allowlists and denylists provide granular control over metrics collection from specific databases and objects. This is particularly useful when security policies mandate restricting access to certain databases while allowing collection from others.
Global allowlists and denylists can be configured for plugins at the receiver level. Here is a general example of such configuration:
receivers:
postgrespro:
acl:
databases:
allow:
- name: postgres
schemas:
- name: public
tables:
- name: table
- name: table_index
indexes:
- name: index1
- name: index2
functions:
- name: function1
deny:
- name: db
schemas:
- name: schema
tables:
- name: table
Where:
The acl.allow section defines which databases (and their
nested objects) are collected by plugins by default.
The acl.deny section specifies databases and objects from
which pgpro-otel-collector is prohibited from
collecting metrics.
Let's consider a specific example of excluding the zabbix
database from data collection:
receivers:
postgrespro:
max_threads: 3
collection_interval: 60s
initial_delay: 1s
transport: tcp
endpoint: localhost:5432
database: postgres
username: postgres
password: ${env:POSTGRESQL_PASSWORD}
metrics: null
acl:
databases:
allow:
- name: postgres
deny:
- name: zabbix
plugins:
activity:
enabled: true
bgwriter:
enabled: true
locks:
enabled: true
version:
enabled: true
wal:
enabled: true
cache:
enabled: true
In this example, metrics are collected from the postgres
database by default, while collection from the zabbix
database is prohibited regardless of other settings.
Individual plugins can have their own databases
configuration section:
tables:
enabled: true
databases:
- name: demo
In this case, plugins override acl.allow but still adhere
to the acl.deny restrictions.