Cómo escribí mi monitoreo

Decidí compartir mi historia. Tal vez a alguien le sirva esta solución económica para un problema conocido.

Cuando era joven y lleno de energía y no sabía qué hacer con ella, decidí hacer algo de freelance. Rápidamente logré ganar reputación y encontré un par de clientes permanentes que me pidieron que manteniera sus servidores de forma continua.

Lo primero que pensé fue en la necesidad de monitoreo. Decidí hacer como las personas inteligentes, no reinventar la rueda y buscar opciones listas, como Munin o Zabbix. Pero descubrí de inmediato que la versión web requiere una buena conexión a internet, especialmente si la abres por primera vez desde el teléfono. Si estás descansando en la naturaleza lejos de la ciudad, obtener una conexión estable puede ser difícil. Así que se eligió la opción de monitoreo por consola.

Para el monitoreo por consola, atop y el programa para leer los logs de atop — atopsar — me fueron de gran ayuda. Ya se habían mencionado en habr, atop fue incluso desglosado,, pero casi no se habló de atopsar.

Instalación

La instalación es muy simple, solo tres comandos.

#Centos

yum install atop

#Debian/Ubuntu

apt-get install atop

Luego, puedes configurar el funcionamiento del monitoreo a tu manera o utilizar la configuración predeterminada.

#Debian/Ubuntu/Centos

/etc/default/atop 

Archivo estándar:

 #cat /etc/default/atop
INTERVAL=60                    #Время, через которое создаётся снимок нагрузки в секундах, по умолчанию каждые 10 минут
LOGPATH="/var/log/atop"        #Путь до папки хранения логов
OUTFILE="$LOGPATH/daily.log"   #Название файла логов за сегодняшний день

Añadimos al inicio automático
#Debian/Ubuntu/Centos

systemctl enable atop 

Iniciamos atop como un demonio
#Debian/Ubuntu/Centos

systemctl start atop  

Para los perezosos, reuní todo en un solo comando
#Centos

yum install atop && systemctl enable atop && systemctl start atop

#Debian/Ubuntu

apt-get install atop && systemctl enable atop && systemctl start atop

Atopsar

Junto con atop, se instala atopsar, un conveniente analizador de logs binarios que lleva a cabo el demonio atop. Por supuesto, se pueden leer los logs también con atop, pero no es tan cómodo si necesitas capturar un intervalo de tiempo amplio.

Una pequeña introducción sobre cómo funciona atopsar.

Al iniciar atopsar sin claves, se abre el log del día de hoy y se muestra la carga en cada núcleo por separado y la línea idl para todos los núcleos.

Las claves que utilizo:

-A = mostrar toda la información del log
-c = mostrar información sobre la carga de los núcleos del procesador, clave por defecto
-m = carga en la memoria RAM y swap
-d = actividad del disco
-O = top 3 procesos con carga en CPU
-G = top 3 procesos con carga en RAM
-D = top 3 procesos con carga en disco
-N = top 3 procesos con carga en red
-r = especificar la ruta al log que quieres leer, si necesitas ver la carga de días pasados
-b = tiempo desde el cual comenzar a mostrar la salida
-e = tiempo en el que se debe finalizar la salida
-M = crea una columna adicional al final que señala la criticidad de la línea (+ carga, * — carga crítica)

Gracias al monitoreo, podremos entender la razón del comportamiento incorrecto del servidor en cualquier momento.

Notificaciones

Entonces, el monitoreo de carga está presente, pero aún así no nos permite identificar y resolver problemas rápidamente. Necesitamos notificaciones cuando surja un problema.

Soy el único que monitorea los servidores, así que las notificaciones deben llegar a donde siempre pueda verlas y reaccionar de alguna manera.

Al principio estaban los SMS: rápidos, fiables, gratuitos. Pero luego los operadores móviles bloquearon el envío gratuito de SMS a través de sus gateways.
El correo electrónico — lento, puede haber problemas con la entrega.
Los mensajeros — hay que instalar en el teléfono, es necesario crear bots.

Como resultado de la búsqueda se eligió el mensajero Telegram por su simplicidad y la conveniencia de la aplicación en el teléfono y en el escritorio.

Creé mi propio bot con la ayuda de botfather.
Después, coloqué en el servidor varios scripts que rastrean la carga del servidor (IDL, smartct, etc.), la presencia de errores de tipo "oom killer", errores al crear copias de seguridad y otras operaciones que necesitan ser controladas.

Los scripts son bastante sencillos, escritos en bash, por ejemplo, la verificación de LA y notificación sobre el exceso de Load Average en relación con la cantidad de núcleos en servidor.

if [ ${LA[0]} -gt 2000 ] || [ ${LA[1]} -gt 3000 ] || [ ${LA[2]} -gt 4000 ]
    then
        wget -O /dev/null "https://api.telegram.org/$bot_id:$bot_key/sendMessage?chat_id=$chat_id&text=En el servidor $ip LA $LAd"
        wget -O /dev/null "https://api.telegram.org/$bot_id:$bot_key/sendMessage?chat_id=$chat_id&text=`top -b -n 1 | grep Cpu`"
        wget -O /dev/null "https://api.telegram.org/$bot_id:$bot_key/sendMessage?chat_id=$chat_id&text=Top 5 procesos `top -b -n 1 | grep -A 5 'PID USER' | tail -5`"
    fi

La simplicidad de la sintaxis ofrece muchas posibilidades de uso (y cualquier persona que tenga un poco de conocimiento de programación puede escribirlo o modificarlo).

El único detalle es que si el servidor está en Rusia (y no tienes IPv6 en el servidor), debes usar un proxy. Para ello, al principio del script debes escribir la línea de conexión al proxy:

export https_proxy=http://login:contraseña@IP.dirección:puerto

Esto no es el final

Mientras caminas tranquilamente por las montañas con una mochila a la espalda, disfrutando de un descanso de la civilización, de repente tu teléfono, al captar señal por casualidad, te envía una notificación sobre un problema en tu servidor. ¿Qué hacer? Tu estado de paz se desvanece como por arte de magia. ¿Llamar a tu esposa y dictarle comandos? ¡Ja, ja!

Necesitaba urgentemente idear una forma de resolver los problemas que surgían rápidamente y sin buena conexión a internet. Aquí es donde de nuevo me salvó el messenger (#telegramvivir). Enseñé a mi bot a comunicarse solo conmigo, ignorando a los demás. Ahora, junto con la notificación sobre el problema, recibo un poco más de información que me ayuda a entender cuál es la fuente del problema y puedo intentar solucionarlo de forma remota. Es suficiente con enviar un mensaje al bot, levantar un poco más el teléfono para que el mensaje se envíe, y ¡listo! — el bot se pone a hacer tu trabajo. De esta manera, puedo, por ejemplo, eliminar algún proceso no deseado, reiniciar un demonio, bloquear una IP, entre otras cosas.

He trasladado aquí las solicitudes futuras de clientes que serán necesarias, por ejemplo, el restablecimiento urgente de contraseñas para usuarios (porque “¡Aaaa, no podemos acceder al servidor, estamos perdiendo millones!”), búsqueda de un usuario que tenga acceso a la carpeta necesaria, encender y apagar el sitio, y otras solicitudes. Por supuesto, estoy constantemente mejorando la funcionalidad del bot, ya que la imaginación de los clientes a veces plantea solicitudes inesperadas y que no había previsto. Pero las principales están satisfechas.

También hay una versión para VK, pero no ha tenido mucho éxito.

Ahora viajo tranquilamente y exploro este mundo, sin miedo a que algo se rompa y no pueda enterarme o arreglarlo.

Fuente: habr.com