{"id":56075,"date":"2020-02-04T00:00:00","date_gmt":"2020-02-03T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/osnovy-monitoringa-postgresql-aleksej-lesovskij"},"modified":"2020-02-18T14:04:16","modified_gmt":"2020-02-18T11:04:16","slug":"osnovy-monitoringa-postgresql-aleksej-lesovskij","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/osnovy-monitoringa-postgresql-aleksej-lesovskij","title":{"rendered":"Fundamentos de monitoreo de PostgreSQL. Alexey Lesovsky","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Te invito a revisar la transcripci\u00f3n de la presentaci\u00f3n de Alexey Lesovski de Data Egret \"Fundamentos de la monitorizaci\u00f3n de PostgreSQL\"<\/strong><\/p>\n

<\/p>\n

En esta presentaci\u00f3n, Alexey Lesovski abordar\u00e1 los aspectos clave de la estad\u00edstica de PostgreSQL, lo que significan y por qu\u00e9 deben estar presentes en la monitorizaci\u00f3n; tambi\u00e9n discutir\u00e1 qu\u00e9 gr\u00e1ficos deben incluirse en la monitorizaci\u00f3n, c\u00f3mo a\u00f1adirlos y c\u00f3mo interpretarlos. La charla ser\u00e1 \u00fatil para administradores de bases de datos, administradores de sistemas y desarrolladores interesados en la resoluci\u00f3n de problemas de PostgreSQL.<\/p>\n

\n

\r\n \"Reproducir\r\n
<\/div>\r\n <\/div><\/center><\/a><\/noindex><\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Me llamo Alexey Lesovsky, represento a la empresa Data Egret. <\/p>\n

<\/p>\n

Unas palabras sobre m\u00ed. Comenc\u00e9 hace mucho tiempo como administrador de sistemas. <\/p>\n

<\/p>\n

Administr\u00e9 diversas distribuciones de Linux, ocup\u00e1ndome de cosas como virtualizaci\u00f3n, monitoreo, trabajando con proxies, etc. Pero en alg\u00fan momento me dediqu\u00e9 m\u00e1s a las bases de datos, PostgreSQL. Me encantaba. Y poco a poco, pas\u00e9 la mayor parte de mi tiempo laboral trabajando con PostgreSQL. As\u00ed, gradualmente me convert\u00ed en DBA de PostgreSQL.<\/p>\n

<\/p>\n

A lo largo de mi carrera, siempre me han interesado los temas de estad\u00edstica, monitoreo y obtenci\u00f3n de telemetr\u00eda. Cuando era administrador de sistemas, trabaj\u00e9 mucho con Zabbix. Y escrib\u00ed un peque\u00f1o conjunto de scripts como zabbix-extensions<\/a><\/noindex>. Fue bastante popular en su momento. Y se pod\u00eda monitorear cosas muy diversas, no solo Linux, sino tambi\u00e9n diferentes componentes.<\/p>\n

<\/p>\n

Ahora trabajo con PostgreSQL. Estoy escribiendo otra herramienta que permite trabajar con la estad\u00edstica de PostgreSQL. Se llama pgCenter<\/a><\/noindex> (art\u00edculo en Habr \u2014 Estad\u00edstica de Postgres sin nervios ni complicaciones<\/a><\/noindex>). <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Una breve introducci\u00f3n. \u00bfCu\u00e1les son las situaciones que enfrentan nuestros clientes? Ocurre alg\u00fan tipo de accidente relacionado con la base de datos. Y cuando ya se ha recuperado la base de datos, el jefe del departamento o el jefe de desarrollo dice: \u00abAmigos, necesitamos monitorear la base de datos, porque algo malo ha sucedido y debemos asegurarnos de que esto no vuelva a ocurrir en el futuro\u00bb. Y aqu\u00ed comienza un interesante proceso de elecci\u00f3n de un sistema de monitoreo o la adaptaci\u00f3n de un sistema de monitoreo existente para poder monitorear nuestra base de datos: PostgreSQL, MySQL o alguna otra. Y los colegas comienzan a proponer: \u00abHe o\u00eddo que hay una cierta base de datos. Vamos a utilizarla\u00bb. Los colegas comienzan a discutir entre ellos. Y al final resulta que elegimos alguna base de datos, pero el monitoreo de PostgreSQL en ella est\u00e1 bastante limitado y siempre hay que modificar algo. Tomar ciertos repositorios de GitHub, clonarlos, adaptar scripts, ajustarlos de alguna manera. Y al final, esto resulta en un trabajo manual. <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Por lo tanto, en esta presentaci\u00f3n intentar\u00e9 brindarles algunos conocimientos sobre c\u00f3mo elegir un monitoreo no solo para PostgreSQL, sino tambi\u00e9n para bases de datos en general. Y proporcionar los conocimientos que les permitan mejorar su monitoreo, para obtener alg\u00fan beneficio, para poder monitorear su base de datos de manera efectiva, y prevenir a tiempo posibles situaciones de emergencia que puedan surgir. <\/p>\n

<\/p>\n

Las ideas presentadas en esta exposici\u00f3n pueden adaptarse directamente a cualquier base de datos, ya sea un SGBD o noSQL. Por lo tanto, no se limita solo a PostgreSQL, sino que habr\u00e1 muchas recetas sobre c\u00f3mo implementarlo en PostgreSQL. Habr\u00e1 ejemplos de consultas, ejemplos de entidades que existen en PostgreSQL para monitoreo. Y si su SGBD tiene caracter\u00edsticas similares que permiten integrarlas en el monitoreo, tambi\u00e9n puede adaptarlas, a\u00f1adirlas y ser\u00e1 excelente.<\/p>\n

<\/p>\n

\"FundamentosEn la presentaci\u00f3n no hablar\u00e9
\nsobre c\u00f3mo recopilar y almacenar m\u00e9tricas. No dir\u00e9 nada sobre el post-procesamiento de datos ni su presentaci\u00f3n al usuario. Y no hablar\u00e9 sobre alertas.
\nA lo largo de la narrativa, ir\u00e9 mostrando diferentes capturas de pantalla de los monitoreos existentes, y las criticar\u00e9 de alguna manera. Sin embargo, tratar\u00e9 de no mencionar marcas para no hacer publicidad ni antireclamo a estos productos. Por lo tanto, todas las coincidencias son aleatorias y quedan a su imaginaci\u00f3n.
\n\"Fundamentos
\nPara empezar, aclaremos qu\u00e9 es el monitoreo. El monitoreo es algo muy importante que se debe tener. Todos lo entienden. Pero al mismo tiempo, el monitoreo no se considera un producto comercial y no influye directamente en las ganancias de la empresa, por lo que siempre se le presta atenci\u00f3n de manera residual. Si tenemos tiempo, trabajamos en el monitoreo; si no hay tiempo, bien, lo dejamos en el backlog y volveremos a estas tareas alg\u00fan d\u00eda. <\/p>\n

<\/p>\n

Por lo tanto, de nuestra experiencia al llegar a los clientes, el monitoreo a menudo est\u00e1 subdesarrollado y carece de elementos interesantes que nos ayuden a mejorar nuestro trabajo con la base de datos. Por eso, el monitoreo siempre necesita ser perfeccionado. <\/p>\n

<\/p>\n

Las bases de datos son cosas complejas que tambi\u00e9n necesitan ser monitoreadas, porque las bases de datos son almacenes de informaci\u00f3n. Y la informaci\u00f3n 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\u00e1n compuestas por una gran cantidad de componentes. Y muchos de estos componentes necesitan ser monitoreados. <\/p>\n

<\/p>\n

\"FundamentosSi hablamos espec\u00edficamente de PostgreSQL, se puede representar como un esquema que consta de muchos componentes. Estos componentes interact\u00faan entre s\u00ed. Al mismo tiempo, en PostgreSQL existe lo que se llama el subsistema Stats Collector, que permite recopilar estad\u00edsticas sobre el funcionamiento de estos subsistemas y proporcionar una interfaz al administrador o usuario para que pueda ver estas estad\u00edsticas. <\/p>\n

<\/p>\n

Estas estad\u00edsticas se presentan en forma de un conjunto de funciones y vistas (views). Tambi\u00e9n se pueden llamar tablas. Es decir, con un cliente psql com\u00fan, puede conectarse a la base de datos, hacer un select a estas funciones y vistas, y obtener cifras concretas sobre el funcionamiento de los subsistemas de PostgreSQL. <\/p>\n

<\/p>\n

Puede agregar estas cifras a su sistema de monitoreo favorito, dibujar gr\u00e1ficos, agregar funciones y obtener an\u00e1lisis a largo plazo. <\/p>\n

<\/p>\n

Sin embargo, en este informe no abordar\u00e9 todas estas funciones de manera exhaustiva, ya que eso podr\u00eda llevar todo un d\u00eda. Me centrar\u00e9 en literal dos o tres cosas y explicar\u00e9 c\u00f3mo ayudan a mejorar la monitorizaci\u00f3n.
\n\"Fundamentos
\nY si hablamos sobre la monitorizaci\u00f3n de la base de datos, \u00bfqu\u00e9 es lo que hay que monitorear? En primer lugar, hay que monitorear la disponibilidad, ya que una base de datos es un servicio que proporciona acceso a datos a los clientes, y necesitamos vigilar su disponibilidad, as\u00ed como algunas caracter\u00edsticas cualitativas y cuantitativas. <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Tambi\u00e9n es necesario monitorear a los clientes que se conectan a nuestra base de datos, porque pueden ser tanto clientes normales como clientes da\u00f1inos que pueden perjudicar la base de datos. Tambi\u00e9n hay que vigilarlos y rastrear su actividad.<\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Cuando los clientes se conectan a la base de datos, es evidente que comienzan a trabajar con nuestros datos, por lo que necesitamos monitorear tambi\u00e9n c\u00f3mo interact\u00faan los clientes con los datos: con qu\u00e9 tablas, y en menor medida, con qu\u00e9 \u00edndices. Es decir, tenemos que evaluar la carga de trabajo (workload) que generan nuestros clientes.<\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Pero la carga de trabajo tambi\u00e9n consiste, por supuesto, en consultas. Las aplicaciones se conectan a la base y acceden a los datos mediante consultas, por lo que es importante evaluar qu\u00e9 consultas tenemos en nuestra base de datos, monitorizar su adecuaci\u00f3n, asegurarnos de que no est\u00e9n mal escritas, y que algunas opciones necesiten ser reescritas para que funcionen m\u00e1s r\u00e1pido y con mejor rendimiento. <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Y dado que estamos hablando de bases de datos, hay que considerar que siempre hay procesos en segundo plano. Los procesos en segundo plano permiten mantener el rendimiento de la base de datos en un buen nivel, y por lo tanto requieren una cierta cantidad de recursos para su funcionamiento. Al mismo tiempo, pueden cruzarse con los recursos de las consultas de los clientes, por lo que el trabajo intensivo de los procesos en segundo plano puede afectar directamente el rendimiento de las consultas de los clientes. Por eso tambi\u00e9n hay que monitorearlos y asegurarse de que no haya desequilibrios relacionados con los procesos en segundo plano. <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Y todo esto en t\u00e9rminos de monitoreo de bases de datos permanece en la m\u00e9trica del sistema. Pero considerando que la mayor parte de nuestra infraestructura se est\u00e1 trasladando a la nube, las m\u00e9tricas del sistema de un host individual siempre quedan en segundo plano. Sin embargo, en bases de datos siguen siendo relevantes y, por supuesto, tambi\u00e9n es necesario monitorear estas m\u00e9tricas del sistema. <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Con las m\u00e9tricas del sistema m\u00e1s o menos todo est\u00e1 bien, todos los sistemas modernos de monitoreo ya admiten estas m\u00e9tricas, pero en general hay algunos componentes que a\u00fan faltan y se necesita a\u00f1adir ciertas cosas. Tambi\u00e9n voy a mencionarlos, habr\u00e1 unas diapositivas al respecto. <\/p>\n

<\/p>\n

\"Fundamentos
\nEl primer punto del plan es la disponibilidad. \u00bfQu\u00e9 es la disponibilidad? La disponibilidad, en mi entendimiento, es la capacidad de la base de datos para manejar conexiones, es decir, la base de datos est\u00e1 activa, acepta conexiones de los clientes como un servicio. Y esta disponibilidad se puede evaluar con ciertas caracter\u00edsticas. Estas caracter\u00edsticas son muy convenientes para mostrar en los dashboards. <\/p>\n

<\/p>\n

\"Fundamentos
\nTodos saben qu\u00e9 es un dashboard. Es cuando echas un vistazo a la pantalla donde se resume la informaci\u00f3n necesaria. Y ya puedes determinar de inmediato si hay un problema en la base de datos o no.
\nPor lo tanto, la disponibilidad de la base de datos y otras caracter\u00edsticas clave siempre deben mostrarse en los dashboards, para que esta informaci\u00f3n est\u00e9 a mano, siempre cerca de ti. Algunos detalles adicionales que ya ayudan en la investigaci\u00f3n de incidentes o situaciones de emergencia deben mostrarse en dashboards secundarios o esconderse en enlaces de drilldown que llevan a sistemas de monitoreo externos. <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Ejemplo de un sistema de monitoreo conocido. Es un sistema de monitoreo muy impresionante. Recopila una gran cantidad de datos, pero desde mi punto de vista, tiene una concepci\u00f3n extra\u00f1a de los dashboards. Hay un enlace \u2018crear dashboard\u2019. Pero cuando creas un dashboard, est\u00e1s creando una lista compuesta por dos columnas, una lista de gr\u00e1ficos. Y cuando necesitas ver algo, comienzas a hacer clic con el rat\u00f3n, desplazarte, buscar el gr\u00e1fico que necesitas. Y esto lleva tiempo, es decir, no hay dashboards como tales. Solo hay listas de gr\u00e1ficos.<\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

\u00bfQu\u00e9 se debe agregar a estos paneles? Se puede comenzar con una caracter\u00edstica como el tiempo de respuesta. En PostgreSQL hay una vista pg_stat_statements. Por defecto, est\u00e1 desactivada, pero es una de las vistas del sistema m\u00e1s importantes que siempre se deben habilitar y utilizar. Esta almacena informaci\u00f3n sobre todas las consultas que se han ejecutado en la base de datos. <\/p>\n

<\/p>\n

Por lo tanto, podemos partir de la idea de que se puede tomar el tiempo total de ejecuci\u00f3n de todas las consultas y dividirlo por el n\u00famero de consultas usando los campos mencionados anteriormente. Pero esto es solo una temperatura promedio. Tambi\u00e9n podemos considerar otros campos: el tiempo m\u00ednimo de ejecuci\u00f3n de las consultas, el m\u00e1ximo y el mediano. E incluso podemos construir percentiles, ya que PostgreSQL cuenta con funciones para ello. Y podemos obtener algunas cifras que caracterizan el tiempo de respuesta de nuestra base de datos en relaci\u00f3n con las consultas ya ejecutadas, es decir, no ejecutamos una consulta falsa 'select 1' y analizamos el tiempo de respuesta, sino que analizamos los tiempos de respuesta de consultas que ya se han realizado, ya sea representando un solo n\u00famero o construyendo un gr\u00e1fico a partir de ellos. <\/p>\n

<\/p>\n

Tambi\u00e9n es importante monitorear la cantidad de errores que el sistema est\u00e1 generando en este momento. Para esto, se puede utilizar la vista pg_stat_database. Nos enfocamos en el campo xact_rollback. Este campo muestra no solo la cantidad de rollbacks que ocurren en la base, sino que tambi\u00e9n considera la cantidad de errores. En otras palabras, podemos mostrar este n\u00famero en nuestro panel y observar cu\u00e1ntos errores hay en este momento. Si hay muchos errores, es un buen motivo para revisar los registros y ver qu\u00e9 tipos de errores son y por qu\u00e9 est\u00e1n ocurriendo, y luego investigar y resolverlos.<\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Se puede a\u00f1adir algo como un Tac\u00f3metro. Esto es la cantidad de transacciones por segundo y la cantidad de consultas por segundo. En otras palabras, puedes utilizar estos n\u00fameros como el rendimiento actual de tu base de datos y observar si hay picos en las consultas, picos en las transacciones o, por el contrario, si la base no est\u00e1 completamente cargada porque alg\u00fan backend se ha ca\u00eddo. Es importante siempre observar este n\u00famero y recordar que para nuestro proyecto, ese rendimiento es normal, mientras que los valores por encima o por debajo son problem\u00e1ticos y extra\u00f1os, lo que significa que hay que investigar por qu\u00e9 hay esos n\u00fameros.<\/p>\n

<\/p>\n

Para evaluar la cantidad de transacciones, podemos volver a consultar la vista pg_stat_database. Podemos sumar el n\u00famero de commits y el n\u00famero de rollbacks para obtener la cantidad de transacciones por segundo. <\/p>\n

<\/p>\n

\u00bfTodos entienden que en una transacci\u00f3n pueden incluirse varias consultas? Por eso, TPS y QPS son un poco diferentes. <\/p>\n

<\/p>\n

La cantidad de consultas por segundo se puede obtener a trav\u00e9s de pg_stat_statements y simplemente calcular la suma de todas las consultas ejecutadas. Es claro que comparamos el valor actual con el anterior, restamos y obtenemos la delta, obteniendo as\u00ed la cantidad.<\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Se pueden agregar m\u00e9tricas adicionales si se desea, que tambi\u00e9n ayudan a evaluar la disponibilidad de nuestra base y a rastrear si ha habido alg\u00fan tiempo de inactividad. <\/p>\n

<\/p>\n

Una de estas m\u00e9tricas es el uptime. Pero el uptime en PostgreSQL es un tema un poco complicado. A continuaci\u00f3n, explicar\u00e9 por qu\u00e9. Cuando PostgreSQL arranca, comienza a contabilizar el uptime. Sin embargo, si en alg\u00fan momento, por ejemplo, durante la noche, se ejecuta alguna tarea, y el OOM-killer finaliza forzosamente un proceso hijo de PostgreSQL, el sistema finaliza las conexiones de todos los clientes, restablece el \u00e1rea de memoria compartida y comienza la recuperaci\u00f3n desde el \u00faltimo punto de control. Durante este tiempo de recuperaci\u00f3n, la base no acepta conexiones, es decir, esta situaci\u00f3n se puede considerar como downtime. Sin embargo, el contador de uptime no se reiniciar\u00e1, porque cuenta el tiempo desde el inicio del postmaster desde el primer momento. Por lo tanto, se pueden pasar por alto tales situaciones.<\/p>\n

<\/p>\n

Tambi\u00e9n se debe monitorear la cantidad de trabajadores de autovacuum. \u00bfTodos saben qu\u00e9 es el autovacuum en PostgreSQL? Es un subsistema interesante en PostgreSQL. Se han escrito muchos art\u00edculos sobre \u00e9l y se han realizado muchas presentaciones. Hay muchas discusiones sobre el vacuum y c\u00f3mo deber\u00eda funcionar. Muchos lo consideran un mal inevitable. Y as\u00ed es. Es una especie de recolector de basura que limpia las versiones obsoletas de filas que no son necesarias por ninguna de las transacciones y libera espacio en las tablas e \u00edndices para nuevas filas. <\/p>\n

<\/p>\n

\u00bfPor qu\u00e9 es necesario monitorearlo? Porque el autovacuum a veces puede causar mucho da\u00f1o. Consume una gran cantidad de recursos, lo que afecta las consultas de los clientes. <\/p>\n

<\/p>\n

Y se debe monitorear a trav\u00e9s de la vista pg_stat_activity, de la que hablar\u00e9 en la siguiente secci\u00f3n. Esta vista muestra la actividad actual en la base de datos. A trav\u00e9s de esta actividad, podemos rastrear la cantidad de procesos de limpieza (vacuum) que est\u00e1n funcionando en este momento. Podemos supervisar los procesos de limpieza y ver que si se supera el l\u00edmite, es una raz\u00f3n para revisar la configuraci\u00f3n de PostgreSQL y optimizar el funcionamiento del proceso de limpieza. <\/p>\n

<\/p>\n

Otra caracter\u00edstica de PostgreSQL es que PostgreSQL sufre mucho con transacciones que se prolongan. Especialmente, con transacciones que permanecen activas y no hacen nada. Estos son los llamados stat idle-in-transaction. Esta transacci\u00f3n mantiene bloqueos, impide el funcionamiento del proceso de limpieza. Y como resultado, las tablas se inflan y aumentan su tama\u00f1o. Y las consultas que trabajan con estas tablas comienzan a funcionar m\u00e1s lentamente, porque hay que mover todas las versiones antiguas de las filas de la memoria al disco y de regreso.<\/strong> Por lo tanto, el tiempo, la duraci\u00f3n de las transacciones m\u00e1s largas y las consultas m\u00e1s prolongadas del proceso de limpieza tambi\u00e9n deben ser monitoreados. Y si vemos algunos procesos que est\u00e1n funcionando durante mucho tiempo, 10-20-30 minutos para una carga OLTP, entonces ya debemos prestar atenci\u00f3n a ellos y finalizarlos forzosamente, o optimizar la aplicaci\u00f3n para que no se llamen y no se queden colgados tanto tiempo.<\/strong> Para una carga anal\u00edtica, 10-20-30 minutos es normal, a veces pueden ser a\u00fan m\u00e1s largas. <\/p>\n

<\/p>\n

\"Fundamentos
\nA continuaci\u00f3n, tenemos la opci\u00f3n con los clientes conectados. Cuando hemos formado el panel de control y hemos publicado las m\u00e9tricas clave de disponibilidad, tambi\u00e9n podemos agregar informaci\u00f3n adicional sobre los clientes conectados. <\/p>\n

<\/p>\n

La informaci\u00f3n sobre los clientes conectados es importante porque, desde el punto de vista de PostgreSQL, los clientes pueden ser diferentes. Hay buenos clientes y hay malos clientes. <\/p>\n

<\/p>\n

Un ejemplo sencillo. Por cliente entiendo una aplicaci\u00f3n. La aplicaci\u00f3n se conecta a la base de datos y comienza a enviar sus consultas; la base de datos las procesa y ejecuta, devolviendo los resultados al cliente. Estos son los clientes buenos y correctos. <\/p>\n

<\/p>\n

Hay situaciones en las que un cliente se conecta, mantiene la conexi\u00f3n, pero no hace nada. Se encuentra en estado idle. <\/p>\n

<\/p>\n

Pero hay clientes problem\u00e1ticos. Por ejemplo, un cliente se conecta, abre una transacci\u00f3n, hace algo en la base de datos y luego se va al c\u00f3digo, supongamos, para acceder a una fuente externa o para procesar los datos obtenidos. Pero no cierra la transacci\u00f3n. Y la transacci\u00f3n queda abierta en la base de datos, manteniendo un bloqueo en una fila. Este es un estado negativo. Y si, por alguna raz\u00f3n, la aplicaci\u00f3n falla por una excepci\u00f3n (Exception), la transacci\u00f3n puede quedarse abierta durante mucho tiempo. Esto afecta directamente el rendimiento de PostgreSQL. PostgreSQL funcionar\u00e1 m\u00e1s lento. Por eso es importante monitorear a estos clientes y finalizar su trabajo de manera forzada. Adem\u00e1s, es necesario optimizar la aplicaci\u00f3n para evitar tales situaciones. <\/p>\n

<\/p>\n

Otros clientes problem\u00e1ticos son los clientes en espera. Pero se convierten en problem\u00e1ticos debido a las circunstancias. Por ejemplo, una transacci\u00f3n simple en espera: puede abrir una transacci\u00f3n, obtener bloqueos en ciertas filas, luego en alg\u00fan lugar del c\u00f3digo falla, y queda una transacci\u00f3n colgada. Llegar\u00e1 otro cliente, solicitar\u00e1 los mismos datos, pero se encontrar\u00e1 con un bloqueo porque la transacci\u00f3n colgada ya tiene bloqueos en algunas filas necesarias. Y la segunda transacci\u00f3n quedar\u00e1 en espera de que la primera transacci\u00f3n finalice o sea cerrada forzosamente por su administrador. De este modo, las transacciones en espera pueden acumularse y sobrepasar el l\u00edmite de conexiones a la base de datos. Y cuando se alcanza el l\u00edmite, la aplicaci\u00f3n ya no puede trabajar con la base. Esto es una situaci\u00f3n cr\u00edtica para el proyecto. Por lo tanto, es necesario monitorear a los clientes problem\u00e1ticos y reaccionar a tiempo. <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Otro ejemplo de monitoreo. Y aqu\u00ed hay un buen panel de control. Hay informaci\u00f3n sobre las conexiones en la parte superior. Conexiones a la base de datos - 8. Y eso es todo. No tenemos informaci\u00f3n sobre qu\u00e9 clientes est\u00e1n activos, cu\u00e1les simplemente est\u00e1n inactivos, sin hacer nada. No hay informaci\u00f3n sobre transacciones colgadas ni sobre conexiones en espera, es decir, es una cifra que muestra el n\u00famero de conexiones y nada m\u00e1s. Y despu\u00e9s, adivinen ustedes.
\n\"Fundamentos
\nPor lo tanto, para a\u00f1adir esta informaci\u00f3n a la monitorizaci\u00f3n, es necesario consultar la vista del sistema pg_stat_activity. Si pasas mucho tiempo en PostgreSQL, esta es una vista excelente que deber\u00eda convertirse en tu aliada, ya que muestra la actividad actual en PostgreSQL, es decir, lo que est\u00e1 sucediendo en \u00e9l. Cada proceso tiene una l\u00ednea separada que muestra informaci\u00f3n sobre ese proceso: desde qu\u00e9 host se realiz\u00f3 la conexi\u00f3n, bajo qu\u00e9 usuario, bajo qu\u00e9 nombre, cu\u00e1ndo se inici\u00f3 la transacci\u00f3n, qu\u00e9 consulta se est\u00e1 ejecutando actualmente y cu\u00e1l fue la \u00faltima consulta ejecutada. Y, por consiguiente, podemos evaluar el estado del cliente a trav\u00e9s del campo stat. En cierto modo, podemos hacer un agrupamiento por este campo y obtener las estad\u00edsticas actuales en la base de datos y el n\u00famero de conexiones que tienen ese stat en la base de datos. Los n\u00fameros obtenidos los podemos enviar a nuestra monitorizaci\u00f3n y graficar a partir de ellos.
\nTambi\u00e9n es importante evaluar la duraci\u00f3n de la transacci\u00f3n. Ya he mencionado que es fundamental evaluar la duraci\u00f3n de los vac\u00edos, pero las transacciones se eval\u00faan de la misma manera. Hay campos xact_start y query_start. Estos, en cierto modo, muestran el tiempo de inicio de la transacci\u00f3n y el tiempo de inicio de la consulta. Tomamos la funci\u00f3n now(), que muestra la marca de tiempo actual y restamos el timestamp de la transacci\u00f3n y de la consulta. Y obtenemos la duraci\u00f3n de la transacci\u00f3n, la duraci\u00f3n de la consulta. <\/p>\n

<\/p>\n

Si vemos transacciones largas, debemos finalizarlas. Para una carga OLTP, las transacciones largas son superiores a 1-2-3 minutos.<\/strong>. Para una carga OLAP, las transacciones largas son normales, pero si se ejecutan durante m\u00e1s de dos horas, tambi\u00e9n es un indicio de que hay un desequilibrio en alg\u00fan lugar.<\/strong> <\/p>\n

<\/p>\n

\"Fundamentos
\nCuando los clientes se conectan a la base de datos, comienzan a trabajar con nuestros datos. Acceden a las tablas, consultan los \u00edndices para obtener datos de la tabla. Y es importante evaluar c\u00f3mo los clientes interact\u00faan con estos datos.<\/p>\n

<\/p>\n

Esto es necesario para evaluar nuestra carga de trabajo y comprender aproximadamente cu\u00e1les son nuestras tablas m\u00e1s \"calientes\". Por ejemplo, esto es \u00fatil en situaciones en las que queremos colocar tablas \"calientes\" en un almacenamiento SSD r\u00e1pido. Por otro lado, algunas tablas de archivo que ya no utilizamos desde hace tiempo se pueden mover a un archivo \"fr\u00edo\" en discos SATA y pueden permanecer all\u00ed, accediendo a ellas solo cuando sea necesario. <\/p>\n

<\/p>\n

Tambi\u00e9n es \u00fatil para detectar anomal\u00edas despu\u00e9s de lanzamientos y despliegues. Supongamos que el proyecto ha lanzado alguna nueva caracter\u00edstica. Por ejemplo, se ha a\u00f1adido nueva funcionalidad para trabajar con la base de datos. Y si construimos gr\u00e1ficos del uso de las tablas, podremos detectar f\u00e1cilmente estas anomal\u00edas en esos gr\u00e1ficos. Por ejemplo, picos en las actualizaciones o picos en las eliminaciones. Eso ser\u00e1 muy evidente.<\/p>\n

<\/p>\n

Tambi\u00e9n se pueden detectar anomal\u00edas en las estad\u00edsticas \"desviadas\". \u00bfQu\u00e9 significa esto? PostgreSQL tiene un planificador de consultas muy fuerte y eficiente. Los desarrolladores dedican mucho tiempo a su desarrollo. \u00bfC\u00f3mo funciona? Para construir buenos planes, PostgreSQL recopila estad\u00edsticas sobre la distribuci\u00f3n de datos en las tablas a intervalos y periodicidades espec\u00edficas. Estas son las estad\u00edsticas m\u00e1s frecuentes: la cantidad de valores \u00fanicos, informaci\u00f3n sobre NULL en la tabla, y mucha informaci\u00f3n m\u00e1s. <\/p>\n

<\/p>\n

Bas\u00e1ndose en estas estad\u00edsticas, el planificador construye varias consultas, selecciona la m\u00e1s \u00f3ptima y utiliza este plan para ejecutar la consulta y devolver los datos. <\/p>\n

<\/p>\n

A veces, las estad\u00edsticas \"fluyen\". La calidad y cantidad de los datos han cambiado en las tablas, pero la estad\u00edstica no se ha actualizado. Los planes formados pueden resultar no \u00f3ptimos. Y si nuestros planes resultan no \u00f3ptimos seg\u00fan la monitorizaci\u00f3n recopilada, podremos ver estas anomal\u00edas. Por ejemplo, donde los datos han cambiado cualitativamente y, en lugar del \u00edndice, se ha utilizado un escaneo secuencial de la tabla; es decir, si la consulta necesita devolver solo 100 filas (con un l\u00edmite de 100), se realizar\u00e1 un escaneo completo. Y esto siempre afecta negativamente al rendimiento. <\/p>\n

<\/p>\n

Y podremos ver esto en la monitorizaci\u00f3n. Ya podremos observar esta consulta, realizar un explain para ella, recopilar estad\u00edsticas, construir un nuevo \u00edndice adicional. Y as\u00ed responder a este problema. Por lo tanto, esto es importante. <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Otro ejemplo de monitorizaci\u00f3n. Creo que muchos lo reconocen, porque es muy popular. Quien lo utiliza en sus proyectos Prometheus<\/a><\/noindex>? \u0410 \u043a\u0442\u043e \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442 \u044d\u0442\u043e\u0442 \u043f\u0440\u043e\u0434\u0443\u043a\u0442 \u0441\u043e\u0432\u043c\u0435\u0441\u0442\u043d\u043e \u0441 Prometheus? \u0414\u0435\u043b\u043e \u0432 \u0442\u043e\u043c, \u0447\u0442\u043e \u0432 \u0441\u0442\u0430\u043d\u0434\u0430\u0440\u0442\u043d\u043e\u043c \u0440\u0435\u043f\u043e\u0437\u0438\u0442\u043e\u0440\u0438\u0438 \u044d\u0442\u043e\u0433\u043e \u043c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433\u0430 \u0435\u0441\u0442\u044c \u0434\u0430\u0448\u0431\u043e\u0440\u0434 \u0434\u043b\u044f \u0440\u0430\u0431\u043e\u0442\u044b \u0441 PostgreSQL \u2013 postgres_exporter<\/a><\/noindex> Prometheus. Pero hay un inconveniente. <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Hay varios gr\u00e1ficos. Y en forma de unidad se indican bytes, es decir, hay 5 gr\u00e1ficos. Estos son Insert data, Update data, Delete data, Fetch data y Return data. Como unidad de medida se indican bytes. Pero el hecho es que las estad\u00edsticas en PostgreSQL devuelven los datos en tuplas (filas). Y, en consecuencia, estos gr\u00e1ficos son una muy buena manera de subestimar su carga de trabajo varias veces, incluso decenas de veces, porque una tupla no es un byte, una tupla es una fila, que son muchos bytes y siempre de longitud variable. Es decir, calcular la carga de trabajo en bytes usando tuplas es una tarea irreal o muy complicada. Por lo tanto, cuando usas un panel de control o monitorizaci\u00f3n incorporada, siempre es importante entender que funcione correctamente y te devuelva datos evaluados de manera precisa. <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

\u00bfC\u00f3mo obtener estad\u00edsticas de estas tablas? Para esto, en PostgreSQL hay un cierto conjunto de vistas. Y la vista principal es pg_stat_user_tables<\/a><\/noindex>. User_tables significa que son tablas creadas por el usuario. En contraste, hay vistas del sistema que son utilizadas por PostgreSQL mismo. Y hay una tabla consolidada Alltables, que incluye tanto las sistem\u00e1ticas como las de usuario. Puedes basarte en cualquiera de ellas, la que m\u00e1s te guste.<\/p>\n

<\/p>\n

Por los campos mencionados arriba se puede estimar la cantidad de insert, update y delete. El ejemplo de panel de control que utilic\u00e9 utiliza precisamente estos campos para evaluar las caracter\u00edsticas de la carga de trabajo. Por lo tanto, tambi\u00e9n podemos basarnos en ellos. Pero hay que recordar que son tuplas, no bytes, as\u00ed que no podemos simplemente tomar y convertirlo en bytes.<\/p>\n

<\/p>\n

Bas\u00e1ndonos en estos datos, podemos construir lo que se denomina tablas TopN. Por ejemplo, Top-5, Top-10. Y se pueden rastrear las tablas calientes que se utilizan m\u00e1s que las dem\u00e1s. Por ejemplo, las 5 tablas \"calientes\" por inserciones. Y con estos TopN, evaluamos nuestra carga de trabajo y podemos valorar los picos de carga de trabajo despu\u00e9s de diversas liberaciones, actualizaciones y despliegues. <\/p>\n

<\/p>\n

Tambi\u00e9n es importante evaluar el tama\u00f1o de la tabla, porque a veces los desarrolladores lanzan una nueva funci\u00f3n y nuestras tablas empiezan a crecer en tama\u00f1o, ya que deciden a\u00f1adir un volumen adicional de datos, pero no pronostican c\u00f3mo esto afectar\u00e1 al tama\u00f1o de la base de datos. Estos casos tambi\u00e9n pueden ser sorpresas para nosotros. <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Y ahora una peque\u00f1a pregunta para ustedes. \u00bfQu\u00e9 pregunta surge cuando notan una carga en el servidor con la base de datos? \u00bfCu\u00e1l es la siguiente pregunta que se les ocurre? <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Pero en realidad, surge la siguiente pregunta. \u00bfCu\u00e1les son las consultas que est\u00e1n causando la carga? Es decir, no es interesante observar los procesos que generan la carga. Est\u00e1 claro que si hay un host con base de datos, entonces se est\u00e1 ejecutando una base de datos ah\u00ed y es evidente que solo las bases de datos son las que la utilizan. Si abrimos Top, ver\u00edamos una lista de procesos en PostgreSQL que est\u00e1n haciendo algo. Desde Top no queda claro qu\u00e9 es lo que est\u00e1n haciendo. <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Por lo tanto, es necesario identificar aquellas consultas que generan la mayor carga, porque generalmente, la optimizaci\u00f3n de consultas proporciona m\u00e1s beneficios que la optimizaci\u00f3n de la configuraci\u00f3n de PostgreSQL o del sistema operativo, o incluso la optimizaci\u00f3n del hardware. Seg\u00fan mi estimaci\u00f3n, esto representa aproximadamente un 80-85-90 %. Y se realiza mucho m\u00e1s r\u00e1pido. Es m\u00e1s f\u00e1cil corregir una consulta que ajustar la configuraci\u00f3n, planificar un reinicio, especialmente si no se puede reiniciar la base de datos o a\u00f1adir hardware. Es m\u00e1s sencillo reescribir una consulta o a\u00f1adir un \u00edndice para obtener un mejor resultado de esta consulta. <\/p>\n

<\/p>\n

\"Fundamentos
\nPor lo tanto, es necesario monitorear las consultas y su adecuaci\u00f3n. Tomemos otro ejemplo de monitoreo. Y aqu\u00ed tambi\u00e9n parece un excelente monitoreo. Hay informaci\u00f3n sobre replicaci\u00f3n, hay informaci\u00f3n sobre capacidad, bloqueos, y utilizaci\u00f3n de recursos. Todo es perfecto, pero no hay informaci\u00f3n sobre las consultas. No est\u00e1 claro qu\u00e9 consultas se est\u00e1n ejecutando en nuestra base de datos, cu\u00e1nto tiempo tardan en ejecutarse y cu\u00e1ntas de estas consultas hay. Siempre necesitamos tener esta informaci\u00f3n en el monitoreo. <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Y para obtener esta informaci\u00f3n, podemos usar el m\u00f3dulo pg_stat_statements. A partir de \u00e9l, se pueden construir diversos gr\u00e1ficos. Por ejemplo, podemos obtener informaci\u00f3n sobre las consultas m\u00e1s frecuentes, es decir, aquellas que se ejecutan con mayor frecuencia. S\u00ed, tambi\u00e9n es muy \u00fatil revisar esto despu\u00e9s de los despliegues y entender si hay alg\u00fan pico en las consultas. <\/p>\n

<\/p>\n

Podemos monitorear las consultas m\u00e1s largas, es decir, aquellas que tardan m\u00e1s en ejecutarse. Estas consumen CPU y tambi\u00e9n utilizan entrada\/salida. Tambi\u00e9n podemos evaluar esto a trav\u00e9s de los campos total_time, mean_time, blk_write_time y blk_read_time. <\/p>\n

<\/p>\n

Podemos evaluar y monitorear las consultas m\u00e1s pesadas en t\u00e9rminos de uso de recursos, aquellas que leen desde el disco, que trabajan con memoria o, por el contrario, que generan alguna carga de escritura.<\/p>\n

<\/p>\n

Podemos evaluar las consultas m\u00e1s generosas. Estas son las consultas que devuelven un gran n\u00famero de filas. Por ejemplo, podr\u00eda ser una consulta donde se olvid\u00f3 establecer un l\u00edmite y retorna todo el contenido de la tabla o consulta de las tablas solicitadas.<\/p>\n

<\/p>\n

Y tambi\u00e9n se pueden monitorear las consultas que utilizan archivos temporales o tablas temporales. <\/p>\n

<\/p>\n

\"Fundamentos
\nY nos quedan los procesos en segundo plano. Los procesos en segundo plano son, en primer lugar, los checkpoints, tambi\u00e9n llamados puntos de control, el autovacuum y la replicaci\u00f3n. <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Otro ejemplo de monitoreo. Hay una pesta\u00f1a a la izquierda llamada Mantenimiento, la abrimos con la esperanza de ver algo \u00fatil. Pero aqu\u00ed solo hay tiempo de ejecuci\u00f3n del vacuum y la recolecci\u00f3n de estad\u00edsticas, nada m\u00e1s. Esta es una informaci\u00f3n muy escasa, por lo que siempre es necesario tener informaci\u00f3n sobre c\u00f3mo est\u00e1n funcionando los procesos en segundo plano en nuestra base de datos y si hay problemas por su funcionamiento. <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Cuando consideramos los puntos de control, debemos recordar que los puntos de control descargan las p\u00e1ginas 'sucias' del \u00e1rea de memoria compartida al disco y luego crean un punto de control. Este punto de control puede ser utilizado posteriormente como un lugar durante la recuperaci\u00f3n, en caso de que PostgreSQL se cierre de manera an\u00f3mala. <\/p>\n

<\/p>\n

Por lo tanto, para volcar todas las p\u00e1ginas \u00absucias\u00bb en el disco, es necesario ejecutar un cierto volumen de escritura. Y, por lo general, en sistemas con una gran cantidad de memoria, esto conlleva un volumen muy elevado. Si los puntos de control se realizan con mucha frecuencia en un corto intervalo de tiempo, el rendimiento del disco disminuir\u00e1 significativamente. Las consultas de los clientes sufrir\u00e1n por la falta de recursos. Luchar\u00e1n por los recursos y no tendr\u00e1n suficiente rendimiento. <\/p>\n

<\/p>\n

Por lo tanto, a trav\u00e9s de pg_stat_bgwriter, podemos monitorear el n\u00famero de puntos de control que ocurren por los campos especificados. Si en un intervalo de tiempo determinado (10-15-20 minutos, media hora) se producen muchos puntos de control, por ejemplo, 3-4-5, esto ya puede ser un problema. Y es necesario revisar la base de datos, examinar la configuraci\u00f3n para ver qu\u00e9 est\u00e1 causando tal abundancia de puntos de control. Puede ser que se est\u00e9 realizando una gran escritura. Con la carga de trabajo, ya podemos evaluar, ya que tenemos los gr\u00e1ficos de carga de trabajo a\u00f1adidos. Podemos ajustar los par\u00e1metros de los puntos de control y hacer que no influyan demasiado en el rendimiento de las consultas.<\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Vuelvo a mencionar el autovacuum, porque es algo que, como ya he mencionado, puede afectar f\u00e1cilmente tanto al rendimiento de los discos como al de las consultas, por lo que siempre es importante evaluar la cantidad de autovacuum. <\/p>\n

<\/p>\n

El n\u00famero de trabajadores de autovacuum en la base de datos est\u00e1 limitado. Por defecto, hay tres, as\u00ed que si siempre hay tres trabajadores funcionando en la base, eso significa que nuestro autovacuum est\u00e1 mal configurado; es necesario aumentar los l\u00edmites y revisar las configuraciones de autovacuum y entrar en la configuraci\u00f3n.
\nEs importante evaluar qu\u00e9 trabajadores de vacuum est\u00e1n activos. Puede ser que haya un vacuum iniciado por un usuario, donde un DBA lo haya ejecutado manualmente, lo que ha creado una carga. Puede haberse presentado alg\u00fan problema. O puede ser por la cantidad de vacuums que est\u00e1n contabilizando las transacciones. Para algunas versiones de PostgreSQL, estos son vacuums muy pesados. Y pueden afectar considerablemente al rendimiento, ya que leen toda la tabla en su totalidad, escaneando todos los bloques de esa tabla. <\/p>\n

<\/p>\n

Y, por supuesto, la duraci\u00f3n de los vac\u00edos. Si tenemos vac\u00edos largos que funcionan durante mucho tiempo, significa que debemos volver a prestar atenci\u00f3n a la configuraci\u00f3n del vac\u00edo y, posiblemente, revisar sus ajustes. Porque puede surgir una situaci\u00f3n en la que el vac\u00edo est\u00e9 trabajando en una tabla durante mucho tiempo (3-4 horas), pero durante ese tiempo se ha acumulado un gran volumen de filas muertas en la tabla. Y tan pronto como el vac\u00edo se complete, necesitar\u00e1 volver a vaciar esa tabla. Y llegamos a una situaci\u00f3n de vac\u00edo interminable. En ese caso, el vac\u00edo no cumple su funci\u00f3n, y las tablas comienzan a aumentar de tama\u00f1o, aunque el volumen de datos \u00fatiles permanezca constante. Por lo tanto, en el caso de vac\u00edos prolongados, siempre revisamos la configuraci\u00f3n y tratamos de optimizarla, pero sin afectar el rendimiento de las consultas de los clientes. <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Hoy en d\u00eda, pr\u00e1cticamente no hay instalaciones de PostgreSQL que no tengan replicaci\u00f3n en streaming. La replicaci\u00f3n es el proceso de transferencia de datos del maestro a la r\u00e9plica.<\/p>\n

<\/p>\n

La replicaci\u00f3n en PostgreSQL se basa en el registro de transacciones. El maestro genera el registro de transacciones. El registro de transacciones se env\u00eda a trav\u00e9s de una conexi\u00f3n de red a la r\u00e9plica, donde se reproduce. Todo es bastante simple. <\/p>\n

<\/p>\n

Por lo tanto, para monitorear el retraso en la replicaci\u00f3n se utiliza la vista pg_stat_replication. Pero no es tan simple. En la versi\u00f3n 10, la vista sufri\u00f3 varios cambios. En primer lugar, algunos campos fueron renombrados. Y se a\u00f1adieron algunos campos. En la versi\u00f3n 10 aparecieron campos que permiten evaluar el retraso de la replicaci\u00f3n en segundos. Esto es muy conveniente. Antes de la versi\u00f3n 10, era posible evaluar el retraso de la replicaci\u00f3n en bytes. Esa opci\u00f3n se mantuvo tambi\u00e9n en la versi\u00f3n 10, es decir, puedes elegir lo que te convenga m\u00e1s: evaluar el retraso en bytes o en segundos. Muchos hacen ambas cosas.<\/p>\n

<\/p>\n

Sin embargo, para evaluar el retraso en la replicaci\u00f3n, es necesario conocer la posici\u00f3n del registro en la transacci\u00f3n. Y esas posiciones del registro de transacciones est\u00e1n en la vista pg_stat_replication. En t\u00e9rminos simples, con la funci\u00f3n pg_xlog_location_diff() podemos tomar dos puntos en el registro de transacciones, calcular la diferencia entre ellos y obtener el retraso de la replicaci\u00f3n en bytes. Esto es muy conveniente y simple. <\/p>\n

<\/p>\n

En la versi\u00f3n 10, esta funci\u00f3n fue renombrada a pg_wal_lsn_diff(). En general, en todas las funciones, vistas y utilidades donde aparec\u00eda la palabra \u00abxlog\u00bb, se ha reemplazado por \u00abwal\u00bb. Esto aplica tanto a las vistas como a las funciones. Esta es una novedad. <\/p>\n

<\/p>\n

Adem\u00e1s, en la versi\u00f3n 10 se a\u00f1adieron l\u00edneas que muestran espec\u00edficamente el retraso. Esto incluye write lag, flush lag y replay lag. Es decir, estas m\u00e9tricas son importantes para monitorear. Si vemos que hay un retraso en la replicaci\u00f3n, es necesario investigar por qu\u00e9 ocurri\u00f3, de d\u00f3nde proviene y solucionar el problema. <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Con las m\u00e9tricas del sistema, pr\u00e1cticamente todo est\u00e1 en orden. Cuando se implementa cualquier tipo de monitoreo, comienza con las m\u00e9tricas del sistema. Esto incluye la utilizaci\u00f3n de CPU, memoria, swap, red y disco. Sin embargo, muchos par\u00e1metros por defecto no est\u00e1n disponibles. <\/p>\n

<\/p>\n

Si la utilizaci\u00f3n del proceso est\u00e1 en orden, hay problemas con la utilizaci\u00f3n del disco. Por regla general, los desarrolladores de monitoreo a\u00f1aden informaci\u00f3n sobre el ancho de banda. Esto puede expresarse en IOPS o bytes. Pero se olvidan de la latencia y la utilizaci\u00f3n de los dispositivos de disco. Estos son par\u00e1metros m\u00e1s importantes que permiten evaluar cu\u00e1n ocupados est\u00e1n los discos y cu\u00e1n lentos son. Si tenemos una alta latencia, significa que hay problemas con los discos. Si la utilizaci\u00f3n es alta, significa que los discos no est\u00e1n rindiendo adecuadamente.<\/strong> Estas son caracter\u00edsticas de mayor calidad que el ancho de banda.<\/p>\n

<\/p>\n

A pesar de que esta estad\u00edstica tambi\u00e9n se puede obtener del sistema de archivos \/proc, como se hace para la utilizaci\u00f3n de CPU. No s\u00e9 por qu\u00e9 esta informaci\u00f3n no se a\u00f1ade a los monitoreos. Sin embargo, es importante tenerla en tu monitoreo.<\/strong> <\/p>\n

<\/p>\n

Lo mismo ocurre con las interfaces de red. Hay informaci\u00f3n sobre el ancho de banda de la red en paquetes, en bytes, pero no hay informaci\u00f3n sobre la latencia ni sobre la utilizaci\u00f3n, aunque esto tambi\u00e9n es informaci\u00f3n \u00fatil.<\/strong> <\/p>\n

<\/p>\n

\"Fundamentos<\/p>\n

<\/p>\n

Todos los monitoreos tienen desventajas. Cualquier monitoreo que elijas siempre no cumplir\u00e1 con algunos criterios. Sin embargo, est\u00e1n evolucionando, se a\u00f1aden caracter\u00edsticas nuevas, as\u00ed que elige algo y aj\u00fastalo. <\/p>\n

<\/p>\n

Y para ajustar, siempre es necesario tener claro qu\u00e9 significa la estad\u00edstica entregada y c\u00f3mo puede ayudar a resolver problemas. <\/p>\n

<\/p>\n

Y varios puntos clave:<\/p>\n

<\/p>\n