Permítanme discutir un tema que no es inherentemente específico de PostgreSQL, pero que encuentro regularmente mientras investigo problemas en los sistemas de los clientes, evalúo la "compatibilidad" de esos sistemas, etc. Es la importancia de tener una solución de monitoreo para las métricas del sistema, configurarla razonablemente. , y por qué sar sigue siendo, con diferencia, mi herramienta favorita (al menos en Linux).
Sobre la importancia del seguimiento
En primer lugar, la supervisión de las métricas básicas del sistema (CPU, E/S, memoria) es extremadamente importante. Es un poco extraño tener que señalar esto en conversaciones con otros ingenieros, pero diría que 1 de cada 10 ingenieros piensa que realmente no necesita supervisión. El razonamiento suele ir en la siguiente línea:
Es cierto que el monitoreo agrega gastos generales, no hay duda al respecto. Pero es probable que sea insignificante en comparación con lo que está haciendo la aplicación. En realidad, sar Realmente no está agregando ninguna instrumentación adicional, simplemente está leyendo contadores del nernel, calculando deltas y escribiendo eso en el disco. Puede necesitar algo de espacio en disco y E/S (según la cantidad de CPU y discos), pero eso es todo.
Por ejemplo, recopilar estadísticas por segundo en una máquina con 32 núcleos y varios discos producirá ~5 GB de datos sin procesar por día, pero se comprime extremadamente bien, a menudo entre ~5 y 10 %. Y apenas se ve en top . La resolución por segundo es un poco extrema, y usar 5 o 10 segundos reducirá aún más la sobrecarga.
Así que no, resulta que la sobrecarga en realidad no es una razón válida para no habilitar el monitoreo.
Costos frente a beneficios
Sin embargo, lo que es más importante, "¿cuántos gastos generales elimino al no habilitar el monitoreo?" es la pregunta equivocada para hacer. En su lugar, debería preguntarse “¿Qué beneficios obtengo del monitoreo? ¿Los beneficios superan los costos?”
Ya sabemos que los costos (gastos generales) son bastante pequeños o completamente insignificantes. ¿Cuales son los beneficios? En mi experiencia, tener datos de monitoreo es realmente invaluable.
En primer lugar, le permite investigar problemas:mirar un montón de gráficos y buscar cambios repentinos es sorprendentemente efectivo y, a menudo, lo lleva directamente al problema correcto. Del mismo modo, comparar los datos actuales (recopilados durante el problema) con una línea de base (recopilada cuando todo está bien) es muy útil e imposible si solo habilita el monitoreo cuando las cosas fallan.
En segundo lugar, te permite evaluar tendencias e identificar problemas potenciales antes de que realmente te afecten. ¿Cuánta CPU estás usando? ¿Está creciendo el uso de la CPU con el tiempo? ¿Hay algunos patrones sospechosos en el uso de la memoria? Solo puede responder esas preguntas si tiene el monitoreo implementado.
Por qué sar es mi herramienta favorita
Supongamos que estoy convencido de que el monitoreo es importante y definitivamente debería hacerlo. Pero, ¿por qué sar nuestra herramienta favorita, cuando hay varias alternativas sofisticadas, tanto en las instalaciones como en la nube?
- Está incluido en todas las distribuciones, y es trivial de instalar/configurar. Esto hace que sea bastante simple convencer a las personas para que lo habiliten.
- Está justo en la máquina. Entonces, si conecta SSH a la máquina, también puede obtener los datos de monitoreo.
- Utiliza salida de texto simple. Procese los datos de manera trivial:impórtelos a una base de datos, analícelos, adjúntelos a un ticket de soporte. Eso es bastante difícil con otras herramientas que generalmente no le permiten exportar los datos fácilmente, solo muestran gráficos y/o restringen significativamente el análisis que puede realizar, etc.
Admito que parte de esto se debe al hecho de que trabajo para una empresa que brinda servicios de PostgreSQL a otras empresas (ya sea soporte 24x7 o DBA remoto). y nada más). Eso significa que tener todos los datos importantes en el propio servidor de la base de datos, accesible a través de SSH simple, es extremadamente conveniente y elimina los viajes de ida y vuelta innecesarios solo para solicitar otra pieza de datos de algún otro sistema. Lo que ahorra tiempo y cordura. en ambos lados.
Si tiene que administrar muchos sistemas, probablemente prefiera una solución de monitoreo que recopile datos de muchas máquinas en un solo lugar. Pero para mí, sar sigue ganando.
Entonces, ¿cómo configurarlo?
Mencioné instalar y habilitar sar (o más bien sysstat , que es el paquete que incluye sar ) es muy simple. Desafortunadamente, la configuración predeterminada es algo mala. Después de instalar sysstat , encontrará algo como esto en /etc/cron.d/sysstat (o dondequiera que su distribución almacene cron configuración):
*/10 * * * * root /usr/lib64/sa/sa1 1 1
Esto efectivamente dice el sa1 El comando se ejecutará cada 10 minutos y recopilará una sola muestra durante 1 segundo. Hay dos problemas aquí. En primer lugar, 10 minutos es una resolución bastante baja. En segundo lugar, la muestra solo cubre 1 segundo de 600, por lo que los 9:59 restantes no están realmente incluidos. Esto está algo bien para tendencias a largo plazo, donde el muestreo aleatorio de baja resolución es suficiente. Para otros fines, probablemente necesite hacer algo como esto:
* * * * * root /usr/lib64/sa/sa1 -S XALL 60 1
Que recoge una muestra por minuto, y cada muestra cubre un minuto. El -S XALL significa que se deben recopilar todas las estadísticas, incluidas las interrupciones, los dispositivos de bloques individuales y las particiones, etc. Consulte man sadc para más detalles.
Resumen
Entonces, para resumir esta publicación en algunos puntos simples:
- Debe tener monitoreo, incluso si cree que no lo necesita. Una vez que te encuentras con problemas, es demasiado tarde.
- Los costos de monitoreo probablemente sean insignificantes, pero ciertamente mucho más bajos que los beneficios de tener los datos de monitoreo.
sares conveniente y muy eficiente. Tal vez use algo más en el futuro, pero es un buen primer paso.- La configuración predeterminada no es particularmente buena (baja resolución, muestras de 1 segundo). Considere aumentar la resolución.
Una cosa que no he mencionado es que sar solo se ocupa de las métricas del sistema:CPU, discos, memoria, procesos, no de las estadísticas de PostgreSQL. Definitivamente también deberías monitorear esa parte de la pila, por supuesto.
