mirror of
https://github.com/neondatabase/neon.git
synced 2026-01-14 17:02:56 +00:00
## Problem When client specifies `application_name`, pgbouncer propagates it to the Postgres. Yet, if client doesn't do it, we have hard time figuring out who opens a lot of Postgres connections (including the `cloud_admin` ones). See this investigation as an example: https://neondb.slack.com/archives/C0836R0RZ0D ## Summary of changes I haven't found this documented, but it looks like pgbouncer accepts standard Postgres connstring parameters in the connstring in the `[databases]` section, so put the default `application_name=pgbouncer` there. That way, we will always see who opens Postgres connections. I did tests, and if client specifies a `application_name`, pgbouncer overrides this default, so it only works if it's not specified or set to blank `&application_name=` in the connection string. This is the last place we could potentially open some Postgres connections without `application_name`. Everything else should be either of two: 1. Direct client connections without `application_name`, but these should be strictly non-`cloud_admin` ones 2. Some ad-hoc internal connections, so if we see spikes of unidentified `cloud_admin` connections, we will need to investigate it again. Fixes neondatabase/cloud#20948
Compute Configuration
These files are the configuration files for various other pieces of software that will be running in the compute alongside Postgres.
sql_exporter
Adding a sql_exporter Metric
We use sql_exporter to export various metrics from Postgres. In order to add
a metric, you will need to create two files: a libsonnet and a sql file. You
will then import the libsonnet file in one of the collector files, and the
sql file will be imported in the libsonnet file.
In the event your statistic is an LSN, you may want to cast it to a float8
because Prometheus only supports floats. It's probably fine because float8 can
store integers from -2^53 to +2^53 exactly.