¿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 tercera y última parte de una serie de blogs y cubre métricas a nivel de tablas, índices y sistemas. El primero cubría las métricas a nivel de clúster y el segundo cubría las métricas a nivel de base de datos.
Nivel de mesa
Por lo general, los datos en una base de datos siguen la regla 80-20. El 20% de las tablas contienen la mayoría de los datos y son las que más acceden o mutan. La configuración de monitoreo adicional solo para estas tablas puede proporcionar información importante pero de bajo volumen.
Aquí hay algunas métricas a nivel de tabla que vale la pena mirar:
1. Tamaño de la mesa
El tamaño real del disco utilizado por la tabla debe ser monitoreado. En la mayoría de los casos, la tabla sigue creciendo, por lo que es la tasa de crecimiento lo que es más interesante.
A menudo sucede que la tasa de crecimiento cambia después del lanzamiento de una nueva versión de la aplicación, o un cambio de referencia en los patrones de tráfico/carga/entrada de la propia aplicación. Dichos cambios deben investigarse, al menos para verificar que la nueva tasa sea sostenible para el hardware aprovisionado.
Acción:Supervisar el aumento de tamaño de la tabla cada semana/mes, investigar cambios abruptos.
Cómo:
-- returns the size for each table
SELECT schemaname || '.' || relname,
pg_size_pretty(pg_table_size(schemaname || '.' || relname))
FROM pg_stat_user_tables;2. Inflar la mesa
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).
Esta métrica se puede monitorear a nivel de tabla individual, o como un agregado en tablas seleccionadas, o a nivel de base de datos.
Acción:Supervisar continuamente el aumento de la tabla en bytes y porcentajes, alertar si los valores superan un umbral establecido, VACÍAR según sea necesario.
Cómo:
Use check_postgres orpgmetrics para obtener estimaciones de hinchamiento. Consulte la wiki para obtener más información.
3. Exploraciones secuenciales
Cuando se ejecutan consultas que no utilizan de manera óptima los índices disponibles, o si la información estadística asociada con una tabla está demasiado desactualizada, Postgres podría terminar teniendo que revisar cada fila de la tabla. Esto se llama un análisis secuencial , y no es muy deseable en el caso general. Lo que sería mejor tener es un escaneo de índice , donde se accede indirectamente a las filas de una tabla a través de una búsqueda de índice.
PostgreSQL puede decirle cuántas veces se escaneó secuencialmente una tabla y cuántas veces se usó un índice. Puede usar esto para monitorear el número de escaneos secuenciales (si desea evitarlos por completo) o como un porcentaje del total de escaneos.
Acción:monitorear continuamente la secuencia. recuento o porcentaje de escaneos, alerta si el valor supera un umbral establecido.
Cómo:
-- returns the no. of seq. scans and the percentage of seq. scans for each table
SELECT schemaname || '.' || relname,
seq_scan,
round(seq_scan::numeric*100/(seq_scan+idx_scan), 1)
FROM pg_stat_user_tables
WHERE seq_scan+idx_scan > 0;Nivel de índice
1. Tamaño del índice
Los índices pueden ocupar un espacio considerable en el disco. Cada índice de una tabla puede ocupar potencialmente tanto espacio en disco como la propia tabla. Es útil controlar el tamaño total de los índices en una base de datos, o los índices de tablas importantes, especialmente en implementaciones donde los índices se pueden crear a través de procesos automáticos.
Los índices irrazonablemente grandes pueden deberse a una hinchazón o simplemente a un índice mal diseñado. En cualquier caso, solucionar la causa (ya sea reconstruyendo el índice o refactorizando la consulta/índice) puede generar tiempos de consulta más rápidos, por lo que vale la pena investigar índices grandes.
Acción:Supervise el tamaño total de los índices interesantes durante cada semana/mes, investigue cuando sea irrazonablemente grande.
Cómo:
-- returns the size for each index
SELECT schemaname || '.' || indexrelname,
pg_size_pretty(pg_total_relation_size(indexrelid))
FROM pg_stat_user_indexes;2. Hinchazón del índice
Los índices también pueden inflarse. Hay demasiados factores, incluida la carga de trabajo de la tabla, el tipo de índice, la versión de Postgres y más, que deciden qué tan hinchado se vuelve un índice. Los índices inflados pueden ralentizar las inserciones y reducir el rendimiento de búsqueda. Supervise la expansión de los í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 del índice 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.
3. Proporción de aciertos de caché
PostgreSQL almacena en memoria caché regiones de índices (y también tablas) a las que se accede con frecuencia. Si ha ajustado sus consultas para que no toquen las tablas excepto para recuperar filas, el siguiente paso es asegurar la máxima residencia en caché para esos índices importantes que realmente están acelerando sus consultas.
La utilización de la memoria caché de un índice se puede medir por la tasa de aciertos de la memoria caché, que es el porcentaje de bloques del índice que se leyeron de la memoria caché al número total de bloques leídos.
Acción:Supervise continuamente el porcentaje de la tasa de aciertos de la memoria caché y envíe una alerta si el valor cae por debajo de un umbral establecido. Investigue valores bajos para índices importantes.
Cómo:
-- returns the cache hit ratio as a percentage, for each index
SELECT schemaname || '.' || indexrelname AS index_name,
round(pg_stat_get_blocks_hit(indexrelid)::numeric*100 /
pg_stat_get_blocks_fetched(indexrelid), 1) AS cache_hit_ratio
FROM pg_stat_user_indexes
WHERE pg_stat_get_blocks_fetched(indexrelid) > 0
ORDER BY cache_hit_ratio DESC;Nivel del sistema
Además de las métricas de PostgreSQL, es importante realizar un seguimiento de algunas métricas de la máquina o VM en la que está ejecutando Postgres. Puede usar cualquier solución de monitoreo popular para esto, o incluso capturarlos y rastrearlos usted mismo.
1. Memoria usada
Los sistemas Linux modernos tienen una contabilidad de memoria compleja. Recomendamos monitorear la "memoria usada", que es la memoria que queda después de contabilizar la memoria marcada como libre , como amortiguadores , como almacenado en caché , y como losa . Los búferes y la memoria caché ceden bajo presión, al igual que la mayoría (generalmente más del 95 %) de losa.
Sin embargo, la memoria utilizada debe medirse durante un período suficientemente largo. Si tiene trabajos por lotes, informes, ETL, etc. que se ejecutan los fines de semana, entonces el período sería de una semana. La métrica real que necesitará monitorear es la memoria máxima utilizada durante este período.
Por lo general, a medida que crece el tamaño de la base de datos, este valor tiende a aumentar. Tendrá que asegurarse de que el uso máximo de la memoria se encuentre dentro de un límite cómodo de memoria disponible, como, por ejemplo, entre el 60 y el 80 %. Si no se hace esto, las cargas de trabajo de Analytics/OLAP fallarán por falta de memoria.
Acción:controle la memoria máxima utilizada durante una semana/quincena, alerta si supera un umbral establecido, reaprovisionamiento.
Cómo :
La memoria utilizada viene dada por MemUsed = MemTotal - MemFree - MemBuffers - MemCached - MemSlab , donde Mem* los campos son de /proc/meminfo . Para obtener más información, consulte este artículo de RedHat.
2. Promedio de carga
El valor promedio de carga simple sigue siendo la forma más fácil y rápida de estimar la carga en un servidor. Esto es especialmente cierto para los servidores de Postgres, ya que cada backend es un proceso de SO separado, y tener más de ellos en un estado ejecutable aumentará el valor promedio de carga.
Para un servidor de Postgres dado, el promedio de carga debe permanecer dentro de un rango razonable durante un ciclo comercial (como una semana, incluidas las ejecuciones de trabajos por lotes).
Acción:Supervise el promedio de carga máxima durante cada día/semana, investigue las tendencias crecientes.
Cómo :
Los promedios de carga de 1 minuto, 5 minutos y 15 minutos son los primeros 3 campos de la primera línea en el archivo /proc/loadavg .
3. Espacio libre en disco
El último elemento de nuestra lista es el elemento más obvio para monitorear:la cantidad de espacio libre en disco en cada sistema de archivos utilizado por su servidor PostgreSQL, incluidos espacios de tabla, directorios de archivos WAL, directorios de respaldo y archivos de registro del servidor. En los casos en que se creen demasiados archivos (cientos de millones) en un solo sistema de archivos, asegúrese de que también se supervise el recuento de inodos libres. La falta de inodos también se informa como poco espacio en disco.
Acción:Supervise continuamente el espacio libre en disco y el uso de inodos en todos los sistemas de archivos relevantes, alerta si los valores caen por debajo de un umbral establecido.
Cómo :
El espacio libre en disco en un sistema de archivos no se puede recuperar directamente leyendo cualquier archivo en /proc . Puede usar stat -f /path/to/mount o incluso df para averiguar el espacio en disco utilizado, libre y reservado para un sistema de archivos montado específico.
Referencia rápida
Aquí hay una lista completa de todas las métricas que hemos discutido hasta ahora en esta serie. Recuerde que estos son solo el conjunto mínimo y más esencial de métricas que debe monitorear para detectar cuándo las cosas están a punto de volverse inestables con su implementación de PostgreSQL.
Nivel de clúster
- Rango de ID de transacción
- Número de servidores
- Ranuras de replicación inactivas
- Backends a la espera de bloqueos
- Backends inactivos en transacción
- Retraso de replicación para conexiones activas
- Retraso de replicación para ranuras de replicación
- Recuento de archivos WAL
- Recuento de archivos WAL listos para archivar
Nivel de base de datos
- Clientes conectados
- Tamaño
- Inflación de mesa en todas las mesas
- Inflación del índice en todos los índices
- Transacciones de larga duración
- Interbloqueos
- Aspiradora más antigua
- Análisis más antiguo
Nivel de mesa
- Tamaño de la mesa
- Inflación de mesa
- Escaneos secuenciales
Nivel de índice
- Tamaño del índice
- Inflación del índice
- Proporción de aciertos de caché
Nivel-del-Sistema
- Memoria usada
- Promedio de carga
- Espacio libre en disco
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.
