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:
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. 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.), el Agent 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.
Necesario 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.track
all
Opcional. Habilita el seguimiento de sentencias dentro de procedimientos almacenados y funciones.
pg_stat_statements.max
10000
Opcional. 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_utility
off
Opcional. 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_timing
on
Opcional. Habilita la recopilación de los tiempos de lectura y escritura de bloques para las consultas.
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:
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.
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.
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"
Cuando se te pida una contraseña, utiliza la que introdujiste al crear el usuario datadog.
Para monitorizar hosts de Cloud SQL, 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.
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 GCE para que el Agent recopile desde una base de datos Cloud SQL:
Edita el archivo postgres.d/conf.yaml para que apunte a tu host / port y configura los principales para monitorizar. Ppara conocer todas las opciones de configuración disponibles, consulta la muestra de postgres.d/conf.yaml. La localización del directorio postgres.d depende de tu sistema operativo. Para obtener más información, consulta el directorio de configuración del Agent.
init_config:instances:- dbm:truehost:'<INSTANCE_ADDRESS>'port:5432username:datadogpassword:'ENC[datadog_user_database_password]'## Optional: Connect to a different database if needed for `custom_queries`# dbname: '<DB_NAME>'# After adding your project and instance, configure the Datadog Google Cloud (GCP) integration to pull additional cloud data such as CPU, Memory, etc.gcp:project_id:'<PROJECT_ID>'instance_id:'<INSTANCE_ID>'
Para configurar el Database Monitoring Agent que se ejecuta en un contenedor de Docker, como en Google Cloud Run, puedes definir las plantillas de integración Autodiscovery como etiquetas (labels) de Docker en tu contenedor del Agent.
Nota: El Agent debe tener permiso de lectura en el socket de Docker para que las etiquetas (labels) de Autodiscovery funcionen.
Ponte en marcha rápidamente con el siguiente comando para ejecutar el Agent desde tu línea de comandos. Sustituye los valores para que coincidan con tu cuenta y tu entorno:
Las etiquetas también pueden especificarse en un Dockerfile, por lo que puedes crear y desplegar un Agent personalizado sin cambiar la configuración de tu infraestructura:
Si tienes un clúster de Kubernetes, utiliza el Datadog Cluster Agent para la Monitorización de base de datos.
Sigue las instrucciones para habilitar checks de clúster, si no están habilitados en tu clúster de Kubernetes. Puedes declarar la configuración de Postgres mediante archivos estáticos montados en el contenedor del Cluster Agent o utilizando anotaciones de servicios:
Realiza los siguientes pasos para instalar el Datadog Cluster Agent en tu clúster de Kubernetes. Sustituye los valores para que coincidan con tu cuenta y tu entorno.
Para configurar un check de clúster con un archivo de configuración montado, monta el archivo de configuración del contenedor del Cluster Agent en la ruta: /conf.d/postgres.yaml:
cluster_check:true# Asegúrate de incluir esta marcainit_config:instances:- dbm:truehost:'<INSTANCE_ADDRESS>'port:5432username:datadogpassword:'ENC[datadog_user_database_password]'# Después de añadir tu proyecto e instancia, configura la integración de Datadog con GCP para extraer datos de nube adicionales, como CPU y memoria, entre otros.gcp:project_id:'<PROJECT_ID>'instance_id:'<INSTANCE_ID>'
En lugar de integrar un archivo, puedes declarar la configuración de la instancia como servicio de Kubernetes. Para configurar este check en un Agent que se ejecuta en Kubernetes, crea un servicio en el mismo espacio de nombres que el Datadog Cluster Agent:
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.
In these cases, Datadog recommends limiting the number of instances per Agent to a maximum of 10 database instances to guarantee reliable performance.
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:truehost:example-service-primary.example-host.comport:5432username:datadogpassword:'ENC[datadog_user_database_password]'database_autodiscovery:enabled:true# Optionally, set the include field to specify# a set of databases you are interested in discoveringinclude:- mydb.*- example.*tags:- 'env:prod'- 'team:team-discovery'- 'service:example-service'
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:truehost:example-service-primary.example-host.comport:5432username:datadogpassword:'ENC[datadog_user_database_password]'database_autodiscovery:enabled:trueexclude:- ^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.comport:5432username:datadogpassword:'ENC[datadog_user_database_password]'dbname:usersdbstrict:truerelations:- 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.comport:5432username:datadogpassword:'ENC[datadog_user_database_password]'dbname:inventorydbstrict:truerelations:- relation_name:products- relation_name:external_seller_products
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 tablesinstances:- dbm:truehost:example-service-primary.example-host.comport:5432username:datadogpassword:'ENC[datadog_user_database_password]'dbname:usersdbstrict:truecollect_schemas:enabled:truerelations:- products- external_seller_products# This instance detects every logical database automatically# and collects relation metrics from every table- dbm:truehost:example-service–replica-1.example-host.comport:5432username:datadogpassword:'ENC[datadog_user_database_password]'database_autodiscovery:enabled:truecollect_schemas:enabled:truerelations:- relation_regex:.*
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.