Configuración de Database Monitoring para Postgres gestionado por Aurora

Database Monitoring te proporciona una amplia visibilidad de tus bases de datos Postgres mediante la exposición de métricas de consultas, muestras de consultas, explain-plans, estados de bases de datos, conmutaciones por error y eventos.

El Agent recopila telemetría directamente de la base de datos iniciando sesión como usuario de sólo lectura. Realiza la siguiente configuración para habilitar Database Monitoring con tu base de datos Postgres:

  1. Configura parámetros de bases de datos.
  2. Concede al Agent acceso a la base de datos.
  3. Instala y configura el Agent.
  4. Instala la integración RDS.

Antes de empezar

Versiones PostgreSQL compatibles
9.6, 10, 11, 12, 13, 14, 15, 16, 17
Versiones del Agent compatibles
v7.36.1 o posterior
Impacto en el rendimiento
La configuración de Database Monitoring predeterminada del Agent es conservadora, pero puedes ajustar algunos parámetros como el intervalo de recopilación y la frecuencia de muestreo de consultas según tus necesidades. Para la mayoría de las cargas de trabajo, el Agent representa menos del uno por ciento del tiempo de ejecución de la consulta en la base de datos y menos del uno por ciento del uso de CPU.

Database Monitoring se ejecuta como una integración sobre el Agent de base (consulta las referencias).
Proxies, balanceadores de carga y agrupadores de conexiones
El Datadog Agent debe conectarse directamente al host que se está monitorizando. Para las bases de datos autoalojadas, se prefiere 127.0.0.1 o el socket. El Agent no debe conectarse a la base de datos a través de un proxy, balanceador de carga o agrupador de conexiones como pgbouncer o del endpoint del clúster de Aurora. Si el Agent se conecta al endpoint del clúster, recopila datos de una réplica aleatoria y sólo proporciona una visibilidad de esa réplica. Si el Agent se conecta a diferentes hosts mientras se ejecuta (como en el caso de la conmutación por error, el balanceo de carga, etc.), calcula la diferencia en las estadísticas entre dos hosts, lo que produce inexactitudes en las métricas.
Consideraciones sobre la seguridad de los datos
Para saber qué datos recopila el Agent de tus bases de datos y cómo garantizar su seguridad, consulta Información confidencial.

Configuración de parámetros de Postgres

Configura los siguientes parámetros en el grupo de parámetros de bases de datos y luego reinicia el servidor para que la configuración surta efecto. Para obtener más información sobre estos parámetros, consulta la documentación de Postgres.

ParámetroValorDescripción
shared_preload_librariespg_stat_statementsNecesario para métricas postgresql.queries.*. Habilita la recopilación de métricas de consultas utilizando la extensión pg_stat_statements Esto sólo funciona así por defecto en Aurora.
track_activity_query_size4096Necesario para recopilar consultas de mayor tamaño. Aumenta el tamaño del texto SQL en pg_stat_activity. Si se deja con el valor predeterminado, las consultas de más de 1024 caracteres no se recopilan.
pg_stat_statements.trackALLOpcional. Habilita el seguimiento de sentencias dentro de procedimientos almacenados y funciones.
pg_stat_statements.max10000Opcional. Aumenta el número de consultas normalizadas rastreadas en pg_stat_statements. Este parámetro se recomienda para bases de datos de gran volumen que reciben muchos tipos diferentes de consultas de muchos clientes distintos.
pg_stat_statements.track_utilityoffOpcional. Deshabilita comandos de utilidad como PREPARE y EXPLAIN. Configurar este valor en off significa que sólo se rastrearán consultas como SELECT, UPDATE y DELETE.
track_io_timingonOpcional. Habilita la recopilación de los tiempos de lectura y escritura de bloques para las consultas.

Concesión de acceso al Agent

El Datadog Agent requiere acceso de sólo lectura al servidor de la base de datos para recopilar estadísticas y consultas.

Los siguientes comandos SQL deben ejecutarse en el servidor de base de datos primario (el escritor) en el clúster, si Postgres está replicado. Elige una base de datos PostgreSQL en el servidor de base de datos para que el Agent se conecte a ella. El Agent puede recopilar telemetría de todas las bases de datos del servidor de bases de datos independientemente de a cuál se conecte, por lo que una buena opción es utilizar la base de datos predeterminada postgres. Elige una base de datos diferente sólo si necesitas que el Agent ejecute consultas personalizadas con datos exclusivos de esa base de datos.

Conéctate a la base de datos elegida como superusuario (u otro usuario con permisos suficientes). Por ejemplo, si la base de datos elegida es postgres, conéctate como el usuario postgres a través de psql ejecutando:

psql -h mydb.example.com -d postgres -U postgres

Crea el usuario datadog:

CREATE USER datadog WITH password '<PASSWORD>';

Nota: La autenticación IAM también es compatible. Para saber cómo configurarla en tu instancia de Aurora, consulta la guía.

Crea el siguiente esquema en cada base de datos:

CREATE SCHEMA datadog;
GRANT USAGE ON SCHEMA datadog TO datadog;
GRANT USAGE ON SCHEMA public TO datadog;
GRANT pg_monitor TO datadog;
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

Crea el siguiente esquema en cada base de datos:

CREATE SCHEMA datadog;
GRANT USAGE ON SCHEMA datadog TO datadog;
GRANT USAGE ON SCHEMA public TO datadog;
GRANT SELECT ON pg_stat_database TO datadog;
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

Crea funciones en cada base de datos para que el Agent pueda leer el contenido completo de pg_stat_activity y pg_stat_statements:

CREATE OR REPLACE FUNCTION datadog.pg_stat_activity() RETURNS SETOF pg_stat_activity AS
  $$ SELECT * FROM pg_catalog.pg_stat_activity; $$
LANGUAGE sql
SECURITY DEFINER;
CREATE OR REPLACE FUNCTION datadog.pg_stat_statements() RETURNS SETOF pg_stat_statements AS
    $$ SELECT * FROM pg_stat_statements; $$
LANGUAGE sql
SECURITY DEFINER;
Para la recopilación de datos o métricas personalizadas que requieren consultar tablas adicionales, es posible que tengas que conceder el permiso SELECT en esas tablas al usuario Datadog. Ejemplo: grant SELECT on <TABLE_NAME> to datadog;. Para obtener más información, consulta Recopilación de métricas personalizadas de PostgreSQL.

Crea la función en cada base de datos para permitir al Agent recopilar explain-plans.

CREATE OR REPLACE FUNCTION datadog.explain_statement(
   l_query TEXT,
   OUT explain JSON
)
RETURNS SETOF JSON AS
$$
DECLARE
curs REFCURSOR;
plan JSON;

BEGIN
   OPEN curs FOR EXECUTE pg_catalog.concat('EXPLAIN (FORMAT JSON) ', l_query);
   FETCH curs INTO plan;
   CLOSE curs;
   RETURN QUERY SELECT plan;
END;
$$
LANGUAGE 'plpgsql'
RETURNS NULL ON NULL INPUT
SECURITY DEFINER;

Guardar tu contraseña de forma segura

Store your password using secret management software such as Vault. You can then reference this password as ENC[<SECRET_NAME>] in your Agent configuration files: for example, ENC[datadog_user_database_password]. See Secrets Management for more information.

The examples on this page use datadog_user_database_password to refer to the name of the secret where your password is stored. It is possible to reference your password in plain text, but this is not recommended.

Verificación

Para verificar que los permisos son correctos, ejecuta los siguientes comandos para confirmar que el usuario del Agent puede conectarse a la base de datos y leer las tablas principales:

psql -h localhost -U datadog postgres -A \
  -c "select * from pg_stat_database limit 1;" \
  && echo -e "\e[0;32mPostgres connection - OK\e[0m" \
  || echo -e "\e[0;31mCannot connect to Postgres\e[0m"
psql -h localhost -U datadog postgres -A \
  -c "select * from pg_stat_activity limit 1;" \
  && echo -e "\e[0;32mPostgres pg_stat_activity read OK\e[0m" \
  || echo -e "\e[0;31mCannot read from pg_stat_activity\e[0m"
psql -h localhost -U datadog postgres -A \
  -c "select * from pg_stat_statements limit 1;" \
  && echo -e "\e[0;32mPostgres pg_stat_statements read OK\e[0m" \
  || echo -e "\e[0;31mCannot read from pg_stat_statements\e[0m"
psql -h localhost -U datadog postgres -A \
  -c "select * from pg_stat_database limit 1;" \
  && echo -e "\e[0;32mPostgres connection - OK\e[0m" \
  || echo -e "\e[0;31mCannot connect to Postgres\e[0m"
psql -h localhost -U datadog postgres -A \
  -c "select * from pg_stat_activity limit 1;" \
  && echo -e "\e[0;32mPostgres pg_stat_activity read OK\e[0m" \
  || echo -e "\e[0;31mCannot read from pg_stat_activity\e[0m"
psql -h localhost -U datadog postgres -A \
  -c "select * from pg_stat_statements limit 1;" \
  && echo -e "\e[0;32mPostgres pg_stat_statements read OK\e[0m" \
  || echo -e "\e[0;31mCannot read from pg_stat_statements\e[0m"

Cuando se te pida una contraseña, utiliza la que introdujiste al crear el usuario datadog.

Instalación y configuración del Agent

Para monitorizar hosts de Aurora, instala el Datadog Agent en tu infraestructura y configúralo para conectarse a cada endpoint de instancia de forma remota. El Agent no necesita ejecutarse en la base de datos, sólo necesita conectarse a ella. Para conocer otros métodos de instalación del Agent no mencionados aquí, consulta las instrucciones de instalación del Agent.

Configuración de Autodiscovery (recomendada)

El Datadog Agent admite Autodiscovery para todos los endpoints Aurora de un clúster.

Si necesitas configuraciones diferentes para instancias específicas o si prefieres especificar manualmente los endpoints de Aurora, sigue la sección de configuración manual a continuación. De lo contrario, Datadog recomienda utilizar las instrucciones de configuración de Autodiscovery para clústeres de bases de dato de Aurora.

Para configurar la recopilación de métricas de Database Monitoring para un Agent que se ejecuta en un host, por ejemplo cuando se aprovisiona una pequeña instancia de EC2 para que el Agent recopile desde una base de datos Aurora:

  1. Edita el archivo postgres.d/conf.yaml para que apunte a tu host / port y configura los principales para la monitorización. Para conocer todas las opciones de configuración disponibles, consulta la muestra postgres.d/conf.yaml.

    init_config:
    instances:
      - dbm: true
        host: '<AWS_INSTANCE_ENDPOINT>'
        port: 5432
        username: datadog
        password: 'ENC[datadog_user_database_password]'
        aws:
          instance_endpoint: '<AWS_INSTANCE_ENDPOINT>'
          region: '<REGION>'
    
        ## Required for Postgres 9.6: Uncomment these lines to use the functions created in the setup
        # pg_stat_statements_view: datadog.pg_stat_statements()
        # pg_stat_activity_view: datadog.pg_stat_activity()
    
        ## Optional: Connect to a different database if needed for `custom_queries`
        # dbname: '<DB_NAME>'
    
Importante: Utiliza aquí el endpoint de la instancia de Aurora, no el endpoint del clúster.
  1. Reinicia el Agent.

Para configurar una integración para un Agent que se ejecuta en un contenedor Docker, como en ECS o Fargate, hay algunos métodos disponibles que se cubren en detalle en la documentación de configuración de Docker.

Los siguientes ejemplos muestran cómo utilizar etiquetas (labels) de Docker y plantillas de Autodiscovery para configurar la integración de Postgres.

Nota: El Agent debe tener permiso de lectura en el socket Docker para que las etiquetas de Autodiscovery funcionen.

Línea de comandos

Ejecuta el siguiente comando desde tu línea de comandos para iniciar el Agent. Sustituye los valores de los marcadores de posición por los de tu cuenta y entorno.

export DD_API_KEY=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
export DD_AGENT_VERSION=<AGENT_VERSION>

docker run -e "DD_API_KEY=${DD_API_KEY}" \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  -l com.datadoghq.ad.checks='{"postgres": {
    "init_config": {},
    "instances": [{
      "dbm": true,
      "host": "<AWS_INSTANCE_ENDPOINT>",
      "port": 5432,
      "username": "datadog",
      "password": "<UNIQUEPASSWORD>",
       "aws": {
         "instance_endpoint": "<AWS_INSTANCE_ENDPOINT>",
         "region": "<REGION>"
       },
      "tags": ["dbinstanceidentifier:<DB_INSTANCE_NAME>"]
    }]
  }}' \
  gcr.io/datadoghq/agent:${DD_AGENT_VERSION}

Para Postgres v9.6, añade los siguientes parámetros a la configuración de la instancia donde se especifican el host y el puerto:

"pg_stat_statements_view": "datadog.pg_stat_statements()",
"pg_stat_activity_view": "datadog.pg_stat_activity()"

Archivo de Docker

También puedes especificar etiquetas (labels) en Dockerfile, lo que te permite crear y desplegar un Agent personalizado sin modificar la configuración de tu infraestructura:

FROM gcr.io/datadoghq/agent:<AGENT_VERSION>

LABEL "com.datadoghq.ad.check_names"='["postgres"]'
LABEL "com.datadoghq.ad.init_configs"='[{}]'
LABEL "com.datadoghq.ad.instances"='[{"dbm": true, "host": "<AWS_INSTANCE_ENDPOINT>", "port": 5432,"username": "datadog","password": "ENC[datadog_user_database_password]","aws": {"instance_endpoint": "<AWS_INSTANCE_ENDPOINT>", "region": "<REGION>"}, "tags": ["dbinstanceidentifier:<DB_INSTANCE_NAME>"]}]'

Para Postgres v9.6, añade los siguientes parámetros a la configuración de la instancia donde se especifican el host y el puerto:

"pg_stat_statements_view": "datadog.pg_stat_statements()",
"pg_stat_activity_view": "datadog.pg_stat_activity()"

Para evitar exponer la contraseña del usuario Datadog en texto plano, utiliza el paquete de gestión de secretos del Agent y declara la contraseña utilizando la sintaxis ENC[]. Alternativamente, consulta la documentación de variables de plantilla de Autodiscovery para proporcionar la contraseña como una variable de entorno.

Si estás ejecutando un clúster de Kubernetes, usa el Datadog Cluster Agent para activar Database Monitoring.

Nota: Asegúrate de que los checks de clúster estén activados para tu Datadog Cluster Agent antes de continuar.

A continuación encontrarás instrucciones paso a paso para configurar la integración de Postgres utilizando diferentes métodos de despliegue del Datadog Cluster Agent.

Operación

Tomando como referencia las Instrucciones para operadores en Kubernetes e integraciones, sigue los pasos que se indican a continuación para configurar la integración de Postgres:

  1. Crea o actualiza el archivo datadog-agent.yaml con la siguiente configuración:

    apiVersion: datadoghq.com/v2alpha1
    kind: DatadogAgent
    metadata:
      name: datadog
    spec:
      global:
        clusterName: <CLUSTER_NAME>
        site: <DD_SITE>
        credentials:
          apiSecret:
            secretName: datadog-agent-secret
            keyName: api-key
    
      features:
        clusterChecks:
          enabled: true
    
      override:
        nodeAgent:
          image:
            name: agent
            tag: <AGENT_VERSION>
    
        clusterAgent:
          extraConfd:
            configDataMap:
              postgres.yaml: |-
                cluster_check: true
                init_config:
                instances:
                - host: <AWS_INSTANCE_ENDPOINT>
                  port: 5432
                  username: datadog
                  password: 'ENC[datadog_user_database_password]'
                  dbm: true
                  aws:
                    instance_endpoint: <AWS_INSTANCE_ENDPOINT>
                    region: <REGION>
                  tags:
                  - "dbinstanceidentifier:<DB_INSTANCE_NAME>"            
    

    Nota: Para Postgres v9.6, añade las siguientes líneas a la configuración de la instancia donde se especifican el host y el puerto:

    pg_stat_statements_view: datadog.pg_stat_statements()
    pg_stat_activity_view: datadog.pg_stat_activity()
    
  2. Aplica los cambios al Datadog Operator utilizando el siguiente comando:

    kubectl apply -f datadog-agent.yaml
    

Helm

Tomando como referencia las instrucciones de Helm en Kubernetes e integraciones, sigue los pasos que se indican a continuación para configurar la integración de Postgres:

  1. Actualiza tu archivo Datadog-values.yaml (utilizado en las instrucciones de instalación del Cluster Agent) con la siguiente configuración:

    datadog:
      clusterChecks:
        enabled: true
    
    clusterChecksRunner:
      enabled: true
    
    clusterAgent:
      enabled: true
      confd:
        postgres.yaml: |-
          cluster_check: true
          init_config:
          instances:
          - dbm: true
            host: <AWS_INSTANCE_ENDPOINT>
            port: 5432
            username: datadog
            password: 'ENC[datadog_user_database_password]'
            aws:
              instance_endpoint: <AWS_INSTANCE_ENDPOINT>
              region: <REGION>
            tags:
            - "dbinstanceidentifier:<DB_INSTANCE_NAME>"      
    

    Nota: Para Postgres v9.6, añade las siguientes líneas a la configuración de la instancia donde se especifican el host y el puerto:

    pg_stat_statements_view: datadog.pg_stat_statements()
    pg_stat_activity_view: datadog.pg_stat_activity()
    
  2. Despliega el Agent con el archivo de configuración anterior utilizando el siguiente comando:

    helm install datadog-agent -f datadog-values.yaml datadog/datadog
    
For Windows, append --set targetSystem=windows to the helm install command.

Configuración con archivos integrados

Para configurar un check de clúster con un archivo de configuración montado, monta el archivo de configuración en el contenedor del Cluster Agent en la ruta: /conf.d/postgres.yaml:

cluster_check: true  # Make sure to include this flag
init_config:
instances:
  - dbm: true
    host: '<AWS_INSTANCE_ENDPOINT>'
    port: 5432
    username: datadog
    password: 'ENC[datadog_user_database_password]'
    aws:
      instance_endpoint: <AWS_INSTANCE_ENDPOINT>
      region: <REGION>
    tags:
    - "dbinstanceidentifier:<DB_INSTANCE_NAME>"

    ## Required: For Postgres 9.6, uncomment these lines to use the functions created in the setup
    # pg_stat_statements_view: datadog.pg_stat_statements()
    # pg_stat_activity_view: datadog.pg_stat_activity()

Configuración con anotaciones de servicios de Kubernetes

En lugar de montar un archivo, puedes declarar la configuración de instancia como un servicio de Kubernetes. Para configurar este check para un Agent que se ejecuta en Kubernetes, crea un servicio en el mismo espacio de nombres que el Datadog Cluster Agent:

Anotaciones de Autodiscovery v2

apiVersion: v1
kind: Service
metadata:
  name: postgres
  labels:
    tags.datadoghq.com/env: '<ENV>'
    tags.datadoghq.com/service: '<SERVICE>'
  annotations:
    ad.datadoghq.com/<CONTAINER_NAME>.checks: |
      {
        "postgres": {
          "init_config": <INIT_CONFIG>,
          "instances": [
            {
              "dbm": true,
              "host": "<AWS_INSTANCE_ENDPOINT>",
              "port": 5432,
              "username": "datadog",
              "password": "ENC[datadog_user_database_password]",
              "aws": {
                "instance_endpoint": "<AWS_INSTANCE_ENDPOINT>",
                "region": "<REGION>"
              },
              "tags": [
                "dbinstanceidentifier:<DB_INSTANCE_NAME>"
              ]
            }
          ]
        }
      }            
spec:
  ports:
  - port: 5432
    protocol: TCP
    targetPort: 5432
    name: postgres

Para obtener más información, consulta Anotaciones de Autodiscovery.

Si utilizas Postgres v9.6, añade lo siguiente a la configuración de la instancia:

"pg_stat_statements_view": "datadog.pg_stat_statements()",
"pg_stat_activity_view": "datadog.pg_stat_activity()"

El Cluster Agent registra automáticamente esta configuración y comienza a ejecutar el check de Postgres.

Para evitar exponer la contraseña del usuario datadog en texto simple, utiliza el paquete de gestión de secretos del Agent y declara la contraseña utilizando la sintaxis ENC[].

Validación

Ejecuta el subcomando de estado del Agent y busca postgres en la sección Checks o visita la página Bases de datos para empezar.

Configuraciones del Agent de ejemplo

One agent connecting to multiple hosts

It is common to configure a single Agent host to connect to multiple remote database instances (see Agent installation architectures for DBM). To connect to multiple hosts, create an entry for each host in the Postgres integration config.

Datadog recommends using one Agent to monitor no more than 30 database instances.

Benchmarks show that one Agent running on a t4g.medium EC2 instance (2 CPUs and 4GB of RAM) can successfully monitor 30 RDS db.t3.medium instances (2 CPUs and 4GB of RAM).
init_config:
instances:
  - dbm: true
    host: example-service-primary.example-host.com
    port: 5432
    username: datadog
    password: 'ENC[datadog_user_database_password]'
    tags:
      - 'env:prod'
      - 'team:team-discovery'
      - 'service:example-service'
  - dbm: true
    host: example-service–replica-1.example-host.com
    port: 5432
    username: datadog
    password: 'ENC[datadog_user_database_password]'
    tags:
      - 'env:prod'
      - 'team:team-discovery'
      - 'service:example-service'
  - dbm: true
    host: example-service–replica-2.example-host.com
    port: 5432
    username: datadog
    password: 'ENC[datadog_user_database_password]'
    tags:
      - 'env:prod'
      - 'team:team-discovery'
      - 'service:example-service'
    [...]

Monitoring multiple databases on a database host

Use the database_autodiscovery option to permit the Agent to discover all databases on your host to monitor. You can specify include or exclude fields to narrow the scope of databases discovered. See the sample postgres.d/conf.yaml for more details.

init_config:
instances:
  - dbm: true
    host: example-service-primary.example-host.com
    port: 5432
    username: datadog
    password: 'ENC[datadog_user_database_password]'
    database_autodiscovery:
      enabled: true
      # Optionally, set the include field to specify
      # a set of databases you are interested in discovering
      include:
        - mydb.*
        - example.*
    tags:
      - 'env:prod'
      - 'team:team-discovery'
      - 'service:example-service'

Running custom queries

To collect custom metrics, use the custom_queries option. See the sample postgres.d/conf.yaml for more details.

init_config:
instances:
  - dbm: true
    host: localhost
    port: 5432
    username: datadog
    password: 'ENC[datadog_user_database_password]'
    custom_queries:
    - metric_prefix: employee
      query: SELECT age, salary, hours_worked, name FROM hr.employees;
      columns:
        - name: custom.employee_age
          type: gauge
        - name: custom.employee_salary
           type: gauge
        - name: custom.employee_hours
           type: count
        - name: name
           type: tag
      tags:
        - 'table:employees'

Monitoring relation metrics for multiple databases

In order to collect relation metrics (such as postgresql.seq_scans, postgresql.dead_rows, postgresql.index_rows_read, and postgresql.table_size), the Agent must be configured to connect to each database (by default, the Agent only connects to the postgres database).

Specify a single “DBM” instance to collect DBM telemetry from all databases. Use the database_autodiscovery option to avoid specifying each database name.

init_config:
instances:
  # This instance is the "DBM" instance. It will connect to the
  # all logical databases, and send DBM telemetry from all databases
  - dbm: true
    host: example-service-primary.example-host.com
    port: 5432
    username: datadog
    password: 'ENC[datadog_user_database_password]'
    database_autodiscovery:
      enabled: true
      exclude:
        - ^users$
        - ^inventory$
    relations:
      - relation_regex: .*
  # This instance only collects data from the `users` database
  # and collects relation metrics from tables prefixed by "2022_"
  - host: example-service-primary.example-host.com
    port: 5432
    username: datadog
    password: 'ENC[datadog_user_database_password]'
    dbname: users
    dbstrict: true
    relations:
      - relation_regex: 2022_.*
        relkind:
          - r
          - i
  # This instance only collects data from the `inventory` database
  # and collects relation metrics only from the specified tables
  - host: example-service-primary.example-host.com
    port: 5432
    username: datadog
    password: 'ENC[datadog_user_database_password]'
    dbname: inventory
    dbstrict: true
    relations:
      - relation_name: products
      - relation_name: external_seller_products

Collecting schemas

To enable this feature, use the collect_schemas option. You must also configure the Agent to connect to each logical database.

Use the database_autodiscovery option to avoid specifying each logical database. See the sample postgres.d/conf.yaml for more details.

init_config:
# This instance only collects data from the `users` database
# and collects relation metrics only from the specified tables
instances:
  - dbm: true
    host: example-service-primary.example-host.com
    port: 5432
    username: datadog
    password: 'ENC[datadog_user_database_password]'
    dbname: users
    dbstrict: true
    collect_schemas:
      enabled: true
    relations:
      - products
      - external_seller_products
  # This instance detects every logical database automatically
  # and collects relation metrics from every table
  - dbm: true
    host: example-service–replica-1.example-host.com
    port: 5432
    username: datadog
    password: 'ENC[datadog_user_database_password]'
    database_autodiscovery:
      enabled: true
    collect_schemas:
      enabled: true
    relations:
      - relation_regex: .*

Working with hosts through a proxy

If the Agent must connect through a proxy such as the Cloud SQL Auth proxy, all telemetry is tagged with the hostname of the proxy rather than the database instance. Use the reported_hostname option to set a custom override of the hostname detected by the Agent.

init_config:
instances:
  - dbm: true
    host: localhost
    port: 5000
    username: datadog
    password: 'ENC[datadog_user_database_password]'
    reported_hostname: example-service-primary
  - dbm: true
    host: localhost
    port: 5001
    username: datadog
    password: 'ENC[datadog_user_database_password]'
    reported_hostname: example-service-replica-1

Instalar la integración de RDS

Para ver métricas de infraestructura de AWS, como la CPU, junto con la telemetría de la base de datos en DBM, instala la integración RDS (opcional).

Solucionar problemas

Si ya instalaste y configuraste las integraciones y el Agent como se describe, pero no funcionan como se esperaba, consulta Solucionar problemas.

Referencias adicionales

Más enlaces, artículos y documentación útiles: