🚨 Telegraf Error Guide: '[inputs.postgresql_extensible] connect: connection refused' — Fix Postgres Connectivity

Overview

The postgresql_extensible input opens a libpq-style connection to PostgreSQL and runs configured queries. When nothing is accepting connections at the target host and port, the Go Postgres driver returns a dial error and Telegraf logs it each interval:

2026-07-12T12:00:00Z E! [inputs.postgresql_extensible] Error in plugin: dial tcp 10.0.0.5:5432: connect: connection refused

Once the server is reachable, a second class of failure surfaces at the authentication or TLS layer instead:

E! [inputs.postgresql_extensible] Error in plugin: pq: no pg_hba.conf entry for host "10.0.0.50", user "telegraf", database "postgres", SSL off

Telegraf keeps running other inputs, but no Postgres metrics are produced until the connection succeeds.

Symptoms

• All postgresql* metrics are missing while other inputs report normally.
• journalctl -u telegraf repeats connect: connection refused or no pg_hba.conf entry on each interval.
• psql -h 10.0.0.5 -p 5432 from the Telegraf host fails the same way, confirming it is not a Telegraf bug.
• Local connections on the DB host succeed but remote ones are refused — a listen_addresses symptom.
• The error changed from connection refused to an SSL/pg_hba.conf message after Postgres started listening.

Common Root Causes

• Postgres not running or wrong port — the service is down, or listens on 5433/a container-mapped port rather than 5432.
• listen_addresses too narrow — postgresql.conf has listen_addresses = 'localhost', so remote TCP connections are refused.
• pg_hba.conf rejects the host/user — no matching entry for the Telegraf host’s IP, user, or database, producing no pg_hba.conf entry.
• sslmode mismatch — the server requires SSL but the DSN sets sslmode=disable, or vice versa.
• Malformed address DSN — wrong key-value/URI syntax so the driver dials the default host/port instead of the intended one.
• Firewall / security group — a host firewall or cloud security group blocks TCP/5432 from the Telegraf host.
• Wrong host in cloud/managed DB — pointing at an instance IP instead of the managed endpoint, or an old IP after a failover.

Diagnostic Workflow

First reproduce the connection with psql from the exact Telegraf host. If it also refuses, the problem is Postgres or the network, not Telegraf:

# Is the port even open from here?
nc -z -v 10.0.0.5 5432

# Reproduce the actual connection and auth path
PGPASSWORD="${PG_PASSWORD}" psql "host=10.0.0.5 port=5432 user=telegraf dbname=postgres sslmode=require" -c 'select 1;'

On the database host, confirm Postgres is listening on a routable address and the right port:

sudo ss -ltnp | grep 5432
grep -E '^listen_addresses|^port' /etc/postgresql/*/main/postgresql.conf

Set listen_addresses to accept remote connections and reload:

# postgresql.conf
listen_addresses = '*'      # or a specific interface like '10.0.0.5'
port = 5432

Add a pg_hba.conf entry for the Telegraf host and a scoped, read-only user:

# pg_hba.conf — allow the Telegraf host over TLS
hostssl  postgres  telegraf  10.0.0.50/32  scram-sha-256

sudo systemctl reload postgresql

Configure the input with a correct DSN. The postgresql_extensible address accepts libpq key-value form, with sslmode matching the server:

[[inputs.postgresql_extensible]]
  address = "host=10.0.0.5 port=5432 user=telegraf password=${PG_PASSWORD} dbname=postgres sslmode=require"
  # URI form also works:
  # address = "postgres://telegraf:${PG_PASSWORD}@10.0.0.5:5432/postgres?sslmode=require"

  [[inputs.postgresql_extensible.query]]
    sqlquery = "SELECT * FROM pg_stat_database"
    version = 901
    withdbname = false
    tagvalue = ""

Run only this input with debug to confirm the connection and queries succeed:

telegraf --config /etc/telegraf/telegraf.conf --test --input-filter postgresql_extensible --debug

Example Root Cause Analysis

A newly provisioned monitoring host logged [inputs.postgresql_extensible] ... dial tcp 10.0.0.5:5432: connect: connection refused for a database that the application servers were happily using. nc -z -v 10.0.0.5 5432 from the Telegraf host was refused, yet psql -h localhost worked fine on the DB host itself. Checking postgresql.conf showed listen_addresses = 'localhost' — the default from the base image — so Postgres only bound the loopback interface and refused every remote TCP connection.

Setting listen_addresses = '*', adding a hostssl ... 10.0.0.50/32 scram-sha-256 line to pg_hba.conf, and reloading Postgres made the Telegraf scrape connect on the next interval. The lesson: connection refused from a healthy database is almost always listen_addresses binding loopback only — verify the listener with ss on the DB host before suspecting firewalls or Telegraf.

Prevention Best Practices

• Reproduce the exact DSN with psql from the Telegraf host during onboarding; it exercises port, auth, and TLS in one shot.
• Set listen_addresses to a specific routable interface (not just localhost) and keep the port explicit in config management.
• Add a dedicated, least-privilege monitoring user with a scoped pg_hba.conf entry (/32 host) using scram-sha-256.
• Match sslmode on both sides; prefer require/verify-full with a sslrootcert over disable.
• Store the password in ${PG_PASSWORD} referenced from config, never inline in version control.
• For managed/cloud databases, target the stable endpoint hostname (not an instance IP) so failovers do not strand the collector.

Quick Command Reference

# Port reachability from the Telegraf host
nc -z -v 10.0.0.5 5432

# Reproduce the full connection and auth
PGPASSWORD="${PG_PASSWORD}" psql "host=10.0.0.5 port=5432 user=telegraf dbname=postgres sslmode=require" -c 'select 1;'

# On the DB host: confirm listener and config
sudo ss -ltnp | grep 5432
grep -E '^listen_addresses|^port' /etc/postgresql/*/main/postgresql.conf

# Run only the postgresql input with debug
telegraf --config /etc/telegraf/telegraf.conf --test --input-filter postgresql_extensible --debug

Related Guides

• Telegraf HTTP connection refused
• Telegraf SQL Server login failed
• Telegraf output context deadline exceeded

More fixes in the Telegraf guides.

Conclusion

[inputs.postgresql_extensible] ... connect: connection refused means nothing accepted a TCP connection at the target host and port — most often Postgres bound only localhost, a wrong port, or a firewall. Reproduce with psql from the Telegraf host, verify the listener with ss on the database, and set listen_addresses, a scoped pg_hba.conf entry, and a matching sslmode in the address DSN. Once the connection and auth align, Postgres metrics collect reliably.