Log Insights: Setup (CloudNativePG)

Log Insights setup for CloudNativePG (CNPG) looks different from the other platforms in these docs because of how CNPG handles logging.

Why this looks different

CNPG always writes Postgres’s log output as JSON to stdout, by design, not by configuration choice. Settings like log_destination, logging_collector, log_directory, and log_filename are on CNPG’s blocked parameter list, so its admission webhook rejects any attempt to set them. There’s no log_line_prefix-formatted text output anywhere to tail, which is what most of pganalyze’s other log ingestion methods (tailing, syslog) expect instead. Each log line looks like this:

{"level":"info","ts":"2025-12-09T00:32:20.823314307Z","logger":"postgres","msg":"record","logging_pod":"cluster-test1-1","record":{"log_time":"2025-12-09 00:32:20.822 UTC","user_name":"postgres","database_name":"postgres","process_id":"4003","connection_from":"[local]","session_id":"69376dbf.fa3","session_line_num":"1","command_tag":"SELECT","session_start_time":"2025-12-09 00:30:55 UTC","virtual_transaction_id":"2/81","transaction_id":"0","error_severity":"LOG","sql_state_code":"00000","message":"duration: 100.000 ms  statement: SELECT 1","application_name":"psql","backend_type":"client backend"}}

pganalyze’s field extraction is built for logger: "postgres" today; other loggers CNPG emits (notably pgaudit) aren’t parsed into structured fields yet.

The log forwarding pipeline

Getting CNPG logs into pganalyze takes two pieces working together: the collector exposes an OpenTelemetry (OTLP) logs endpoint (the same db_log_otel_server mechanism other platforms use, not unique to Kubernetes), and Vector runs as a DaemonSet, tailing Kubernetes pod logs, filtering down to your CNPG instance pods, reshaping CNPG’s JSON envelope into the OTLP log record format, and forwarding it to that endpoint. pganalyze provides and tests the reshaping transform for Vector, a VRL script maintained in the collector repository, used in the steps below.

A sidecar tailing Postgres’s log output directly, the usual pattern on other platforms, isn’t an option here: CNPG doesn’t support attaching sidecars to its managed instance pods through the normal Cluster spec, and its only extensibility point (the CNPG-I plugin framework) has no confirmed way to reach that log stream either. Collecting from Kubernetes and forwarding over OpenTelemetry, as above, is the supported path.

Setup

• Step 1: Configure the collector’s OTLP endpoint
• Step 2: Deploy Vector
• Step 3: Test and verify