Script de monitorización de servicios para servidores Linux: 4 pasos

2024 Autor: John Day | [email protected]. Última modificación: 2024-01-30 08:44

Tener un sistema estable y siempre en funcionamiento, incluso si usa Linux, puede ser una tarea difícil.

Debido a la complejidad de los paquetes de software modernos y la mala codificación, es inevitable que algunos procesos se bloqueen de vez en cuando. Esto podría ser malo si está ejecutando un servidor y algunas personas confían en estos servicios.

Paso 1: uso de métodos proporcionados por Systemd

Como ya sabrá, la mayoría de los sistemas operativos Linux modernos utilizan systemd.

Si no está familiarizado con systemd, esto es, según wikipedia:

"… un sistema de inicio utilizado en distribuciones de Linux para arrancar el espacio del usuario y administrar todos los procesos posteriormente, en lugar de los sistemas de inicio UNIX System V o Berkeley Software Distribution (BSD). …"

Mucha gente todavía está discutiendo por qué fue necesario reemplazar el antiguo sistema init con este sistema de gestión de procesos más complicado, pero en el siguiente enlace se puede encontrar una buena explicación:

www.tecmint.com/systemd-replaces-init-in-l…

La mejora más importante sería que puede activar el sistema más rápido que init, debido al procesamiento simultáneo y paralelo en el arranque en lugar del enfoque secuencial de init.

Sin entrar en las profundidades de systemd, para agregar un proceso al systemd, debe crear un archivo de servicio. La sintaxis de dicho archivo puede variar desde muy simple hasta completamente complicada, y no entraremos en detalles. Para tener un archivo.service básico, es suficiente usar las siguientes entradas:

[Unidad] Descripción = Descripción de applicationDocumentation = https://wikipedia.org/ Después = local-fs.target network.target [Servicio] Tipo = simpleExecStart = / usr / sbin / applicationExecReload = / usr / sbin / application reloadExecStop = / usr / sbin / application stopRestart = always [Install] WantedBy = multi-user.target

Colóquelos en el archivo application.service en la carpeta / lib / systemd / system.

Lo que hace cada una de estas opciones se explica en el siguiente enlace:

access.redhat.com/documentation/en-US/Red_…

Para iniciar su aplicación, ejecute el siguiente comando:

sudo systemctl start application.service

Nota: la extensión.service se puede omitir.

Para detener la aplicación:

sudo systemctl detener application.service

Si se ha cambiado el archivo de configuración y desea volver a cargar la configuración:

sudo systemctl recargar application.service

Para reiniciar la aplicación:

sudo systemctl reiniciar application.service

Para habilitar el inicio automático en el arranque:

sudo systemctl enable application.service

Si está habilitado, el administrador de procesos systemd intentará iniciar la aplicación según la configuración proporcionada por el archivo del sistema.

Para deshabilitarlo, use el mismo comando que el anterior, pero con el parámetro 'deshabilitar'.

Si coloca Restart = always en el archivo de servicio, systemd supervisará el proceso y, si no se puede encontrar en la lista de procesos, intentará reiniciarlo automáticamente.

Si colocas

RestartSec = 30

después de la directiva de reinicio, esperará 30 segundos antes de intentar reiniciar el proceso. Esto puede ser útil, ya que un intento de reinicio continuo de un servicio / aplicación que falla puede generar una gran demanda en el sistema (escribir registros de errores, etc.)

Como puede ver, systemd ya proporciona algunos medios para monitorear los procesos. Sin embargo, en algunos casos, esto puede no ser suficiente. ¿Qué sucede si un proceso no sale (seguirá estando en la lista de procesos), pero deja de responder? En este caso, para asegurarse de que un proceso está realmente en funcionamiento, es posible que necesite realizar comprobaciones adicionales.

Aquí es donde los guiones de este instructivo serán útiles.

Paso 2: configuración y uso de los scripts de Service Checker

Si necesita más control de sus procesos / servicios en ejecución, estos scripts serán útiles, sin duda.

Como el código es un poco grande, se carga en github y se puede encontrar en el siguiente repositorio:

github.com/trex2000/Service-Monitor-Scripts/blob/master/checkService.sh

El 'corazón' de todo el paquete es el

checkService.sh

Antes de usarlo, debe reemplazar la ruta completa a la carpeta de servicio. Esto se puede encontrar al principio del guión.

El script puede monitorear varios procesos y realizar tareas adicionales, como se describe a continuación:

Revisa cada archivo de la subcarpeta / services que tiene extensiones.serv o.check y verificará si hay un proceso activo llamado 'aplicación'.

Si no hay un archivo '.check' para una aplicación, solo el archivo application.serv:

Si el proceso está activo, lo considerará activo

Si el proceso está inactivo, reiniciará el servicio emitiendo el siguiente comando:

aplicación de reinicio systemctl

si el archivo.serv está vacío!

Si el archivo.serv no está vacío y tiene derechos ejecutables, intentará ejecutarlo como un simple script BASH.

Esto es útil si hay que hacer algo adicional además de reiniciar el servicio.

Por ejemplo, en el archivo spamd.serv, del repositorio anterior, en caso de que el servicio de spam esté inactivo, el servicio spamassassin debe reiniciarse en su lugar, que también reiniciará el spam. Reiniciar solo spam no sería suficiente.

Se puede editar el contenido de dicho archivo serv según las necesidades.

Otro ejemplo es el archivo pcscd.serv. En este caso, también se reiniciaron / mataron varios otros procesos.

Si hay un archivo de verificación, después de verificar si el proceso se está ejecutando, también ejecutará este archivo de secuencia de comandos para realizar verificaciones adicionales.

Por ejemplo, para el servicio oscam, hemos creado un archivo de verificación que intenta conectarse a su interfaz web para ver si tiene éxito. De lo contrario, a pesar de tener el proceso activo, el servicio no responde y debe reiniciarse. El reinicio del servicio debe ser realizado / llamado por el propio archivo.check.

Otro ejemplo sería el servicio Mediatomb DLNA.

Este es un pequeño servidor que proporciona contenido de video / audio a clientes DLNA y se transmite a sí mismo en la red. A veces, el servicio se cuelga y ya no se puede descubrir, pero el proceso seguirá activo. Para verificar si el servicio es detectable, se usó la utilidad CLI llamada gssdp-discover. Todo el código que verifica el servidor DLNA se colocó dentro de un script mediatomb.check.

Estos son solo algunos ejemplos de cómo puede utilizar los archivos.serv y.check.

Para monitorear un nuevo servicio, debe crear un.serv y, si es necesario, también un archivo de verificación y escribir el script correspondiente dentro de ellos.

Si solo se verifica la presencia del proceso si es suficiente, entonces un archivo.serv vacío será suficiente. Si se deben realizar comprobaciones adicionales, se debe crear un archivo.check y se debe escribir un pequeño script para hacer el trabajo.

Por supuesto, el script.sh debe ejecutarse periódicamente, por lo tanto, también debe crearse un trabajo cron para él:

# comprobar los servicios en ejecución cada 5 minutos * / 5 * * * * /var/bin/ServiceCheck/checkService.sh> / dev / null

Paso 3: Pensamientos finales

Espero que este paquete le resulte útil, ya que puede simplificar en gran medida la supervisión de los procesos de Linux y, con suerte, minimizará el tiempo de inactividad de sus servicios.

Siéntase libre de cargar scripts adicionales en github, si crea otros nuevos. Házmelo saber y te agregaré como colaborador.