Instalar e configurar o NRDOT para monitoramento do PostgreSQL com Helm

Você pode instalar e configurar o monitoramento do PostgreSQL no Kubernetes usando o chart do Helm postgresql-otel. Opcionalmente, o chart também pode executar um job de configuração que cria a role de monitoramento, suas concessões e a extensão pg_stat_statements para você.

Instalação guiada

Para instalar pela interface da New Relic, acesse one.newrelic.com > Integrations & Agents > PostgreSQL (Database 360). Esta página aborda apenas a instalação manual.

Importante

O chart implanta o coletor como uma implantação do Kubernetes que acessa o PostgreSQL remotamente pela rede, portanto, ele relata apenas métricas do PostgreSQL: nenhuma métrica de host ou de infraestrutura para a máquina em que o PostgreSQL é executado. Ele monitora uma instância do PostgreSQL por release (vários bancos de dados nessa instância são suportados) e não configura o TLS ou provedores de credenciais db_auth, como a autenticação do AWS IAM.

Pré-requisitos em nível de servidor

O PostgreSQL 14 ou mais recente é necessário. Antes de instalar este chart (ou habilitar o job de configuração), os seguintes parâmetros do servidor devem estar configurados. pg_stat_statements não pode ser criado sem shared_preload_libraries, e esse parâmetro requer uma reinicialização, portanto, nada em execução dentro do seu cluster do Kubernetes pode fazer isso por você.

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`

Auto-hospedado: defina-os em postgresql.conf e, em seguida, reinicie o PostgreSQL. Algumas distribuições precisam do pacote postgresql-contrib instalado para que pg_stat_statements esteja disponível.
AWS RDS ou Aurora: defina-os no grupo de parâmetros do banco de dados, não em um arquivo de configuração. track_activity_query_size e pg_stat_statements.max são parâmetros estáticos; aplique-os com apply_method: pending-reboot e, em seguida, reinicie a instância. Aplicá-los imediatamente falha com InvalidParameterCombination. Para o Aurora, o nome da família do grupo de parâmetros deve corresponder exatamente à versão principal do seu mecanismo, por exemplo, aurora-postgresql16.

Pré-requisitos

Chave de licença da New Relic válida.
Helm 3.0 ou posterior, e kubectl configurado para acessar seu cluster do Kubernetes.
Conectividade de rede do seu cluster do Kubernetes para o host do PostgreSQL (ou endpoint do RDS) e porta:
- Auto-hospedado: um caminho roteado para o host do PostgreSQL (VPN, peering ou rede compartilhada), resolução de DNS se for um nome do host, e o pg_hba.conf e o firewall do lado do PostgreSQL devem permitir o IP de origem real da conexão (que pode ser um gateway NAT, não o IP do próprio pod).
- AWS RDS: emparelhamento de VPC, um transit gateway ou posicionamento em VPC compartilhada com a instância do RDS, e o grupo de segurança do RDS deve permitir a porta do PostgreSQL (5432 por padrão) a partir da origem de saída do cluster.
Uma role de monitoramento que você já criou com suas concessões por banco de dados ou credenciais de administrador do PostgreSQL para que o job de configuração do chart possa criá-las para você. Veja Configurar credenciais de monitoramento abaixo.

Crie o namespace

Crie o namespace onde a instalação será realizada. Ele deve existir antes da criação de qualquer secret na próxima etapa, já que helm install --create-namespace cria o namespace apenas durante a etapa final de instalação:

bash

$kubectl create namespace newrelic

Dica

Defina-o como o namespace padrão para o seu contexto kubectl atual para que não seja necessário passar -n em todos os comandos abaixo:

bash

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

Configure as credenciais de monitoramento

Decida se você deseja que o job de configuração do chart crie a role de monitoramento do PostgreSQL para você e, se não, como você fornecerá suas credenciais:

Com este método não há job de configuração, portanto, nada aqui cria a função de monitoramento para você. Antes de instalar o chart, crie-o você mesmo como superusuário. Execute isto uma vez no nível do cluster:

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

Em seguida, execute isto em cada banco de dados que você planeja listar em 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 obter mais detalhes, consulte a etapa Configurar usuário e concessões do banco de dados para PostgreSQL auto-hospedado ou PostgreSQL no RDS.

Você definirá o nome de usuário e a senha de monitoramento diretamente em values.yaml na próxima etapa.

Com este método, também não há job de configuração. Crie você mesmo a função de monitoramento e suas concessões por banco de dados primeiro, exatamente como no método de credenciais simples acima. A única diferença é onde suas credenciais ficam: em vez de texto simples em values.yaml, armazene-as em um secret do Kubernetes:

bash

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

Com este método, o job de configuração do chart cria a função de monitoramento para você e, para cada banco de dados em postgresql.databases, cria o esquema otel, concede USAGE/SELECT/pg_monitor e cria a extensão pg_stat_statements. Tanto as credenciais de monitoramento quanto as de administrador devem ser fornecidas como secrets do Kubernetes: o job de configuração nunca aceita credenciais de administrador em texto simples, e habilitá-lo também requer credenciais de monitoramento baseadas em secrets.

Crie um secret com o nome de usuário e a senha de monitoramento. Esta é a identidade que o job de configuração cria e com a qual o coletor se conecta:

bash

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

O job de configuração aceita apenas credenciais de administrador por meio de um secret do Kubernetes (sem nome de usuário/senha em texto simples em values.yaml). Essa credencial deve ser de um superusuário (auto-hospedado) ou um equivalente a rds_superuser (RDS), uma vez que precisa de CREATE USER, CREATE SCHEMA e CREATE EXTENSION:
bash
```
$kubectl create secret generic postgres-admin-creds \
>  --from-literal=username=<ADMIN_USERNAME> \
>  --from-literal=password='<ADMIN_PASSWORD>' \
>  -n newrelic
```

Configure os valores do Helm

Defina postgresql.topology para corresponder ao seu ambiente:

Valor	Descrição
`self-hosted`	PostgreSQL auto-hospedado, acessado pela rede.
`rds`	PostgreSQL ou Aurora no AWS RDS.

postgresql.databases é uma lista obrigatória e não vazia. Ao contrário do MySQL ou do SQL Server, o PostgreSQL não possui um modo de monitoramento de todos os bancos de dados: uma conexão tem como destino um banco de dados por vez, portanto, o receiver deve ser informado sobre quais coletar.

Use o values.yaml que corresponde ao método de credencial escolhido na etapa 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	Descrição
`licenseKey`	Sua chave de licença New Relic.
`otlpEndpoint`	O endpoint OTLP/gRPC da sua região, como um `host:port` simples sem esquema : `otlp.nr-data.net:4317` (EUA) ou `otlp.eu01.nr-data.net:4317` (UE). Para mais informações, consulte a documentação dos endpoints OTLP da New Relic .
`postgresql.server` / `postgresql.port`	Seu host do PostgreSQL (ou endpoint do RDS) e porta, acessíveis a partir do cluster.
`postgresql.databases`	Lista obrigatória e não vazia de bancos de dados para monitorar.
`postgresql.excludeDatabases`	Bancos de dados excluídos das varreduras de consultas principais e amostras de consultas em todo o cluster. O padrão é `[rdsadmin]` e só é renderizado quando `topology` é `rds` ; no RDS, o usuário de monitoramento nunca pode acessar `rdsadmin` , portanto, excluí-lo evita erros de permissão.
`setupJob.image.repository` / `setupJob.image.tag`	Uma imagem compatível com `psql` usada pelo job de configuração. O chart não inclui nenhum padrão , portanto, é necessário fornecer um quando o job de configuração estiver habilitado. A imagem oficial do `postgres` inclui o `psql` e é uma escolha razoável.
`setupJob.enableExplainPermissions`	Opcional. Também cria a função `otel.explain_statement` `SECURITY DEFINER` e concede `EXECUTE` sobre ela, permitindo que o receptor execute `EXPLAIN` em consultas de bloqueio e gravação sem possuir permissões de gravação. Deixá-lo `false` é seguro: o receptor recorre ao `EXPLAIN` inline, portanto, essas instruções simplesmente não obtêm planos de consulta.
`setupJob.enablePgvector`	Opcional. Também cria a extensão `vector` em cada banco de dados monitorado, para métricas de vetor. As funções de distância `l1` , `hamming` e `jaccard` requerem o pgvector 0.7.0 ou posterior.

Dica

Geralmente, não é necessário definir postgresql.topQueryCollection.explainFunctionName. O próprio padrão do receiver já é otel.explain_statement (a função exata que setupJob.enableExplainPermissions cria), e o chart omite a chave quando ela está vazia, de modo que os dois se alinham sem configuração extra. Defina-o apenas para apontar o receiver para uma função com nome diferente.

Dica

Consulte o values.yaml do chart para ver todas as opções de configuração disponíveis, incluindo postgresql.collectionInterval, os toggles metrics, os blocos topQueryCollection/querySampleCollection e a válvula de escape additionalReceiverConfig.

(Opcional) Monitorar várias instâncias a partir de um release

Em vez de postgresql.*, defina postgresqlMulti.enabled: true para monitorar várias instâncias do PostgreSQL (auto-hospedadas ou RDS) a partir de um único pod de coletor em uma versão. Os dois modos são mutuamente exclusivos: não defina postgresql.server e postgresqlMulti.enabled: true na mesma versão.

As entradas são chamadas de instances, não de databases: cada instância é um servidor PostgreSQL separado e cada uma carrega sua própria lista databases aninhada (os bancos de dados individuais a serem monitorados nessa instância), da mesma forma que postgresql.databases funciona no modo de instância única.

O modo multi-instância não possui um caminho de nome de usuário/senha simples: cada instância precisa de seu próprio secret do Kubernetes com credenciais de monitoramento. Decida se você também deseja que o job de configuração crie cada função de monitoramento para você:

Crie manualmente o segredo da função de monitoramento de cada instância antes da instalação (repita por instância, correspondendo ao name fornecido em 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 instância precisa tanto de seu próprio secret da função de monitoramento quanto de seu próprio secret de credenciais de administrador (repita por instância):

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	Descrição
`postgresqlMulti.enabled`	Defina como `true` para monitorar várias instâncias de uma versão em vez de `postgresql.*` . O padrão é `false` .
`postgresqlMulti.topology`	`self-hosted` ou `rds` , mesmo significado que `postgresql.topology` , compartilhado por todas as instâncias nesta versão.
`postgresqlMulti.instances`	Lista de instâncias a serem monitoradas. Cada entrada requer um `name` exclusivo, `server` ( `port` tem como padrão `5432` ), `existingSecret` e uma lista `databases` obrigatória e não vazia de nomes de bancos de dados nessa instância; adicione `postgresAdmin.existingSecret` por entrada apenas quando `setupJob.enabled` for `true` .

Parâmetro

Descrição

postgresqlMulti.enabled

Defina como

true

para monitorar várias instâncias de uma versão em vez de

postgresql.*

. O padrão é

false

postgresqlMulti.topology

self-hosted

rds

, mesmo significado que

postgresql.topology

, compartilhado por todas as instâncias nesta versão.

postgresqlMulti.instances

Lista de instâncias a serem monitoradas. Cada entrada requer um

name

exclusivo,

server

(

port

tem como padrão

5432

existingSecret

e uma lista

databases

obrigatória e não vazia

de nomes de bancos de dados nessa instância; adicione

postgresAdmin.existingSecret

por entrada apenas quando

setupJob.enabled

for

true

Dica

setupJob.enableExplainPermissions e setupJob.enablePgvector são chaves únicas compartilhadas em cada banco de dados em cada instância; elas não podem ser definidas por instância. As configurações de extração (intervalo de coleta, métricas, topQueryCollection/querySampleCollection) também se aplicam de forma idêntica a cada instância em postgresqlMulti.instances; não há substituição por instância. Utilize additionalReceiverConfig para qualquer elemento que precise ser diferente. O job de configuração é executado uma vez por instância (<release>-setup-<name>) em vez de uma vez por versão.

Instale o Helm chart

Adicione o repositório Helm da New Relic:

bash

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

Instale o chart usando seu arquivo values.yaml:

bash

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

Verifique a instalação

Verifique se o job de configuração foi concluído (se ativado) e se o pod do coletor está em execução:
bash
```
$kubectl get jobs,pods -n newrelic --watch
```

Execute esta consulta no criador de consulta para confirmar se os dados estão chegando:

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

Encontre e use seus dados

Assim que seus dados estiverem sendo coletados, você poderá acessar o monitoramento abrangente do banco de dados PostgreSQL por meio da interface do New Relic.

Para encontrar a entidade de banco de dados PostgreSQL no New Relic:

Vá para one.newrelic.com > All capabilities > Databases.
Na dropdown Entity type, selecione PostgreSQL instance e clique em Apply.
Selecione seu banco de dados PostgreSQL na lista de entidades.

Introdução ao monitoramento do PostgreSQL com NRDOT

Saiba mais sobre todos os métodos de instalação disponíveis para o monitoramento do PostgreSQL com o New Relic.

Instalação da CLI

Saiba como instalar e configurar o monitoramento do PostgreSQL com um único comando da CLI do New Relic.

Instalação via Ansible

Saiba como instalar e configurar o monitoramento do PostgreSQL em escala com a newrelic.newrelic_install função Ansible.

Instalação via Chef

Aprenda a instalar e configurar o monitoramento do PostgreSQL em escala com o cookbook do Chef newrelic-install.

Esta tradução de máquina é fornecida para sua comodidade.

Instalar e configurar o NRDOT para monitoramento do PostgreSQL com Helm

Instalação guiada

Importante

Pré-requisitos em nível de servidor

Pré-requisitos

Crie o namespace

Dica

Configure as credenciais de monitoramento

Sem job de configuração: nome de usuário e senha simples

Sem job de configuração: credenciais baseadas em segredos

Tarefa de configuração automatizada

Configure os valores do Helm

Sem job de configuração: nome de usuário e senha simples

Sem job de configuração: credenciais baseadas em segredos

Tarefa de configuração automatizada

Dica

Dica

(Opcional) Monitorar várias instâncias a partir de um release

Sem job de configuração

Tarefa de configuração automatizada

Dica

Instale o Helm chart

Verifique a instalação

Encontre e use seus dados

Introdução ao monitoramento do PostgreSQL com NRDOT

Instalação da CLI

Instalação via Ansible

Instalação via Chef

Esta tradução de máquina é fornecida para sua comodidade.

Instalar e configurar o NRDOT para monitoramento do PostgreSQL com Helm

Instalação guiada

Importante

Pré-requisitos em nível de servidor .css-21sua1{background:none;border:none;width:0;padding:0;}

Pré-requisitos

Crie o namespace

Dica

Configure as credenciais de monitoramento

Sem job de configuração: credenciais baseadas em segredos

Tarefa de configuração automatizada

Configure os valores do Helm

Sem job de configuração: nome de usuário e senha simples

Sem job de configuração: credenciais baseadas em segredos

Tarefa de configuração automatizada

Dica

Dica

(Opcional) Monitorar várias instâncias a partir de um release

Sem job de configuração

Tarefa de configuração automatizada

Dica

Instale o Helm chart

Verifique a instalação

Encontre e use seus dados

Documentação relacionada

Introdução ao monitoramento do PostgreSQL com NRDOT

Instalação da CLI

Instalação via Ansible

Instalação via Chef

Pré-requisitos em nível de servidor