¿Qué métricas de su implementación de PostgreSQL debe monitorear? Esta serie de publicaciones de blog tiene como objetivo proporcionar un conjunto básico mínimo de acciones de monitoreo esenciales que debe implementar para garantizar la salud y la estabilidad de sus servidores de Postgres.
Esta es la segunda parte de una serie de blogs y cubre los parámetros a nivel de base de datos. El primero cubrió los parámetros a nivel de clúster.
Parte 2:Nivel de base de datos
En esta parte, analizamos las métricas y la información que debe monitorearse para cada base de datos importante que utilice.
La mayoría de las consultas SQL enumeradas a continuación deben ejecutarse mientras está conectado a la base de datos en cuestión.
1. Clientes Conectados
Los clientes conectados consumen recursos del sistema operativo y del sistema. Postgres tiene una arquitectura de proceso por cliente, y demasiados clientes pueden ralentizar los tiempos de respuesta de consulta para todos. Considere usar PgBouncer o pgpool para reducir la cantidad de conexiones que el servidor de Postgres tendrá que atender.
Esté atento a los cambios en la línea de base después de las actualizaciones de la aplicación y las sobretensiones en las conexiones debido al aumento del tráfico.
Acción:Supervise el número máximo de clientes conectados durante cada día/semana, investigue los cambios en la tendencia.
Cómo:
-- returns the number of clients connected for each database
SELECT datname, count(*)
FROM pg_stat_activity
GROUP BY datname;2. Tamaño
El tamaño real del disco utilizado por la base de datos debe ser monitoreado. En la mayoría de los casos, el tamaño de la base de datos sigue creciendo, por lo que es la tasa de crecimiento lo que es más interesante. Una vez más, tenga cuidado con el aumento de la tasa de crecimiento después del lanzamiento de nuevas aplicaciones.
Acción:Supervisar el crecimiento del tamaño de la base de datos cada semana/mes, investigar tendencias, reaprovisionar.
Cómo:
-- returns the size for each database
SELECT datname, pg_size_pretty(pg_database_size(datname))
FROM pg_database;3. Inflación de mesa en todas las mesas
Debido a la arquitectura MVCC de Postgres, las versiones anteriores de las filas se encuentran en los archivos de datos físicos de cada tabla y se denominan hinchar. . La operación para borrar las versiones de fila obsoletas se llama vacuum . Postgres ejecuta un proceso en segundo plano llamado autovacuum , que selecciona tablas candidatas (en función de parámetros configurables) y las aspira por usted.
Bloat ralentiza las operaciones de la tabla y desperdicia espacio en el disco, y puede desaparecer incluso con autovacuum. Se requiere el monitoreo de la expansión, como un número absoluto de bytes, así como un porcentaje (de datos muertos a datos totales). Esto se puede hacer a nivel de la base de datos como un total en todas las tablas, con la posibilidad de profundizar en las "tablas más infladas".
Acción:Supervise continuamente la expansión total como bytes y porcentaje, alerta si los valores superan un umbral establecido.
Cómo:
Use check_postgres orpgmetrics para obtener estimaciones de hinchamiento. Consulte la wiki para obtener más información.
4. Aumento del índice en todos los índices
Los índices inflados pueden ralentizar las inserciones y reducir el rendimiento de búsqueda. Supervise el exceso de índices como valor absoluto (número de bytes) y como porcentaje. Los índices tendrán que ser reconstruidos cuando estén demasiado hinchados.
Acción:Supervise continuamente la expansión total como bytes y porcentaje, alerta si los valores superan un umbral establecido.
Cómo:
Use check_postgres orpgmetrics para obtener estimaciones de hinchamiento. Consulte la wiki para obtener más información.
5. Transacciones de larga duración
Las transacciones abiertas durante demasiado tiempo no son buenas noticias para PostgreSQL. Las transacciones de ejecución prolongada pueden provocar la retención de archivos WAL, pueden aferrarse a bloqueos y evitar el vacío. Las aplicaciones deben estar diseñadas para mantener la duración de las transacciones lo más baja posible.
Un backend que ejecuta una transacción de larga duración se puede eliminar con pg_cancel_backend() y pg_terminate_backend() funciones.
Acción:Supervise continuamente el recuento de transacciones que se han estado ejecutando durante más de un tiempo establecido, alerta si los valores superan un umbral establecido.
Cómo:
-- returns the count of transactions that have been running for more than a day
SELECT count(*)
FROM pg_stat_activity
WHERE xact_start < now() - '24 hours'::interval;6. Interbloqueos
En PostgreSQL, los backends colocan bloqueos en las filas y tablas implícitamente a medida que se ejecutan consultas que modifican las filas. Las consultas también pueden colocar bloqueos explícitos (como SELECT .. FOR UPDATE ). Al igual que en la programación de subprocesos múltiples, dos transacciones que colocan bloqueos, ya sea implícita o explícitamente, en orden opuesto pueden resultar en un interbloqueo.
PostgreSQL detectará interbloqueos y revertirá una de las transacciones involucradas (Todos los bloqueos retenidos por una transacción se liberan cuando se confirma o revierte). Los detalles se registrarán en el destino de registro de PostgreSQL.
Las aplicaciones deben estar diseñadas para evitar la posibilidad de interbloqueo. También pueden optar por volver a intentar una transacción en caso de interbloqueo.
Acción:Supervise los recuentos de interbloqueos cada día/semana, rediseñe la aplicación para reducir el recuento, investigue los cambios.
Cómo:
Las ocurrencias de interbloqueos, junto con información adicional, se registran en el archivo de registro de PostgreSQL. Utilice pgmetrics, pgbadgeru otras herramientas de procesamiento de registros específicas de PostgreSQL para extraer esta información.
7. Aspiradora más antigua
El aspirado regular de las mesas, ya sea con autovacío o con trabajos programados, o manualmente, es imprescindible para mantener las operaciones de la mesa rápidas. Sin embargo, las aspiradoras pueden fallar por varias razones, incluidas transacciones de ejecución prolongada, ranuras de replicación inactivas, etc.
Dado que la limpieza periódica de las tablas es muy importante en el mundo de Postgres, es mejor comprobar periódicamente si todas las tablas se han aspirado al menos una vez en un intervalo determinado.
Y aunque tienden a estar fuera de la vista y de la mente, las tablas de catalogación del sistema también deben aspirarse.
Acción:compruebe continuamente si alguna mesa no se ha aspirado en el último número de horas/días establecido, alerta si hay alguna.
Cómo:
-- returns the top 5 tables vacuumed least recently
SELECT schemaname || '.' || relname, now()-last_vacuum
FROM pg_stat_all_tables
ORDER BY last_vacuum ASC NULLS LAST LIMIT 5;
-- returns all tables that have not been vacuumed in the last 7 days
SELECT schemaname || '.' || relname, now()-last_vacuum
FROM pg_stat_all_tables
WHERE last_vacuum < now() - '7 days'::interval;8. Análisis más antiguo
Para ejecutar sus consultas SELECT, el planificador de consultas prepara un plan de ejecución que describe qué índices y tablas deben leerse y cómo. Para elaborar un plan de ejecución eficiente, el planificador necesita tener estadísticas sobre la distribución de valores, tamaños de tuplas, etc. Dicha información estadística sobre los datos en una tabla es recopilada y mantenida por analyze operaciones. Las tablas con estadísticas actualizadas dan como resultado consultas más rápidas y menos E/S.
El proceso de vacío automático mencionado anteriormente normalmente también ejecuta ANALIZAR sobre la mesa aspira para mantener actualizada esta información. Sin embargo, esto por sí solo podría no proporcionar suficiente cobertura de análisis para sus tablas. Querrá complementar ejecutando ANALYZE como trabajos programados o después de cambios significativos en la tabla.
En aras del rendimiento de las consultas, es mejor verificar continuamente si todas las tablas se han analizado al menos una vez en un intervalo establecido.
Acción:Verifique continuamente si alguna tabla no ha sido analizada en el último número de horas/días establecido, alerta si hay alguna.
Cómo:
-- returns the top 5 tables analyzed least recently
SELECT schemaname || '.' || relname, now()-last_analyze
FROM pg_stat_all_tables
ORDER BY last_analyze ASC NULLS LAST LIMIT 5;
-- returns all tables that have not been analyzed in the last 7 days
SELECT schemaname || '.' || relname, now()-last_analyze
FROM pg_stat_all_tables
WHERE last_analyze < now() - '7 days'::interval;Recopilación de estas métricas
Las secciones anteriores proporcionan instrucciones SQL para extraer las métricas necesarias de un servidor Postgres en ejecución. Si prefiere no escribir los guiones usted mismo, consulte la herramienta de código abierto pgmetrics. Puede recopilar las métricas anteriores y más, e informarlas en formato de texto y JSON.
Puede enviar directamente los informes de pgmetrics a nuestra oferta comercial, pgDash, que almacena y procesa estos informes para mostrar gráficos y generar alertas.
Siguiente
La siguiente parte de esta serie cubrirá las métricas a nivel de tabla, índice y sistema. ¡Estén atentos!
