Skip to main content
Version: 6.2

Configure Collection and Verify

Configure the Collection Configurations​

In each SA Data Collector configuration, repeat the block between the #@instance-block-begin and #@instance-block-end markers for each instance. For pg_objects, use a separate block for each monitored database.

Replace the connection tokens, including:

  • PG_CLUSTER, PG_HOST, PG_INSTANCE, PG_PORT, and PG_DB
  • PG_ENVIRONMENT and PG_MON_USER
  • PG_CONN_PARAMS with sslmode=verify-full
  • the SA Data Storage addresses and the path to the root certificate
  • the Patroni, PgBouncer, and beats input ports if the corresponding tiers are used

After substitution, active configuration lines must not contain PG_*, ES_*, LST_* tokens or conditional generator markers.

Add the monitoring role password to the secure SA Data Collector keystore:

sudo -u logstash /app/logstash/bin/logstash-keystore \
  --path.settings /app/logstash/config add DB_PG_PWD

Validate the configurations with the standard SA Data Collector validation command. Then add a separate pipeline.id for each file in pipelines.yml and schedule a single service restart window. Restarting stops all pipelines on that node.

For Tier 2 and Tier 3, configure the SAF Beat application filebeat_postgresql_logs. It reads jsonlog and sends data to pg_logs; pgaudit events are separated within the pipeline.

Verify the Data Flow​

Check that documents appear in all indexes for the selected maturity tiers. The base profile requires db_metrics, db_activity, db_replication, db_statements, and db_meta.

Open DB Observability: Collection Health and verify that:

  • every instance appears in the sources table
  • the PostgreSQL version is marked as supported
  • the collection role has pg_monitor and is not a superuser
  • collection delay does not exceed the threshold
  • active and inactive scenarios match the source configuration

Verify Module Objects​

Check the utility objects with read-only commands:

export SAF_PASSWORD='<password>'
./bin/make_rsm.py show --host <SEARCH_ANYWHERE_FRAMEWORK_HOST>:5601 
./bin/apply_incident_types.py show --host <SEARCH_ANYWHERE_FRAMEWORK_HOST>:5601
./bin/make_sla_policies.py show --host <SEARCH_ANYWHERE_FRAMEWORK_HOST>:5601
./bin/make_ai_presets.py show --host <SEARCH_ANYWHERE_FRAMEWORK_HOST>:5601
./bin/make_lookups.py show --host <SEARCH_ANYWHERE_FRAMEWORK_HOST>:5601
./bin/make_custom_icons.py show <SEARCH_ANYWHERE_FRAMEWORK_HOST> <SSH_USER>

Verify that the db_00_lookup_refresh and db_00_thresholds_seed jobs completed without errors. Instances should appear in db_instances, and default values should appear in db_thresholds.

Open all eight dashboards and test navigation between them. Then check the cluster, instance, and extension assets in Inventory, the DB Observability: Databases health model services in Service Monitor Toolkit, and the db_incident type in Incident Manager.

Verify that the platform has installed the service task for calculating SLA. If the task document is missing, SLA states do not change even though the incident card shows no error.

Initial Calculations

A new asset appears according to the Inventory schedule, the health model is recalculated separately, and Service Monitor Toolkit metrics follow their own schedules. A gray value immediately after installation does not indicate an error.