A lo largo de mi experiencia como desarrollador ( y también como DevOps pero a nivel más personal ) me he encontrado en situaciones en la cuales un servicio se ve interrumpido durante mucho tiempo por pérdida de acceso con ese servicio. Algunas veces son causas totalmente ajenas a los técnicos y no se puede hacer mucho ( caídas de la infraestructura o errores de hardware ) pero la gran mayoría suelen ser errores de software ( un proceso bloqueado o un error en la configuración ) y pueden llegar a impactar seriamente un servicio.
En mi experiencia MONIT es una herramienta gratuita de Linux que podría mitigar el impacto de esos casos en un sistema productivo. Es altamente configurable y solo esta limitado con la capacidad del SysAdmin o DevOp a cargo de esa infraestructura.
MONIT , una herramienta indispensable para un HAS.
Monit es una herramienta cuya única función es monitorizar el estado del servidor y de los procesos del sistema, comprobar si están bloqueados o sencillamente alertar cuando esos servicios consumen demasiados recursos de forma prolongada. Se configura por scripting y permite alertar, reiniciar el servicio o incluso reiniciar el servidor si es necesario.
Pongamos un caso muy sencillo basado en mi propia experiencia. Los servidores NGINX en el 2011 no estaban tan maduros como lo está ahora, dando lugar en muchos casos a tener que instalar la versión en development (beta) para poder usar ciertas funcionalidades que de otra forma no estarían disponibles y eran necesarias. Estas versiones aunque estables aun así no estaban libres de bugs y estos podían causar la caída del servidor.
Pues con monit es muy fácil monitorizar esto:
check process nginx with pidfile /var/run/nginx.pid
group http
start program = "/usr/sbin/service nginx start" with timeout 60 seconds
stop program = "/usr/sbin/service nginx stop"
if cpu > 70% for 10 cycles then alert
if cpu > 90% for 10 cycles then restart
if failed host arturoemilio.es port 443 protocol https for 5 cycles then restart
if 5 restarts within 5 cycles then unmonitorEste sencillo script se ocupará de mantener el servidor operativo, reiniciando si es necesario o enviando una notificación si consume demasiados recursos durante un periodo muy largo.
¿Y qué ocurriría con la base de datos? Porque todo el mundo sabe que la base de datos es lo que presenta más desafíos a la hora de mantenerla en óptimo funcionamiento. También podemos monitorizar esta , pero en este caso incluso podemos recibir una notificación si no hay actividad (y decididamente debería haberla).
check process mysqld with pidfile /var/run/mysqld/mysqld.pid
start program = "/usr/sbin/service mysql start"
stop program = "/usr/sbin/service mysql stop"
if failed unixsocket /var/run/mysqld/mysqld.sock for 5 cycles then restart
if 5 restarts within 5 cycles then alert
if cpu > 90% for 15 cycles then restart
if totalcpu > 90% for 15 cycles then restart
check file database with path /var/lib/mysql/mydatabase.db
if failed permission 700 then alert
if failed uid sql then alert
if failed gid sqlgroup then alert
if timestamp > 90 minutes then alert
Con este script no solo podemos controlar la carga del servicio y del servidor, si que además detectar cuando la base de datos ha dejado de actualizarse.
Muy bien, es posible mantener el servidor siempre en funcionamiento. ¿Pero es conveniente reiniciar el servicio de forma automática? ¿Qué ocurre con los datos que perdemos si reiniciamos el servicio?
La falacia del costo hundido
Algo que he escuchado muy a menudo sobre esta forma de atajar los problemas en un sistema productivo de negocio es “Pero no podemos reiniciar el servicio porque que pasará con todos los datos que aun están en el limbo”. Lo cual me recuerda a una técnica manipulativa que se usa mucho en videojuegos para mantener a la gente enganchada.
La falacia del coste de los fondos perdidos ( Sunk Cost Falacy para a el que le apetezca informarse) se basa en que no operamos en estas situaciones de forma racional en base a el futuro impacto, experiencia e inversión realizada, si no que tendemos a una decisión emocional basada exclusivamente en la inversión ya hecha (tiempo con el sistema bloqueado) y cuanto más tiempo pasa más difícil es abandonar ese proceso.
Pongamos un caso típico que ocurre mucho en SAP (también en HANA) cuando se procesan muchas cantidades de datos, en los casos que debido a una carga súbita y puntual el sistema se bloquea y no puede operado. Con MONIT el SysAdmin seria notificado casi inmediatamente que el sistema lleva sobrecargado durante los últimos X minutos e incluso detectar el proceso que consume la mayoría de los recursos y poder reiniciarlo.
¿Pero qué pasaría si en realidad el servicio sólo está bloqueado “parcialmente“? (alguna vez he escuchado esto..) . Si la Base de Datos ha dejado de procesar solicitudes (da igual que sea en un esquema o en todos) eso solo va a crear un efecto de bola nieve, las nuevas solicitudes solo van a incrementar el tamaño del tapón y el proceso no se va a desbloquear. Al final pueden ocurrir casos que el proceso ni siquiera responda a una orden de reinicio y sea necesario matarlo.
Si la Base de Datos aun procesa solicitudes pero de forma inusualmente lenta deberíamos recibir una notificación para supervisar la situación, a lo mejor es una carga puntual y el servicio se recupera rápidamente. Pero en ese caso el servicio no está bloqueado parcialmente, solo está sobrecargado.
Así que con una base de datos bloqueada que no procesa solicitudes, ¿Que podemos hacer?
- Podemos esperar a ver si los duendes de los chips nos arreglan el tinglado.
O - Cortamos por lo sano reiniciando tan pronto como se presenta el problema.
Segun la guia de ITIL se debería optar por el segundo caso siempre que sea viable: recuperar el servicio lo antes posible y realizar las investigaciones pertinentes del porque después. Segun mi experiencia también.
Recuperar el servicio lo antes posible es lo más importante ya que sin incluir la urgencia que es para un negocio no poder facturar durante unas horas, estamos arriesgando a una pérdida de datos mayor que si atajamos el problema tan pronto como fueramos informados. No es lo mismo arriesgar la pérdida de 3 minutos de posible facturación a tener que recuperar las transacciones de las últimas 12 horas.
Esta es mi opinión al menos. Si estas de acuerdo conmigo entonces te preguntaras ¿Y porque no se hace de esta forma? En otro momento hablaré de mi experiencia con Si funciona no se toca.