¿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.
La primera parte cubre los parámetros a nivel de clúster.
Parte 1:Nivel de clúster
En la jerga de Postgres, un clúster es un conjunto de bases de datos administradas por una sola instancia de servidor de Postgres. Funciones como la replicación y el archivo WAL funcionan a nivel de clúster.
1. Rango de ID de transacción
Desde la perspectiva de un cliente normal, los archivos de datos de un clúster de PostgreSQL parecerán contener la instantánea de los datos modificados por la última transacción confirmada. Sin embargo, debido a la arquitectura MVCC de Postgres, los archivos físicos contienen no solo los datos de la transacción más reciente, sino también de una variedad de transacciones que terminan con la última. (Aspirado regular se deshace de los datos de las transacciones anteriores).
Cada transacción tiene un identificador entero único de 32 bits, denominado ID de transacción. . Por varias razones, la diferencia entre la primera y la última ID de transacción debe ser inferior a 2, que es de alrededor de 2 mil millones. Mantener el rango muy por debajo de este límite es imprescindible. – lea esta historia de la vida real de lo que sucede de otra manera.
Acción:monitoree continuamente el rango de ID de transacciones, avise si el valor excede un umbral establecido.
Cómo:
-- returns the first and last transactions IDs for the cluster
SELECT oldest_xid::text::int as first,
regexp_replace(next_xid, '^[0-9]+:', '')::int-1 as last
FROM pg_control_checkpoint();
-- returns the transaction ID range for each database
SELECT datname, age(datfrozenxid)
FROM pg_database;2. Número de servidores
Cada backend representa un cliente conectado al servidor o un proceso backend del sistema (como trabajador de vacío automático, escritor de fondo, etc.). Cada backend es también un proceso del sistema operativo que consume recursos del sistema operativo como memoria, descriptores de archivos abiertos, etc. Demasiados backends, generalmente debido a demasiados clientes o demasiadas consultas de ejecución prolongada, pueden ejercer presión sobre los recursos del sistema operativo y ralentizar los tiempos de respuesta de las consultas para cada cliente.
Acción:Supervise el recuento máximo de back-end cada día/semana, investigue las tendencias crecientes.
Cómo:
-- returns the count of currently running backends
SELECT count(*)
FROM pg_stat_activity;3. Ranuras de replicación inactivas
Las ranuras de replicación se marcan como "inactivas" cuando el cliente de replicación conectado a la ranura se desconecta. Las ranuras de replicación inactivas hacen que se retengan los archivos WAL, ya que deberán enviarse al cliente cuando se vuelva a conectar y las ranuras se activen. De hecho, lo primero que debe comprobar si el recuento de archivos WAL no disminuye es ver si tiene ranuras de replicación inactivas.
A menudo, las ranuras de replicación inactivas son el resultado de un cliente de copia de seguridad que se eliminó, un esclavo que se eliminó, promociones, conmutación por error y similares.
Acción:comprobar continuamente si hay ranuras de replicación inactivas y alertar si las hay.
Cómo:
-- returns the count of inactive replication slots
SELECT count(*)
FROM pg_replication_slots
WHERE NOT active;4. Backends esperando bloqueos
Las sentencias SQL pueden causar explícita o implícitamente que otras sentencias SQL esperen. Por ejemplo, ejecutar "SELECCIONAR .. PARA ACTUALIZAR" declara explícitamente un bloqueo para las filas seleccionadas, y ejecutar "ACTUALIZAR" coloca bloqueos exclusivos de filas implícitas. Otras sentencias SQL cuando encontrar el bloqueo tendrá que esperar hasta que la primera declaración renuncie al bloqueo, antes de continuar con su ejecución.
Esto puede manifestarse como un rendimiento lento de la aplicación durante las ejecuciones de informes semanales, transacciones/páginas web agotadas y similares.
Si bien no se puede evitar una cierta cantidad de bloqueo, una tendencia creciente de backends que esperan bloqueos generalmente requiere que se reestructuren las consultas o la lógica de la aplicación.
Acción:Supervise la cantidad máxima de backends en espera de bloqueos cada día/semana, investigue las tendencias crecientes.
Cómo:
-- returns the count of backends waiting on locks
SELECT count(*)
FROM pg_stat_activity
WHERE wait_event = 'Lock';5. Backends inactivos en transacción
Las transacciones de ejecución prolongada no son muy agradables de tener en el mundo de PostgreSQL. Pueden hacer que se acumulen archivos WAL, evitar el vacío automático y el vacío manual, y consumir recursos. No se puede hacer mucho con las transacciones genuinas que toman mucho tiempo en completarse, pero hay casos como aplicaciones/scripts que se comportan mal y el cliente psql ocasional que inicia transacciones pero no las cierra. Los backends que atienden a dichos clientes aparecen como "inactivos en transacción".
Los backends que están inactivos en la transacción deben detectarse y apagarse antes de que comiencen a afectar la estabilidad del sistema.
Acción:supervise continuamente la cantidad de backends inactivos en la transacción, revise si se encuentra alguno.
Cómo:
-- returns the count of backends waiting on locks
SELECT count(*)
FROM pg_stat_activity
WHERE state = 'idle in transaction';6. Retraso de replicación para conexiones activas
Cuando hay clientes de replicación de transmisión activos (como hot standbys) o clientes de replicación lógica activos, Postgres ejecuta un backend del sistema llamado Remitente WAL para cada cliente activo (conectado). El remitente WAL es responsable de enviar los datos del registro WAL que el cliente necesita.
Los clientes de replicación generalmente intentan mantenerse al día tanto como pueden con el principal. A veces, sin embargo, la tasa de generación de WAL en el lado primario puede volverse más alta que la tasa a la que el cliente puede consumirlos. Esto da como resultado un retraso en la replicación para cada conexión de replicación.
PostgreSQL proporciona un mecanismo para consultar el retraso de escritura (cantidad de bytes enviados pero no escritos en el disco del cliente), demora de descarga (cantidad de bytes escritos pero no descargados en el disco del cliente) y demora de reproducción (cantidad de bytes descargados pero no reproducidos en el disco del cliente). archivos de base de datos) para cada remitente WAL activo.
Acción:Supervise continuamente los retrasos de replicación para las conexiones activas, alerte si los valores superan los umbrales establecidos.
Cómo:
-- returns the write, flush and replay lags per WAL sender, as described above
SELECT write_lsn - sent_lsn AS write_lag,
flush_lsn - write_lsn AS flush_lag,
replay_lsn - flush_lsn AS replay_lag
FROM pg_stat_replication;7. Retraso de replicación para ranuras de replicación
Los clientes de replicación no solo pueden retrasarse, sino que también pueden desaparecer por completo debido a fallas, cambios de topología o errores humanos. También puede ser por diseño, donde los clientes no siempre están en línea.
Si el cliente está respaldado por una ranura de replicación, PostgreSQL retiene todos los archivos WAL necesarios para que el cliente se reanude desde el punto en que lo dejó. Los archivos WAL se conservarán indefinidamente; no hay forma de establecer un límite. Cuando el cliente se vuelve a conectar, todos los datos retenidos deben transmitirse primero al cliente, lo que puede implicar una gran cantidad de tráfico de disco y de red en el principal. Por estas razones, también debe monitorear el retraso a nivel de ranura.
(Nota:el proceso del remitente WAL se ejecuta solo cuando un cliente está conectado y sale cuando el cliente se desconecta. El método del remitente WAL para medir qué tan atrás está un cliente no funciona cuando un cliente está desconectado).
Acción:Supervise continuamente los retrasos de replicación para las ranuras de replicación lógica, alerte si los valores superan un umbral establecido.
Cómo:
-- returns the replication slot lag in bytes
-- (works only for logical replication slots)
SELECT pg_current_wal_lsn() - confirmed_flush_lsn
FROM pg_replication_slots;8. Recuento de archivos WAL
Administrar archivos WAL puede ser una tarea exasperante, especialmente si tiene clientes de replicación de transmisión o archivo WAL. Los recuentos de archivos WAL pueden comenzar a aumentar sin ningún motivo aparente, el proceso de archivado WAL puede no mantenerse al día con la tasa de generación WAL y el tamaño total del archivo WAL puede llegar a los terabytes.
Como mínimo, debe controlar la cantidad de archivos WAL presentes en el directorio de su base de datos y asegurarse de que la cantidad parezca razonable para su implementación.
Acción:Supervise continuamente el recuento de archivos WAL, alerte si el valor supera un umbral establecido.
Cómo:
-- returns the number of WAL files present in the pg_wal directory (v10+)
SELECT count(*)
FROM pg_ls_waldir();
-- same, for v9.x
SELECT count(*)
FROM pg_ls_dir('pg_xlog')
WHERE pg_ls_dir ~ '^[0-9A-F]{24}$';
-- can also count the files physically present in $DBDIR/pg_wal
-- /bin/ls -l $DBDIR/pg_wal | grep -c '^-'9. Recuento de archivos WAL listos para archivar
Cuando el archivado WAL está habilitado, PostgreSQL invoca un script de usuario cada vez que se genera un nuevo archivo WAL. Se supone que la secuencia de comandos "archiva" el único archivo WAL para el que se invocó (por lo general, lo copia en otro servidor o en un depósito de S3). Si la secuencia de comandos tarda demasiado en hacer su trabajo, o si falla, el conjunto de archivos WAL para ser archivado se acumula.
Acción:Supervise continuamente el recuento de archivos WAL listos para archivar y envíe una alerta si el valor supera un umbral establecido.
Cómo:
-- returns the number of WAL files ready to be archived (v12+)
SELECT count(*)
FROM pg_ls_archive_statusdir()
WHERE name ~ '^[0-9A-F]{24}.ready$';
-- same, for v10+
SELECT count(*)
FROM pg_ls_dir('pg_wal/archive_status')
WHERE pg_ls_dir ~ '^[0-9A-F]{24}.ready$';
-- same, for v9.x
SELECT count(*)
FROM pg_ls_dir('pg_xlog/archive_status')
WHERE pg_ls_dir ~ '^[0-9A-F]{24}.ready$';
-- can also count the *.ready files physically present in $DBDIR/pg_wal/archive_status
-- /bin/ls -l $DBDIR/pg_wal/archive_status | grep -c .readyRecopilació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
Otras partes de esta serie cubrirán las métricas a nivel de base de datos, de tabla, de índice y de sistema. ¡Estén atentos!
