Instalar y configurar NRDOT para el monitoreo de PostgreSQL con Helm

Puede instalar y configurar el monitoreo de PostgreSQL en Kubernetes usando el chart de Helm postgresql-otel. Opcionalmente, el chart también puede ejecutar un trabajo de configuración que crea el rol de monitoreo, sus permisos y la extensión pg_stat_statements.

Instalación guiada

Para instalar a través de la UI de New Relic en su lugar, vaya a one.newrelic.com > Integrations & Agents > PostgreSQL (Database 360). Esta página solo cubre la instalación manual.

Importante

El chart despliega el recolector como un despliegue de Kubernetes que se conecta a PostgreSQL de forma remota a través de la red, por lo que solo reporta métricas de PostgreSQL: sin métricas de host o infraestructura para la máquina en la que se ejecuta PostgreSQL. Monitorea una instancia de PostgreSQL por lanzamiento (se admiten múltiples bases de datos en esa instancia) y no configura TLS ni proveedores de credenciales de db_auth como la autenticación de IAM de AWS.

Requisitos previos a nivel de servidor

Se requiere PostgreSQL 14 o superior. Antes de instalar este chart (o habilitar el trabajo de configuración), los siguientes parámetros del servidor deben estar establecidos. No se puede crear pg_stat_statements sin shared_preload_libraries, y ese parámetro requiere un reinicio, por lo que nada que se ejecute dentro del clúster de Kubernetes puede hacerlo.

Parámetro	Valor
`shared_preload_libraries`	`pg_stat_statements`
`pg_stat_statements.track`	`ALL`
`pg_stat_statements.max`	`10000`
`pg_stat_statements.save`	`on`
`track_activity_query_size`	`4096`
`track_functions`	`all`

Autohospedado: configure estos valores en postgresql.conf y luego reinicie PostgreSQL. Algunas distribuciones necesitan que el paquete postgresql-contrib esté instalado para que pg_stat_statements esté disponible.
AWS RDS o Aurora: configúrelos en el grupo de parámetros de la base de datos, no en un archivo de configuración. track_activity_query_size y pg_stat_statements.max son parámetros estáticos; aplíquelos con apply_method: pending-reboot y luego reinicie la instancia. Aplicarlos inmediatamente falla con InvalidParameterCombination. Para Aurora, el nombre de la familia del grupo de parámetros debe coincidir exactamente con la versión principal de su motor, por ejemplo aurora-postgresql16.

Requisitos previos

Clave de licencia de New Relic válida.
Helm 3.0 o posterior, y kubectl configurado para acceder al clúster de Kubernetes.
Conectividad de red desde el clúster de Kubernetes al host de PostgreSQL (o extremo de RDS) y al puerto:
- Autohospedado: una ruta enrutada al host de PostgreSQL (VPN, emparejamiento o red compartida), resolución de DNS si es un nombre de host, y el pg_hba.conf del lado de PostgreSQL y el firewall deben permitir la IP de origen real de la conexión (que puede ser una puerta de enlace NAT, no la IP del pod en sí).
- AWS RDS: emparejamiento de VPC, una puerta de enlace de tránsito o ubicación de VPC compartida con la instancia de RDS, y el grupo de seguridad de RDS debe permitir el puerto de PostgreSQL (5432 por defecto) desde la fuente de salida del clúster.
Ya sea un rol de monitoreo que ya haya creado con sus permisos por base de datos, o credenciales de administrador de PostgreSQL para que el trabajo de configuración del chart pueda crearlos. Consulte Configurar las credenciales de monitoreo a continuación.

Cree el namespace

Cree el namespace en el que realizará la instalación. Debe existir antes de crear cualquier secreto en el siguiente paso, ya que helm install --create-namespace solo crea el namespace durante el paso de instalación final:

bash

$kubectl create namespace newrelic

Sugerencia

Establézcalo como el namespace predeterminado para el contexto kubectl actual para que no necesite pasar -n en cada comando a continuación:

bash

$kubectl config set-context --current --namespace=newrelic

Configurar las credenciales de monitoreo

Decida si desea que el trabajo de configuración del chart cree el rol de monitoreo de PostgreSQL y, de no ser así, cómo proporcionará sus credenciales:

Con este método no hay un trabajo de configuración, por lo que nada aquí le crea el rol de monitoreo. Antes de instalar el chart, créelo como superusuario. Ejecute esto una vez a nivel del clúster:

CREATE USER newrelic WITH LOGIN PASSWORD '<password>';
ALTER ROLE newrelic INHERIT;   -- required on PG15+, a no-op on PG14

Luego, ejecute esto en cada base de datos que planee listar en postgresql.databases:

CREATE SCHEMA IF NOT EXISTS otel;
GRANT USAGE ON SCHEMA otel TO newrelic;
GRANT USAGE ON SCHEMA public TO newrelic;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO newrelic;
GRANT pg_monitor TO newrelic;
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

Para más detalles, consulte el paso Configurar el usuario y los permisos de la base de datos para PostgreSQL autohospedado o PostgreSQL en RDS.

Configurará el nombre de usuario y la contraseña de monitoreo directamente en values.yaml en el siguiente paso.

Con este método tampoco hay un trabajo de configuración. Cree primero el rol de monitoreo y sus permisos por base de datos, exactamente como en el método de credenciales simples anterior. La única diferencia es dónde residen sus credenciales: en lugar de texto sin formato en values.yaml, almacénelas en un secreto de Kubernetes:

bash

$kubectl create secret generic postgres-monitor-creds \
>  --from-literal=username=<MONITORING_USERNAME> \
>  --from-literal=password='<MONITORING_PASSWORD>' \
>  -n newrelic

Con este método, el trabajo de configuración del chart crea el rol de monitoreo y, para cada base de datos en postgresql.databases, crea el esquema otel, otorga USAGE/SELECT/pg_monitor y crea la extensión pg_stat_statements. Tanto las credenciales de monitoreo como las de administrador deben proporcionarse como secretos de Kubernetes: el trabajo de configuración nunca acepta credenciales de administrador en texto sin formato, y habilitarlo también requiere credenciales de monitoreo basadas en secretos.

Cree un secreto con el nombre de usuario y la contraseña de monitoreo. Esta es la identidad que crea el trabajo de configuración y con la que se conecta el recolector:

bash

$kubectl create secret generic postgres-monitor-creds \
>  --from-literal=username=<MONITORING_USERNAME> \
>  --from-literal=password='<MONITORING_PASSWORD>' \
>  -n newrelic

El trabajo de configuración solo acepta credenciales de administrador mediante un secreto de Kubernetes (sin nombre de usuario/contraseña en texto sin formato en values.yaml). Esta credencial debe ser de superusuario (autohospedado) o un equivalente de rds_superuser (RDS), ya que necesita CREATE USER, CREATE SCHEMA y CREATE EXTENSION:
bash
```
$kubectl create secret generic postgres-admin-creds \
>  --from-literal=username=<ADMIN_USERNAME> \
>  --from-literal=password='<ADMIN_PASSWORD>' \
>  -n newrelic
```

Configurar los valores de Helm

Establezca postgresql.topology para que coincida con su entorno:

Valor	Descripción
`self-hosted`	PostgreSQL autohospedado, al que se accede a través de la red.
`rds`	PostgreSQL o Aurora en AWS RDS.

postgresql.databases es una lista obligatoria y no vacía. A diferencia de MySQL o SQL Server, PostgreSQL no tiene un modo de monitorear cada base de datos: una conexión tiene como objetivo una base de datos a la vez, por lo que se debe indicar al receptor cuáles extraer.

Utilice el values.yaml que coincida con el método de credenciales que eligió en el paso anterior:

licenseKey: <YOUR_LICENSE_KEY>
otlpEndpoint: otlp.nr-data.net:4317

postgresql:
  topology: <self-hosted|rds>
  server: <YOUR_DB_HOST>
  port: <YOUR_DB_PORT>
  username: <YOUR_MONITORING_USERNAME>
  password: <YOUR_MONITORING_PASSWORD>
  databases:
    - <YOUR_DATABASE>
    - <ANOTHER_DATABASE>

# No setup job runs, so create the monitoring role and its
# per-database grants yourself before installing the chart.
setupJob:
  enabled: false

licenseKey: <YOUR_LICENSE_KEY>
otlpEndpoint: otlp.nr-data.net:4317

postgresql:
  topology: <self-hosted|rds>
  server: <YOUR_DB_HOST>
  port: <YOUR_DB_PORT>
  existingSecret: postgres-monitor-creds
  databases:
    - <YOUR_DATABASE>
    - <ANOTHER_DATABASE>

# No setup job runs, so the monitoring role referenced by
# this secret must already exist - create it yourself
# before installing the chart.
setupJob:
  enabled: false

licenseKey: <YOUR_LICENSE_KEY>
otlpEndpoint: otlp.nr-data.net:4317

postgresql:
  topology: <self-hosted|rds>
  server: <YOUR_DB_HOST>
  port: <YOUR_DB_PORT>
  existingSecret: postgres-monitor-creds
  databases:
    - <YOUR_DATABASE>
    - <ANOTHER_DATABASE>

setupJob:
  enabled: true
  image:
    # -- psql-capable image. No default: the official postgres
    # image bundles psql and is a reasonable choice.
    repository: postgres
    tag: "16"
    pullPolicy: IfNotPresent
  postgresAdmin:
    existingSecret: postgres-admin-creds
  # -- Also creates the otel.explain_statement SECURITY DEFINER
  # function, so the receiver can EXPLAIN write/locking queries.
  enableExplainPermissions: false
  # -- Also creates the pgvector extension in each database.
  enablePgvector: false

Parámetro	Descripción
`licenseKey`	Su clave de licencia de New Relic.
`otlpEndpoint`	El extremo OTLP/gRPC de la región, como un `host:port` simple sin esquema: `otlp.nr-data.net:4317` (EE. UU.) o `otlp.eu01.nr-data.net:4317` (UE). Para obtener más información, consulte la documentación de los extremos OTLP de New Relic.
`postgresql.server` / `postgresql.port`	El host de PostgreSQL (o extremo de RDS) y el puerto, accesibles desde el clúster.
`postgresql.databases`	Lista obligatoria y no vacía de bases de datos para monitorear.
`postgresql.excludeDatabases`	Bases de datos excluidas de los escaneos de consultas principales y muestras de consultas a nivel de clúster. El valor predeterminado es `[rdsadmin]` y solo se renderiza cuando `topology` es `rds`; en RDS, el usuario de monitoreo nunca puede acceder a `rdsadmin`, por lo que excluirlo evita errores de permisos.
`setupJob.image.repository` / `setupJob.image.tag`	Una imagen compatible con `psql`utilizada por el trabajo de configuración. El chart no incluye ninguna de forma predeterminada, por lo que debe proporcionar una cuando el trabajo de configuración esté habilitado. La imagen oficial de `postgres` incluye `psql` y es una opción razonable.
`setupJob.enableExplainPermissions`	Opcional. También crea la función `otel.explain_statement` `SECURITY DEFINER` y otorga `EXECUTE` sobre ella, lo que permite al receptor ejecutar `EXPLAIN` contra consultas de bloqueo y escritura sin tener permisos de escritura. Dejarlo `false` es seguro: el receptor recurre a `EXPLAIN` en línea, por lo que esas declaraciones simplemente no obtienen planes de consulta.
`setupJob.enablePgvector`	Opcional. También crea la extensión `vector` en cada base de datos monitoreada, para métricas vectoriales. Las funciones de distancia `l1`, `hamming` y `jaccard` necesitan pgvector 0.7.0 o posterior.

Sugerencia

Por lo general, no es necesario configurar postgresql.topQueryCollection.explainFunctionName. El valor predeterminado del propio receptor ya es otel.explain_statement (la función exacta que crea setupJob.enableExplainPermissions), y el chart omite la clave cuando está vacía, por lo que ambos coinciden sin configuración adicional. Configúrelo solo para que el receptor apunte a una función con un nombre diferente.

Sugerencia

Consulte el archivo values.yaml del chart para ver todas las opciones de configuración disponibles, incluidos postgresql.collectionInterval, los interruptores metrics, los bloques topQueryCollection/querySampleCollection y la vía de escape additionalReceiverConfig.

(Opcional) Monitorear múltiples instancias desde un release

En lugar de postgresql.*, configure postgresqlMulti.enabled: true para monitorear varias instancias de PostgreSQL (autohospedadas o RDS) desde un único pod recolector en una versión. Los dos modos son mutuamente excluyentes: no configure postgresql.server y postgresqlMulti.enabled: true en la misma versión.

Las entradas se llaman instances, no databases: cada instancia es un servidor de PostgreSQL independiente y cada una contiene su propia lista anidada de databases (las bases de datos individuales para monitorear en esa instancia), de la misma manera que postgresql.databases funciona en el modo de instancia única.

El modo multiinstancia no tiene una ruta de nombre de usuario/contraseña en texto plano: cada instancia necesita su propio secreto de Kubernetes con credenciales de monitoreo. Decida si también desea que el trabajo de configuración le cree cada rol de monitoreo:

Cree el secreto del rol de monitoreo de cada instancia antes de instalar (repita por instancia, de modo que coincida con el name que le asigne en values.yaml):

bash

$kubectl create secret generic db1-monitor-creds \
>  --from-literal=username=<MONITORING_USERNAME> \
>  --from-literal=password='<MONITORING_PASSWORD>' \
>  -n newrelic
$# Repeat for every instance (db2-monitor-creds, ...)

licenseKey: <YOUR_LICENSE_KEY>
otlpEndpoint: otlp.nr-data.net:4317

# EDIT the two example entries below (or add more) to match
# your real instances - each `name` must be unique within
# this release and match the Secret you created for it.
postgresqlMulti:
  enabled: true
  topology: <self-hosted|rds>
  instances:
    - name: db1
      server: <YOUR_DB_1_HOST>
      port: 5432
      existingSecret: db1-monitor-creds
      databases:
        - appdb1
    - name: db2
      server: <YOUR_DB_2_HOST>
      port: 5432
      existingSecret: db2-monitor-creds
      databases:
        - appdb2

# No admin credential is configured here since the setup
# job is disabled - create each instance's monitoring role
# yourself first.
setupJob:
  enabled: false

Cada instancia necesita tanto su propio secreto de rol de monitoreo como su propio secreto de credenciales de administrador (repetir por instancia):

bash

$kubectl create secret generic db1-monitor-creds \
>  --from-literal=username=<MONITORING_USERNAME> \
>  --from-literal=password='<MONITORING_PASSWORD>' \
>  -n newrelic
>kubectl create secret generic db1-admin-creds \
>  --from-literal=username=<ADMIN_USERNAME> \
>  --from-literal=password='<ADMIN_PASSWORD>' \
>  -n newrelic
$# Repeat for every instance (db2-monitor-creds, db2-admin-creds, ...)

licenseKey: <YOUR_LICENSE_KEY>
otlpEndpoint: otlp.nr-data.net:4317

# EDIT the two example entries below (or add more) to match
# your real instances - each `name` must be unique within
# this release and match the Secrets you created for it.
postgresqlMulti:
  enabled: true
  topology: <self-hosted|rds>
  instances:
    - name: db1
      server: <YOUR_DB_1_HOST>
      port: 5432
      existingSecret: db1-monitor-creds
      databases:
        - appdb1
      postgresAdmin:
        existingSecret: db1-admin-creds
    - name: db2
      server: <YOUR_DB_2_HOST>
      port: 5432
      existingSecret: db2-monitor-creds
      databases:
        - appdb2
      postgresAdmin:
        existingSecret: db2-admin-creds

setupJob:
  enabled: true
  image:
    # -- psql-capable image. No default: the official postgres
    # image bundles psql and is a reasonable choice.
    repository: postgres
    tag: "16"

Parámetro	Descripción
`postgresqlMulti.enabled`	Establezca en `true` para monitorear varias instancias desde un lanzamiento en lugar de `postgresql.*`. Por defecto es `false`.
`postgresqlMulti.topology`	`self-hosted` o `rds`, mismo significado que `postgresql.topology`, compartido por cada instancia en esta versión.
`postgresqlMulti.instances`	Lista de instancias a monitorear. Cada entrada requiere un `name` único, `server` (`port` tiene como valor predeterminado `5432`), `existingSecret` y una lista `databases` obligatoria y no vacía de nombres de bases de datos en esa instancia; agregue `postgresAdmin.existingSecret` por entrada solo cuando `setupJob.enabled` sea `true`.

Sugerencia

setupJob.enableExplainPermissions y setupJob.enablePgvector son opciones únicas compartidas en cada base de datos de cada instancia; no se pueden configurar por instancia. La configuración de extracción (intervalo de recopilación, métricas, topQueryCollection/querySampleCollection) también se aplica de manera idéntica a cada instancia en postgresqlMulti.instances; no hay anulación por instancia. Utilice additionalReceiverConfig para cualquier elemento que deba ser diferente. El trabajo de configuración se ejecuta una vez por instancia (<release>-setup-<name>) en lugar de una vez por versión.

Instale el chart de Helm

Agregue el repositorio Helm de New Relic:

bash

$helm repo add newrelic https://helm-charts.newrelic.com
$helm repo update

Instale el chart utilizando su archivo values.yaml:

bash

$helm upgrade --install postgresql-otel newrelic/postgresql-otel \
>  -n newrelic \
>  --create-namespace \
>  -f values.yaml

Verifique la instalación

Compruebe que el trabajo de configuración se haya completado (si está habilitado) y que el pod del recolector se esté ejecutando:
bash
```
$kubectl get jobs,pods -n newrelic --watch
```

Ejecute esta consulta en el generador de consultas para confirmar que los datos están llegando:

SELECT count(*) FROM Metric
WHERE metricName LIKE 'postgresql.%'
AND instrumentation.provider = 'opentelemetry'
SINCE 10 minutes ago

Encuentra y utiliza tus datos

Una vez que sus datos se estén recopilando, puede acceder al monitoreo integral de bases de datos PostgreSQL a través de la UI de New Relic.

Para encontrar su entidad de base de datos PostgreSQL en New Relic:

Vaya a one.newrelic.com > All capabilities > Databases.
En el menú desplegable Entity type, seleccione PostgreSQL instance y luego haga clic en Apply.
Seleccione su base de datos PostgreSQL de la lista de entidades.

Introducción al monitoreo de PostgreSQL con NRDOT

Conozca todos los métodos de instalación disponibles para el monitoreo de PostgreSQL con New Relic.

Instalación de la CLI

Aprenda a instalar y configurar el monitoreo de PostgreSQL con un solo comando de la CLI de New Relic.

Instalación con Ansible

Aprenda a instalar y configurar el monitoreo de PostgreSQL a escala con el newrelic.newrelic_install rol de Ansible.

Instalación con Chef

Aprenda a instalar y configurar el monitoreo de PostgreSQL a escala con el libro de recetas de Chef newrelic-install.

Te ofrecemos esta traducción automática para facilitar la lectura.

Instalar y configurar NRDOT para el monitoreo de PostgreSQL con Helm

Instalación guiada

Importante

Requisitos previos a nivel de servidor

Requisitos previos

Cree el namespace

Sugerencia

Configurar las credenciales de monitoreo

Sin trabajo de configuración: nombre de usuario y contraseña en texto sin formato

Sin trabajo de configuración: credenciales basadas en secretos

Trabajo de configuración automatizado

Configurar los valores de Helm

Sin trabajo de configuración: nombre de usuario y contraseña en texto sin formato

Sin trabajo de configuración: credenciales basadas en secretos

Trabajo de configuración automatizado

Sugerencia

Sugerencia

(Opcional) Monitorear múltiples instancias desde un release

Sin trabajo de configuración

Trabajo de configuración automatizado

Sugerencia

Instale el chart de Helm

Verifique la instalación

Encuentra y utiliza tus datos

Introducción al monitoreo de PostgreSQL con NRDOT

Instalación de la CLI

Instalación con Ansible

Instalación con Chef

Te ofrecemos esta traducción automática para facilitar la lectura.

Instalar y configurar NRDOT para el monitoreo de PostgreSQL con Helm

Instalación guiada

Importante

Requisitos previos a nivel de servidor .css-21sua1{background:none;border:none;width:0;padding:0;}

Requisitos previos

Cree el namespace

Sugerencia

Configurar las credenciales de monitoreo

Sin trabajo de configuración: credenciales basadas en secretos

Trabajo de configuración automatizado

Configurar los valores de Helm

Sin trabajo de configuración: nombre de usuario y contraseña en texto sin formato

Sin trabajo de configuración: credenciales basadas en secretos

Trabajo de configuración automatizado

Sugerencia

Sugerencia

(Opcional) Monitorear múltiples instancias desde un release

Sin trabajo de configuración

Trabajo de configuración automatizado

Sugerencia

Instale el chart de Helm

Verifique la instalación

Encuentra y utiliza tus datos

Documentación relacionada

Introducción al monitoreo de PostgreSQL con NRDOT

Instalación de la CLI

Instalación con Ansible

Instalación con Chef

Requisitos previos a nivel de servidor