Le sugiero que lea la transcripción del informe de Alexey Lesovsky de Data Egret "Fundamentos de la supervisión de PostgreSQL"
En este informe, Alexey Lesovsky hablará sobre los puntos clave de las estadísticas de postgres, qué significan y por qué deben incluirse en el monitoreo; sobre qué gráficos deberían estar en el monitoreo, cómo agregarlos y cómo interpretarlos. El informe será útil para los administradores de bases de datos, administradores de sistemas y desarrolladores interesados en la solución de problemas de Postgres.
Mi nombre es Alexey Lesovsky, represento a Data Egret.
Unas pocas palabras sobre mí. Empecé hace mucho tiempo como administrador de sistemas.
Administré todo tipo de Linux diferente, hice varias cosas relacionadas con Linux, es decir, virtualización, monitoreo, trabajé con proxies, etc. Pero en algún momento me involucré más en las bases de datos, PostgreSQL. Realmente me gustaba. Y en algún momento, comencé a lidiar con PostgreSQL la mayor parte de mi tiempo de trabajo. Y así, gradualmente, me convertí en un DBA de PostgreSQL.
Y a lo largo de mi carrera, siempre me han interesado los temas de estadística, monitoreo, telemetría. Y cuando era administrador de sistemas, trabajé muy duro en Zabbix. Y escribió un pequeño conjunto de guiones como . Fue bastante popular en su época. Y allí fue posible monitorear cosas importantes muy diferentes, no solo Linux, sino también varios componentes.
Ahora ya estoy haciendo PostgreSQL. Ya estoy escribiendo otra cosa que te permite trabajar con estadísticas de PostgreSQL. Se llama (artículo sobre Habré - ).
Una pequeña introducción. ¿Cuáles son las situaciones con nuestros clientes, con nuestros clientes? Hay algún tipo de accidente asociado con la base de datos. Y cuando la base de datos ya está restaurada, llega el jefe de departamento o el jefe de desarrollo y dice: “Amigos, debemos monitorear la base de datos, porque algo malo pasó y es necesario que esto no vuelva a suceder en el futuro”. Y aquí comienza el interesante proceso de elegir un sistema de monitoreo o adaptar un sistema de monitoreo existente para que pueda monitorear su base de datos: PostgreSQL, MySQL o algunos otros. Y los colegas comienzan a ofrecer: “Escuché que existe tal y tal base de datos. Usémoslo". Los colegas comienzan a discutir entre ellos. Y al final, resulta que elegimos algún tipo de base de datos, pero el monitoreo de PostgreSQL está bastante mal representado y siempre tenemos que terminar algo. Tome algunos repositorios de GitHub, clónelos, adapte scripts, ajústelos de alguna manera. Y al final se convierte en una especie de trabajo manual.
Por lo tanto, en este informe, intentaré brindarle algunos conocimientos sobre cómo elegir el monitoreo no solo para PostgreSQL, sino también para la base de datos. Y para brindarle el conocimiento que le permitirá finalizar su monitoreo para obtener algún beneficio de él, para que pueda monitorear su base de datos con beneficio para prevenir cualquier situación de emergencia que pueda surgir a tiempo.
Y esas ideas que estarán en este informe, se pueden adaptar directamente a cualquier base de datos, ya sea DBMS o noSQL. Por lo tanto, no solo PostgreSQL aquí, sino que habrá muchas recetas sobre cómo hacer esto en PostgreSQL. Habrá ejemplos de consultas, ejemplos de entidades que tiene PostgreSQL para monitorear. Y si su DBMS tiene las mismas cosas que le permiten ponerlos en monitoreo, también puede adaptarlos, agregarlos y estará bien.
no voy a reportar
hable sobre cómo entregar y almacenar métricas. No diré nada sobre el procesamiento posterior de los datos y su suministro al usuario. Y no diré nada sobre alertar.
Pero en el transcurso de la historia, mostraré diferentes capturas de pantallas de monitoreos existentes, de alguna manera los criticaré. No obstante, intentaré no nombrar marcas para no crear publicidad o antipublicidad de estos productos. Por lo tanto, todas las coincidencias son aleatorias y quedan en tu imaginación.
Primero, comprendamos qué es el monitoreo. El monitoreo es una cosa muy importante a tener. Todo el mundo entiende esto. Pero al mismo tiempo, el seguimiento no está relacionado con un producto comercial y no afecta directamente las ganancias de la empresa, por lo que el seguimiento siempre se da en el tiempo de forma residual. Si tenemos tiempo, entonces nos dedicamos a monitorear, si no hay tiempo, entonces está bien, lo pondremos en la cartera de pedidos y algún día volveremos a estas tareas.
Por lo tanto, desde nuestra práctica, cuando llegamos a los clientes, el monitoreo muchas veces está poco desarrollado y no tiene cosas interesantes que nos ayuden a hacer un mejor trabajo con la base de datos. Y, por lo tanto, el monitoreo siempre debe terminarse.
Las bases de datos son cosas tan complejas que también necesita monitorear, porque las bases de datos son un depósito de información. Y la información es muy importante para la empresa, no se puede perder de ninguna manera. Pero al mismo tiempo, las bases de datos son piezas de software muy complejas. Están formados por muchos componentes. Y muchos de estos componentes necesitan ser monitoreados.
Si estamos hablando específicamente de PostgreSQL, entonces se puede representar como un esquema de este tipo, que consta de una gran cantidad de componentes. Estos componentes interactúan entre sí. Y a su vez, PostgreSQL cuenta con el llamado subsistema Stats Collector, que permite recopilar estadísticas sobre el funcionamiento de estos subsistemas y brindar una interfaz al administrador o usuario para que pueda visualizar dichas estadísticas.
Esta estadística se presenta en forma de un conjunto de funciones y vistas (vista). También se les puede llamar tablas. Es decir, utilizando un cliente psql normal, puede conectarse a la base de datos, seleccionar estas funciones y vistas y obtener algunos números específicos sobre el funcionamiento de los subsistemas de PostgreSQL.
Puede agregar estos números a su sistema de monitoreo favorito, dibujar gráficos, agregar funciones y obtener análisis a largo plazo.
Pero en este informe, no cubriré todas estas funciones sin excepción, porque puede tomar un día entero. Me referiré literalmente a dos, tres o cuatro cosas y les diré cómo ayudan a mejorar el monitoreo.
Y si hablamos de monitorear la base de datos, ¿qué se debe monitorear? En primer lugar, necesitamos monitorear la disponibilidad, porque la base de datos es un servicio que brinda acceso a los datos a los clientes y necesitamos monitorear la disponibilidad, y también proporcionar algunas de sus características cualitativas y cuantitativas.
También necesitamos monitorear los clientes que se conectan a nuestra base de datos, porque pueden ser tanto clientes normales como clientes dañinos que pueden dañar la base de datos. También necesitan ser monitoreados y rastreados.
Cuando los clientes se conectan a la base de datos, es obvio que comienzan a trabajar con nuestros datos, por lo que debemos monitorear cómo los clientes trabajan con los datos: con qué tablas, en menor medida con qué índices. Es decir, necesitamos evaluar la carga de trabajo que crean nuestros clientes.
Pero la carga de trabajo también consiste, por supuesto, en solicitudes. Las aplicaciones se conectan a la base de datos, acceden a los datos mediante consultas, por lo que es importante evaluar qué consultas tenemos en la base de datos, monitorear su adecuación, que no estén torcidas, que algunas opciones deben reescribirse y realizarse para que funcionen más rápido y con un mejor rendimiento.
Y dado que estamos hablando de la base de datos, la base de datos siempre son procesos en segundo plano. Los procesos en segundo plano mantienen el rendimiento de la base de datos en un buen nivel, por lo que requieren una cierta cantidad de recursos para ejecutarse. Y, al mismo tiempo, pueden superponerse con los recursos de solicitud del cliente, por lo que el trabajo voraz de los procesos en segundo plano puede afectar directamente el rendimiento de las solicitudes del cliente. Por lo tanto, también deben ser monitoreados y rastreados para que no haya distorsiones en términos de procesos en segundo plano.
Y eso es todo en términos de base de datos de seguimiento permanece en la métrica del sistema. Pero dado que, en su mayor parte, toda nuestra infraestructura va a las nubes, las métricas del sistema de un host individual siempre se desvanecen en segundo plano. Pero en las bases de datos siguen siendo relevantes y, por supuesto, también es necesario monitorear las métricas del sistema.
Con las métricas del sistema, todo está más o menos bien, todos los sistemas de monitoreo modernos ya soportan estas métricas, pero en general, algunos componentes aún no son suficientes y es necesario agregar algunas cosas. También me referiré a ellos, habrá varias diapositivas sobre ellos.
El primer punto del plan es la accesibilidad. ¿Qué es la accesibilidad? La disponibilidad a mi entender es la capacidad de la base para atender conexiones, es decir, la base está levantada, como servicio acepta conexiones de clientes. Y esta accesibilidad puede ser evaluada por algunas características. Estas características son muy convenientes para mostrar en los tableros.
Todo el mundo sabe lo que son los cuadros de mando. Fue entonces cuando echó un vistazo a la pantalla, que resumió la información necesaria. Y ya puede determinar de inmediato si hay un problema en la base de datos o no.
En consecuencia, la disponibilidad de la base de datos y otras características clave siempre se deben poner en los tableros para que esta información esté a mano, siempre con usted. Algunos detalles adicionales que ya ayudan en la investigación de incidentes, en la investigación de algunas situaciones de emergencia, ya deben colocarse en tableros secundarios u ocultarse en enlaces de desglose que conducen a sistemas de monitoreo de terceros.
Un ejemplo de un sistema de monitoreo conocido. Este es un sistema de monitoreo muy bueno. Recopila muchos datos, pero desde mi punto de vista, tiene un concepto extraño de tableros. Hay un enlace "Crear panel". Pero cuando crea un tablero, crea una lista de dos columnas, una lista de gráficos. Y cuando necesita mirar algo, comienza a hacer clic, desplazarse, buscar el gráfico deseado con el mouse. Y esto lleva su tiempo, es decir, no hay cuadros de mando como tales. Sólo hay listas de gráficos.
¿Qué se debe agregar a estos tableros? Puede comenzar con una característica como el tiempo de respuesta. PostgreSQL tiene la vista pg_stat_statements. Está deshabilitado de forma predeterminada, pero es una de las vistas importantes del sistema que siempre debe estar habilitada y utilizada. Almacena información sobre todas las consultas en ejecución que se ejecutaron en la base de datos.
En consecuencia, podemos partir del hecho de que podemos tomar el tiempo de ejecución total de todas las solicitudes y dividirlo por el número de solicitudes utilizando los campos anteriores. Pero esta es una temperatura tan promedio en el hospital. Podemos basarnos en otros campos: el tiempo mínimo de ejecución de la consulta, el máximo y la mediana. E incluso podemos construir percentiles, PostgreSQL tiene las funciones correspondientes para esto. Y podemos obtener algunos números que caracterizan el tiempo de respuesta de nuestra base de datos para solicitudes ya completadas, es decir, no ejecutamos la solicitud falsa 'seleccionar 1' y observamos el tiempo de respuesta, pero analizamos el tiempo de respuesta para solicitudes ya completadas y dibujamos una figura separada, o construimos un gráfico basado en ella.
También es importante realizar un seguimiento de la cantidad de errores que el sistema está generando actualmente. Y para esto puedes usar la vista pg_stat_database. Estamos apuntando al campo xact_rollback. Este campo no solo muestra la cantidad de reversiones que ocurren en la base de datos, sino que también tiene en cuenta la cantidad de errores. En términos relativos, podemos mostrar esta cifra en nuestro tablero y ver cuántos errores tenemos en este momento. Si hay muchos errores, entonces esta ya es una buena razón para mirar los registros y ver qué tipo de errores son y por qué ocurren, y luego invertir y resolverlos.
Puede agregar algo como un tacómetro. Estos son el número de transacciones por segundo y el número de solicitudes por segundo. En términos relativos, puede usar estos números como el rendimiento actual de su base de datos y observar si hay picos en las solicitudes, picos en las transacciones o, por el contrario, si la base de datos está sobrecargada porque se cayó algún tipo de backend. Es importante mirar siempre esta figura y recordar que para nuestro proyecto tal rendimiento es normal, y los valores arriba y abajo ya son problemáticos e incomprensibles, lo que significa que debemos ver por qué tales números .
Para estimar el número de transacciones, podemos volver a consultar la vista pg_stat_database. Podemos agregar la cantidad de confirmaciones y la cantidad de reversiones para obtener la cantidad de transacciones por segundo.
¿Todos entienden que varias solicitudes pueden caber en una transacción? Por lo tanto, TPS y QPS son ligeramente diferentes.
El número de solicitudes por segundo se puede obtener de pg_stat_statements y simplemente calcular la suma de todas las solicitudes ejecutadas. Está claro que comparamos el valor actual con el anterior, restamos, obtenemos el delta, obtenemos la cantidad.
Puede agregar métricas adicionales si lo desea, que también ayudan a evaluar la disponibilidad de nuestra base de datos y rastrear si hubo algún tiempo de inactividad.
Una de estas métricas es el tiempo de actividad. Pero el tiempo de actividad en PostgreSQL es un poco complicado. Te diré por qué. Cuando se inicia PostgreSQL, comienza a informar el tiempo de actividad. Pero si en algún momento, por ejemplo, alguna tarea se estaba ejecutando por la noche, llegó un OOM-killer y terminó por la fuerza el proceso secundario de PostgreSQL, entonces, en este caso, PostgreSQL finaliza la conexión de todos los clientes, restablece el área de memoria fragmentada e inicia la recuperación desde el último puesto de control. Y mientras dura esta recuperación del punto de control, la base de datos no acepta conexiones, es decir, esta situación se puede evaluar como un tiempo de inactividad. Pero esto no restablecerá el contador de tiempo de actividad, ya que tiene en cuenta la hora en que se inició el postmaster desde el primer momento. Por lo tanto, tales situaciones se pueden omitir.
También debe controlar la cantidad de trabajadores que trabajan con aspiradoras. ¿Todos saben qué es autovacuum en PostgreSQL? Este es un subsistema interesante en PostgreSQL. Se han escrito muchos artículos al respecto, se han hecho muchos informes. Mucha discusión sobre el vacío, cómo debería funcionar. Muchos lo consideran un mal necesario. Pero es. Este es algún tipo de recolector de basura que limpia versiones obsoletas de filas que no son necesarias para ninguna de las transacciones y libera espacio en tablas e índices para nuevas filas.
¿Por qué se debe monitorear? Porque la aspiradora a veces duele mucho. Consume una gran cantidad de recursos y las solicitudes de los clientes comienzan a sufrir por esto.
Y debe monitorearse a través de la vista pg_stat_activity, de la que hablaré en la siguiente sección. Esta vista muestra la actividad actual en la base de datos. Y a través de esta actividad, podemos rastrear la cantidad de aspiradoras que están funcionando en este momento. Podemos monitorear los vacíos y ver si hemos excedido el límite, entonces esta es una ocasión para mirar la configuración de PostgreSQL y de alguna manera optimizar el funcionamiento del vacío.
Otra característica de PostgreSQL es que PostgreSQL está muy harto de transacciones largas. Especialmente, de transacciones que cuelgan durante mucho tiempo y no hacen nada. Estos son los llamados stat inactivos en la transacción. Tal transacción tiene bloqueos, evita que el vacío funcione. Y como resultado, las mesas se hinchan, aumentan de tamaño. Y las consultas que funcionan con estas tablas, comienzan a funcionar más lentamente, porque necesita trasladar todas las versiones antiguas de las filas de la memoria al disco y viceversa. Por lo tanto, el tiempo, la duración de las transacciones más largas, las solicitudes de vacío más largas también deben monitorearse. Y si vemos algunos procesos que se han estado ejecutando durante mucho tiempo, durante más de 10-20-30 minutos para una carga OLTP, entonces debemos prestarles atención y forzarlos a finalizar, u optimizar la aplicación para que no se llaman y no cuelgan tanto tiempo. Para una carga analítica lo normal es 10-20-30 minutos, también los hay más largos.
A continuación tenemos la opción con clientes conectados. Cuando ya hemos formado un tablero, publicado métricas clave de accesibilidad en él, también podemos agregar información adicional sobre los clientes conectados allí.
La información sobre los clientes conectados es importante porque, desde el punto de vista de PostgreSQL, existen diferentes tipos de clientes. Hay buenos clientes y hay malos clientes.
Un ejemplo sencillo. Por cliente, me refiero a la aplicación. La aplicación se ha conectado a la base de datos e inmediatamente comienza a enviar sus solicitudes allí, la base de datos las procesa y las ejecuta, y devuelve los resultados al cliente. Estos son buenos y correctos clientes.
Hay situaciones que el cliente está conectado, mantiene la conexión, pero no hace nada. Está en estado inactivo.
Pero hay malos clientes. Por ejemplo, el mismo cliente se conectó, abrió una transacción, hizo algo en la base de datos y luego ingresó al código, por ejemplo, para acceder a una fuente externa o procesar allí los datos recibidos. Pero al mismo tiempo, no cerró la transacción. Y la transacción se cuelga en la base de datos y mantiene el candado en la línea. Este es un mal estado. Y si de repente la aplicación en algún lugar dentro de ella cae por una excepción (Excepción), entonces la transacción puede permanecer abierta durante mucho tiempo. Y esto afecta directamente al rendimiento de PostgreSQL. PostgreSQL se ejecutará más lento. Por lo tanto, es importante rastrear a dichos clientes a tiempo y terminar su trabajo por la fuerza. Y necesita optimizar su aplicación para que no haya tales situaciones.
Otros malos clientes son clientes en espera. Pero se vuelven malos debido a las circunstancias. Por ejemplo, una transacción inactiva simple: puede abrir una transacción, tomar bloqueos en algunas líneas, luego caerá en algún lugar del código, dejando una transacción pendiente. Vendrá otro cliente, solicitará los mismos datos, pero encontrará un bloqueo, porque esa transacción pendiente ya tiene bloqueos en algunas filas necesarias. Y la segunda transacción se bloqueará anticipadamente cuando se complete la primera transacción o su administrador la cierre por la fuerza. Por lo tanto, las transacciones pendientes pueden acumularse y desbordar el límite de conexión de la base de datos. Y cuando el límite está lleno, la aplicación ya no puede funcionar con la base de datos. Esto ya es una situación de emergencia para el proyecto. Por lo tanto, los malos clientes deben ser rastreados y respondidos de manera oportuna.
Otro ejemplo de seguimiento. Y aquí hay un tablero de instrumentos decente. Hay información sobre las conexiones desde arriba. Conexión DB - 8 piezas. Y es todo No tenemos información sobre qué clientes están activos, qué clientes están inactivos, sin hacer nada. No hay información sobre transacciones colgadas y conexiones pendientes, es decir, esta es una figura que muestra la cantidad de conexiones y eso es todo. Y luego adivina por ti mismo.
En consecuencia, para agregar esta información al monitoreo, debe consultar la vista del sistema pg_stat_activity. Si pasa mucho tiempo en PostgreSQL, esta es una muy buena vista que debería convertirse en su amigo, porque muestra la actividad actual en PostgreSQL, es decir, lo que está sucediendo en él. Hay una línea separada para cada proceso que muestra información sobre este proceso: desde qué host se realizó la conexión, con qué usuario, con qué nombre, cuándo se inició la transacción, qué solicitud se está ejecutando actualmente, qué solicitud se ejecutó por última vez. Y, en consecuencia, podemos evaluar el estado del cliente por el campo de estadísticas. En términos relativos, podemos agrupar por este campo y obtener las estadísticas que ahora están en la base de datos y la cantidad de conexiones que hay con esta estadística en la base de datos. Y podemos enviar los números ya recibidos a nuestro seguimiento y dibujar gráficos sobre ellos.
También es importante evaluar la duración de la transacción. Ya he dicho que es importante evaluar la duración de los vacíos, pero las transacciones también se evalúan de la misma manera. Hay campos xact_start y query_start. Ellos, en términos relativos, muestran la hora de inicio de la transacción y la hora de inicio de la solicitud. Tomamos la función now(), que muestra la marca de tiempo actual, y restamos las marcas de tiempo de la transacción y la solicitud. Y obtenemos la duración de la transacción, la duración de la solicitud.
Si vemos transacciones largas, deberíamos completarlas ya. Para una carga OLTP, las transacciones largas ya son más de 1-2-3 minutos. Para una carga OLAP, las transacciones largas son normales, pero si se ejecutan durante más de dos horas, esto también es una señal de que tenemos un sesgo en alguna parte.
Una vez que los clientes se han conectado a la base de datos, comienzan a trabajar con nuestros datos. Acceden a tablas, acceden a índices para obtener datos de una tabla. Y es importante evaluar cómo trabajan los clientes con estos datos.
Esto es necesario para evaluar nuestra carga de trabajo y comprender aproximadamente qué tablas tenemos las "más calientes". Por ejemplo, esto es necesario en situaciones en las que queremos colocar tablas "calientes" en algún tipo de almacenamiento SSD rápido. Por ejemplo, algunas tablas de archivo que no hemos utilizado durante mucho tiempo se pueden transferir a algún tipo de archivo "frío", a discos SATA y dejarlas vivir allí, se accederá a ellas según sea necesario.
También es útil para detectar anomalías después de cualquier lanzamiento e implementación. Digamos que el proyecto implementó alguna característica nueva. Por ejemplo, agregamos una nueva funcionalidad para trabajar con la base de datos. Y si construimos gráficos para el uso de tablas, podemos detectar fácilmente estas anomalías en estos gráficos. Por ejemplo, actualizar ráfagas o eliminar ráfagas. Será muy visible.
También es posible detectar anomalías de estadísticas "flotantes". ¿Qué significa? PostgreSQL tiene un planificador de consultas muy fuerte y muy bueno. Y los desarrolladores dedican mucho tiempo a su desarrollo. ¿Cómo trabaja? Para construir buenos planes, PostgreSQL recopila estadísticas sobre la distribución de datos en tablas con un cierto intervalo de tiempo, con cierta periodicidad. Estos son los valores más frecuentes: el número de valores únicos, información sobre NULL en la tabla, mucha información.
En función de estas estadísticas, el planificador crea varias consultas, elige la más óptima y utiliza este plan de consulta para ejecutar la consulta en sí y devolver datos.
Y sucede que la estadística “flota”. Los datos de calidad y cantidad cambiaron de alguna manera en la tabla, pero no se recopilaron las estadísticas. Y los planes formados pueden no ser óptimos. Y si nuestros planes resultan ser subóptimos en términos de monitoreo que se recopila, según las tablas, podremos ver estas anomalías. Por ejemplo, en algún lugar los datos cambiaron cualitativamente y en lugar del índice, comenzó a usarse un paso secuencial a través de la tabla, es decir si la consulta necesita devolver solo 100 filas (hay un límite de 100), se realizará una enumeración completa para esta consulta. Y esto siempre tiene un efecto muy malo en el rendimiento.
Y lo podemos ver en el seguimiento. Y ya mire esta consulta, realice una explicación, recopile estadísticas, cree un nuevo índice adicional. Y ya responde a este problema. Por lo tanto, es importante.
Otro ejemplo de seguimiento. Creo que mucha gente lo reconoce porque es muy popular. Quién utiliza en sus proyectos ? ¿Y quién usa este producto junto con Prometheus? El hecho es que en el repositorio estándar de este monitoreo hay un tablero para trabajar con PostgreSQL: Prometeo. Pero hay un detalle malo aquí.
Hay varios gráficos. Y los bytes se especifican como unidad, es decir, hay 5 gráficos. Estos son Insertar datos, Actualizar datos, Eliminar datos, Obtener datos y Devolver datos. Los bytes se especifican como la dimensión de la unidad. Pero el hecho es que las estadísticas en PostgreSQL devuelven datos en tupla (filas). Y, en consecuencia, estos gráficos son una muy buena manera de subestimar su carga de trabajo varias veces, docenas de veces, porque una tupla no es un byte, una tupla es una cadena, son muchos bytes y siempre es de longitud variable. Es decir, calcular la carga de trabajo en bytes mediante tuplas es una tarea poco realista o muy difícil. Por lo tanto, cuando utiliza un tablero o monitoreo incorporado, siempre es importante comprender que funciona correctamente y le devuelve datos correctamente evaluados.
¿Cómo obtener estadísticas en estas tablas? Para hacer esto, PostgreSQL tiene una familia de vistas. Y la vista principal es . User_tables: esto significa que las tablas se crean en nombre del usuario. Por el contrario, hay vistas del sistema, que son utilizadas por el mismo PostgreSQL. Y hay una tabla de resumen Alltables, que incluye tanto el sistema como el usuario. Puedes empezar por cualquiera de ellos que más te guste.
Los campos anteriores se pueden utilizar para estimar el número de inserciones, actualizaciones y eliminaciones. El panel de ejemplo que utilicé utiliza estos campos para evaluar las características de la carga de trabajo. Por lo tanto, también podemos construir sobre ellos. Pero vale la pena recordar que estas son tuplas, no bytes, por lo que no podemos tomarlo y convertirlo en bytes.
En base a estos datos, podemos construir las llamadas tablas TopN. Por ejemplo, Top-5, Top-10. Y puede realizar un seguimiento de las mesas calientes que se utilizan más que otras. Por ejemplo, 5 tablas "calientes" para la inserción. Y de acuerdo con estas tablas TopN, evaluamos nuestra carga de trabajo y podemos evaluar ráfagas de carga de trabajo después de cualquier lanzamiento, actualización e implementación.
También es importante evaluar el tamaño de la tabla, porque a veces los desarrolladores implementan una nueva función y nuestras tablas comienzan a aumentar de tamaño porque decidieron agregar una cantidad adicional de datos, pero no predijeron cómo sería. afectan el tamaño de la base de datos. Estos casos también nos sorprenden.
Y ahora una pequeña pregunta para ti. ¿Cuál es la pregunta cuando nota la carga en el servidor de la base de datos? ¿Cuál es tu próxima pregunta?
Pero la verdadera pregunta es la siguiente. ¿Qué peticiones provoca la carga? Es decir, no interesa observar los procesos que provoca la carga. Está claro que si el host está con una base de datos, entonces la base de datos se está ejecutando allí y está claro que solo las bases de datos se eliminarán allí. Si abrimos Top, veremos allí una lista de procesos de PostgreSQL que están haciendo algo. Desde Arriba no quedará claro qué están haciendo.
En consecuencia, debe encontrar aquellas consultas que causen la mayor carga, porque el ajuste de consultas, por regla general, genera más beneficios que la configuración de PostgreSQL o el ajuste del sistema operativo, o incluso el ajuste del hardware. Según mi estimación, esto es alrededor del 80-85-90%. Y esto se hace mucho más rápido. Es más rápido corregir la solicitud que corregir la configuración, programar un reinicio, especialmente si la base de datos no se puede reiniciar, o agregar hardware. Es más fácil volver a escribir la consulta en algún lugar o agregar un índice para obtener un mejor resultado de esta consulta.
En consecuencia, es necesario monitorear las solicitudes y su adecuación. Tomemos otro ejemplo de monitoreo. Y aquí, también, parece haber un excelente seguimiento. Hay información sobre replicación, hay información sobre rendimiento, bloqueo, utilización de recursos. Todo está bien, pero no hay información sobre las solicitudes. No está claro qué consultas se ejecutan en nuestra base de datos, cuánto tiempo se ejecutan, cuántas de estas consultas. Necesitamos tener siempre esta información en el monitoreo.
Y para obtener esta información, podemos usar el módulo pg_stat_statements. Sobre esta base, puede construir una variedad de gráficos. Por ejemplo, puede obtener información sobre las solicitudes más frecuentes, es decir, sobre aquellas solicitudes que se realizan con más frecuencia. Sí, después de las implementaciones, también es muy útil mirarlo y comprender si hay algún aumento en las solicitudes.
Puede monitorear las consultas más largas, es decir, aquellas consultas que duran más. Se ejecutan en el procesador, consumen E/S. También podemos evaluar esto por los campos total_time, mean_time, blk_write_time y blk_read_time.
Podemos evaluar y monitorear las solicitudes más pesadas en términos de uso de recursos, las que leen de disco, las que trabajan con memoria o, por el contrario, crean algún tipo de carga de escritura.
Podemos evaluar las solicitudes más generosas. Estas son las consultas que devuelven una gran cantidad de filas. Por ejemplo, puede ser algún tipo de solicitud en la que se olvidaron de establecer un límite. Y simplemente devuelve todo el contenido de la tabla o consulta en las tablas solicitadas.
Y también puede monitorear consultas que usan archivos temporales o tablas temporales.
Y todavía tenemos procesos en segundo plano. Los procesos en segundo plano son principalmente puntos de control o también se denominan puntos de control, estos son autovacuum y replicación.
Otro ejemplo de seguimiento. Hay una pestaña de Mantenimiento a la izquierda, vaya a ella y espere ver algo útil. Pero aquí, sólo el tiempo del vacío y la recopilación de estadísticas, nada más. Esta es una información muy pobre, por lo que siempre debe tener información sobre cómo funcionan los procesos en segundo plano en nuestra base de datos y si hay algún problema con su trabajo.
Cuando observamos los puntos de control, debe recordarse que nuestros puntos de control vacían las páginas "sucias" del área de memoria fragmentada al disco y luego crean un punto de control. Y este punto de control ya se puede usar como un lugar durante la recuperación, si PostgreSQL se canceló repentinamente en una emergencia.
En consecuencia, para vaciar todas las páginas "sucias" en el disco, debe escribir una cierta cantidad. Y, como regla, en sistemas con una gran cantidad de memoria, esto es mucho. Y si hacemos puntos de control muy a menudo en un intervalo corto, el rendimiento del disco se hundirá mucho. Y las solicitudes de los clientes sufrirán por la falta de recursos. Competirán por los recursos y carecerán de productividad.
En consecuencia, a través de pg_stat_bgwriter en los campos especificados, podemos monitorear la cantidad de puntos de control que ocurren. Y si tenemos muchos puntos de control durante un cierto período de tiempo (durante 10-15-20 minutos, durante media hora), por ejemplo, 3-4-5, entonces esto ya puede ser un problema. Y ya necesita buscar en la base de datos, buscar en la configuración, lo que causa tal abundancia de puntos de control. Tal vez se avecina algún gran disco. Ya podemos evaluar la carga de trabajo, porque ya hemos agregado gráficos de carga de trabajo. Ya podemos modificar los parámetros del punto de interrupción y asegurarnos de que no afecten en gran medida el rendimiento de las consultas.
Voy a volver a autovacuum nuevamente porque es el tipo de cosa, como dije, que puede sumar fácilmente tanto el rendimiento del disco como el de las consultas, por lo que siempre es importante medir la cantidad de autovacuum.
El número de trabajadores de autovacío en la base de datos es limitado. De forma predeterminada, hay tres de ellos, por lo que si tenemos tres trabajadores trabajando en la base de datos todo el tiempo, esto significa que nuestro vacío automático está subconfigurado, debemos aumentar los límites, revisar la configuración de vacío automático y subir a la configuración.
Es importante evaluar qué aspiradores trabajan para nosotros. O fue lanzado por el usuario, el DBA entró y lanzó una especie de aspiradora con sus manos, y esto creó una carga. Tenemos un problema. O este es el número de vacíos que desenroscan el contador de transacciones. Para algunas versiones de PostgreSQL, estas son aspiraciones muy pesadas. Y pueden agregar rendimiento fácilmente porque están restando toda la tabla, escaneando todos los bloques en esta tabla.
Y, por supuesto, la duración de los vacíos. Si tenemos aspiradoras largas que funcionan durante mucho tiempo, esto significa que debemos prestar atención nuevamente a la configuración de la aspiradora y tal vez reconsiderar su configuración. Debido a que puede surgir una situación en la que la aspiradora funciona en la mesa durante mucho tiempo (3-4 horas), pero durante el tiempo que la aspiradora estuvo funcionando, una gran cantidad de filas muertas lograron acumularse nuevamente en la mesa. Y tan pronto como termine el vacío, necesita aspirar esta mesa nuevamente. Y llegamos a una situación: un vacío infinito. Y en este caso, el vacío no hace frente a su trabajo, y las tablas comienzan a aumentar gradualmente de tamaño, aunque la cantidad de datos útiles sigue siendo la misma. Por lo tanto, en vacíos largos, siempre miramos la configuración y tratamos de optimizarla, pero al mismo tiempo, para que el rendimiento de las solicitudes de los clientes no se resienta.
Ahora prácticamente no hay instalación de PostgreSQL donde no haya replicación de transmisión. La replicación es el proceso de transferir datos de un maestro a una réplica.
La replicación en PostgreSQL se organiza a través de un registro de transacciones. El maestro genera un registro de transacciones. El registro de transacciones en la conexión de red va a la réplica y luego se reproduce en la réplica. Todo es simple.
En consecuencia, la vista pg_stat_replication se usa para monitorear el retraso de la replicación. Pero no es fácil para ella. En la versión 10, la vista ha sufrido varios cambios. En primer lugar, se ha cambiado el nombre de algunos de los campos. Y algunos de los campos han sido agregados. En la décima versión, aparecieron campos que le permiten evaluar el retraso de la replicación en segundos. Es muy cómodo. Antes de la versión 10, era posible estimar el retraso de replicación en bytes. Esta función se mantuvo en la décima versión, es decir, puede elegir lo que sea más conveniente para usted: evaluar el retraso en bytes o evaluar el retraso en segundos. Muchos hacen ambas cosas.
Sin embargo, para evaluar el retraso de la replicación, debe conocer la posición del registro en la transacción. Y estas posiciones del registro de transacciones están solo en la vista pg_stat_replication. En términos relativos, podemos usar la función pg_xlog_location_diff() para tomar dos puntos en el registro de transacciones. Calcule el delta entre ellos y obtenga el retraso de replicación en bytes. Es muy conveniente y simple.
En la versión 10, esta función cambió de nombre a pg_wal_lsn_diff(). En general, en todas las funciones, vistas, utilidades, donde se encontró la palabra "xlog", se reemplazó con el valor "wal". Esto es tanto en vistas como en funciones. Esta es una gran innovación.
Además, en la décima versión, se agregaron líneas que muestran específicamente el retraso. Estos son retraso de escritura, retraso de descarga, retraso de reproducción. Es decir, es importante monitorear estas cosas. Si vemos que tenemos un retraso en la replicación, debemos investigar por qué apareció, de dónde vino y solucionar el problema.
Con las métricas del sistema, casi todo está en orden. Cuando nace cualquier monitoreo, comienza con las métricas del sistema. Esta es la utilización de procesadores, memoria, intercambio, red y disco. Sin embargo, muchos parámetros no están ahí por defecto.
Si todo está en orden con la eliminación del proceso, entonces hay problemas con la eliminación del disco. Como regla general, los desarrolladores de monitoreo agregan información de ancho de banda. Puede ser en iops o bytes. Pero se olvidan de la latencia y la utilización del dispositivo de disco. Estos son parámetros más importantes que nos permiten evaluar qué tan cargados están nuestros discos y cuánto se ralentizan. Si tenemos una latencia alta, esto significa que hay algunos problemas con los discos. Si tenemos una alta utilización, esto significa que los discos no pueden hacer frente. Estas son características más cualitativas que el ancho de banda.
Sin embargo, estas estadísticas también se pueden obtener del sistema de archivos /proc, como se hace para el reciclaje del procesador. Por qué esta información no se agrega al monitoreo, no lo sé. Pero sigue siendo importante tenerlo en su seguimiento.
Lo mismo es cierto para las interfaces de red. Hay información sobre el ancho de banda de la red en paquetes, en bytes, pero sin embargo no hay información sobre la latencia y no hay información sobre la utilización, aunque esta también es información útil.
Cualquier monitoreo tiene sus inconvenientes. Y no importa qué tipo de seguimiento realice, siempre no cumplirá con ciertos criterios. Sin embargo, se desarrollan, se agregan nuevas características, cosas nuevas, así que elige algo y termínalo.
Y para terminar, siempre debe tener una idea de lo que significan las estadísticas dadas y cómo puede resolver problemas con ellas.
Y algunos puntos clave:
- Siempre necesita monitorear la disponibilidad, tener tableros para que pueda evaluar rápidamente que todo está en orden con la base.
- Siempre debe tener una idea de qué clientes están trabajando con su base de datos para eliminar a los malos y dispararles.
- Es importante evaluar cómo estos clientes trabajan con los datos. Necesitas tener una idea sobre tu carga de trabajo.
- Es importante evaluar cómo se forma esta carga de trabajo, con la ayuda de qué consultas. Puede evaluar consultas, puede optimizarlas, refactorizarlas, crear índices para ellas. Es muy importante.
- Los procesos en segundo plano pueden tener un impacto negativo en las solicitudes de los clientes, por lo que es importante asegurarse de que no utilicen demasiados recursos.
- Las métricas del sistema le permiten hacer planes para escalar, para aumentar la capacidad de sus servidores, por lo que también es importante realizar un seguimiento y evaluarlos.
Si está interesado en este tema, puede seguir estos enlaces.
es la documentación oficial del recopilador de estadísticas. Hay una descripción de todas las vistas estadísticas y una descripción de todos los campos. Puede leerlos, comprenderlos y analizarlos. Y sobre la base de ellos, construya sus propios gráficos, agréguelos a su monitoreo.
Solicitar ejemplos:
Este es nuestro repositorio corporativo y el mío propio. Tienen solicitudes de muestra. No hay consultas de la serie select* from, algo allí. Ya existen solicitudes listas para usar con uniones, que utilizan funciones interesantes que le permiten generar valores legibles y convenientes a partir de números sin procesar, es decir, estos son bytes, tiempo. Puede elegirlos, verlos, analizarlos, agregarlos a sus monitoreos, construir sus propios monitoreos basados en ellos.
preguntas
Pregunta: Dijiste que no publicitarías marcas, pero todavía me pregunto: ¿qué tipo de tableros usas en tus proyectos?
Respuesta: De diferentes maneras. Sucede que llegamos al cliente y ya tiene su propio seguimiento. Y asesoramos al cliente sobre lo que hay que añadir a su seguimiento. La peor situación es con Zabbix. Porque no tiene la capacidad de construir gráficos TopN. Nosotros mismos usamos porque consultamos a estos muchachos sobre el monitoreo. Hicieron el monitoreo de PostgreSQL basado en nuestro TOR. Estoy escribiendo mi propio proyecto favorito, que recopila datos a través de Prometheus y los dibuja en . Mi tarea es hacer mi propio exportador en Prometheus y luego dibujar todo en Grafana.
Pregunta: ¿Hay análogos de informes AWR o ... agregaciones? ¿Eres consciente de algo como esto?
Respuesta: Sí, sé lo que es AWR, es genial. Actualmente, existe una variedad de bicicletas que implementan aproximadamente el siguiente modelo. En algún intervalo de tiempo, algunas líneas base se escriben en el mismo PostgreSQL o en un almacenamiento separado. Puedes googlearlos en Internet, lo son. Uno de los desarrolladores de tal cosa se sienta en el foro sql.ru en el hilo de PostgreSQL. Puedes atraparlo allí. Sí, hay tales cosas, se pueden usar. más en su También escribo algo que te permite hacer lo mismo.
PS1 Si está usando postgres_exporter, ¿qué panel está usando? Hay muchos de ellos. Ya están obsoletos. ¿Puede la comunidad crear una plantilla actualizada?
PS2 Se eliminó pganalyze porque es una oferta de SaaS patentada que se enfoca en el monitoreo del rendimiento y sugerencias de ajuste automático.
Solo los usuarios registrados pueden participar en la encuesta. por favor
¿Qué monitoreo postgresql autohospedado (con tablero) cree que es el mejor?
-
30,0%Zabbix + adiciones de Alexey Lesovsky o zabbix 4.4 o libzbxpgsql + zabbix libzbxpgsql + zabbix3
-
0,0%https://github.com/lesovsky/pgcenter0
-
0,0%https://github.com/pg-monz/pg_monz0
-
20,0%https://github.com/cybertec-postgresql/pgwatch22
-
20,0%https://github.com/postgrespro/mamonsu2
-
0,0%https://www.percona.com/doc/percona-monitoring-and-management/conf-postgres.html0
-
10,0%pganalyze es un SaaS patentado: no se puede eliminar1
-
10,0%https://github.com/powa-team/powa1
-
0,0%https://github.com/darold/pgbadger0
-
0,0%https://github.com/darold/pgcluu0
-
0,0%https://github.com/zalando/PGObserver0
-
10,0%https://github.com/spotify/postgresql-metrics1
10 usuarios votaron. 26 usuarios se abstuvieron.
Fuente: habr.com