Hace dos años ya hice un post Conmutación por error simple para un sitio web sobre okerr. Ahora hay algo de desarrollo en el proyecto y también publiqué. código fuente del lado del servidor okerr bajo licencia abierta, por eso decidí escribir esta breve reseña sobre Habr.

[ tamaño completo ]

A quien le pueda interesar

Esto puede ser de su interés si trabaja en un equipo pequeño o solo. No tienes seguimiento y no estás seguro de si realmente lo necesitas. O probaste algún tipo de monitoreo serio y popular "para los grandes", pero de alguna manera "no despegó" para ti, o funciona en una configuración casi predeterminada y no cambió mucho tu vida. Y también, si definitivamente no planea asignar a un empleado completo (o incluso un departamento) para monitorear el panel de monitoreo al menos un par de horas al día o configurarlo.

¿Por qué okerr es inusual?

A continuación mostraré características interesantes de la okerra que la distinguen de otros sistemas de monitoreo.

Okerr es un monitoreo híbrido

Durante el monitoreo interno, se ejecuta un "agente" en las máquinas monitoreadas, que transmite datos al servidor de monitoreo (por ejemplo, espacio libre en el disco). Cuando es externo, el servidor realiza comprobaciones a través de la red (por ejemplo, ping o disponibilidad del sitio web). Cada enfoque tiene sus limitaciones. Okerr utiliza ambas opciones. Las comprobaciones dentro de los servidores las realiza un agente muy ligero (30 Kb) o sus propios scripts y aplicaciones, y las comprobaciones de la red se realizan a través de sensores okerr en diferentes países.

okerr no es sólo un software, sino también un servicio

La parte del servidor de cualquier monitoreo es grande y compleja, es difícil de instalar y configurar y requiere recursos. Con okerr puedes instalar tu propio servidor de monitoreo (es gratuito y de código abierto), o simplemente puedes usar solo la parte del cliente y utilizar el servicio de nuestro servidor. También gratis.

Si el monitoreo permite compensar y encubrir la falta de confiabilidad en servidores y aplicaciones, entonces surge una pregunta filosófica: ¿quién está en guardia? ¿Cómo nos informará el monitoreo sobre un problema si él mismo "murió" por alguna razón, por separado o junto con sus otros recursos (por ejemplo, se cayó el canal al centro de datos)? Cuando utilice el servicio externo okerr (este problema está resuelto), recibirá una alerta incluso si todo el centro de datos con sus servidores se queda sin energía o es atacado por zombies.

Por supuesto, existe el riesgo de que el servidor okerr no esté disponible, esto es cierto (como saben, el 90% de la confiabilidad siempre se obtiene de manera simple y "gratuita", el 99% con un mínimo de esfuerzo, y cada nueve posterior es exponencialmente más difícil). Pero, en primer lugar, las posibilidades de que esto suceda son menores y, en segundo lugar, el problema puede pasar desapercibido sólo si coincide con problemas en nuestros servidores. Si tenemos una confiabilidad del 99.9% y usted tiene un 99.9% (cifras no demasiado altas), entonces la probabilidad de una falla no detectada es del 0.1% de 0.1% = 0.0001%. Sumar tres nueves a tu confiabilidad casi sin esfuerzo y sin costo ¡es muy bueno!

Otra ventaja del monitoreo como servicio es que un proveedor de hosting o un estudio web puede instalar un servidor okerr y brindar acceso a los clientes como un servicio adicional gratuito o pago. Sus competidores solo tienen hosting y sitios web, pero usted tiene hosting confiable con monitoreo.

Okerr se trata de indicadores

El indicador es una "bombilla". Tiene dos estados principales: verde (OK) o rojo (ERR). El proyecto contiene muchos indicadores agrupados (por ejemplo, por servidor). En la página principal del proyecto, verá inmediatamente que todo está en verde (y puede cerrarlo) o algo está iluminado en rojo y debe corregirse. Al realizar la transición entre estos estados, se envía una alerta. Una vez al día mientras lo estás configurando se envía un resumen del proyecto.

Cada indicador okerr tiene condiciones integradas mediante las cuales cambia de estado (en Zabbix esto se llama disparador). Por ejemplo, el promedio de carga no debe ser superior a 2 (por supuesto, esto es configurable). Y para cada control interno (carga media, disco libre,...) hay un organismo de control. Si por algún motivo no recibimos una confirmación exitosa a la hora acordada, se registra un error y se envía una alerta.

Nuestro patrón de trabajo habitual es revisar los correos electrónicos por la mañana, y mirar el resumen entre otras cartas (lo programamos al inicio del trabajo). Si todo está bien, hacemos otras cosas importantes (pero para estar seguros, podemos mirar rápidamente el panel de okerra y asegurarnos de que todo esté verde en este momento). Si llega una alerta, reaccionamos.

Por supuesto, es posible simplemente mantener indicadores "informativos" (para ver la imagen de la red desde el monitoreo), pero se hace todo lo posible para crear de manera simple, fácil y rápida indicadores específicos para el monitoreo automático y el envío de alertas.

El propósito para el cual estás configurando okerr es en alertas, para que puedas crear un indicador en un minuto, podría "dormir" durante un año, simplemente aceptar actualizaciones, y cuando un año después algo se estropea, se enciende y envía una alerta. El minuto que dedicó a crear un indicador valió la pena: se enteró del problema inmediatamente, antes que nadie. Es posible que lo hayan arreglado antes de que alguien se diera cuenta. ¡Aquello que se levanta rápidamente no se considera que haya caído!

seguridad

Sería una pena configurar el monitoreo para aumentar la confiabilidad, pero como resultado, será atacado a través de la red a través de él y habrá muchas vulnerabilidades de red en diferentes herramientas de monitoreo (Zabbix, Nagios).

Agente (okerrmod del paquete okerrupdate) que se ejecuta en el sistema no es un servidor de red, sino un cliente. Por lo tanto, no hay puertos abiertos adicionales en el servidor monitoreado, el cliente funciona fácilmente detrás de un firewall o NAT y es muy difícil (yo diría "imposible") piratear la red, ya que en principio no escucha la red. enchufe.

Cobertura de seguimiento completa

Ahora nuestra regla es que aprendemos sobre todos los problemas técnicos de okerr. Si de repente se viola la regla (okerr no advirtió sobre su inminente ocurrencia (si esto es posible) o que ya ocurrió), agregamos cheques a okerr.

Controles externos

Un conjunto bastante típico:

• de ping
• http-estado
• comprobar la validez y frescura del certificado SSL (advertirá si está a punto de caducar)
• abra el puerto TCP y el banner en él
• http grep (la página [no debe] contener texto específico)
• hash sha1 para detectar cambios en la página.
• DNS (el registro DNS debe tener un valor específico)
• WHOIS (advertirá si el dominio está a punto de estropearse)
• DNSBL antispam (comprobación del host con más de 50 listas negras antispam a la vez)

Controles internos

Además, un conjunto bastante estándar (pero fácilmente ampliable).

• df (espacio libre en disco)
• promedio de carga
• opentcp (abre sockets de escucha TCP; notificará si algo comenzó o falló)
• tiempo de actividad: solo tiempo de actividad en el servidor. Notificará si ha cambiado (es decir, el servidor se ha sobrecargado)
• cliente_ip
• dirsize: lo usamos para rastrear cuándo los rootfs de nuestra máquina virtual exceden el tamaño permitido, sin introducir restricciones estrictas, y el tamaño de los directorios de inicio de los usuarios.
• vacío y no vacío: supervisa los archivos que deberían estar vacíos (o no vacíos). Por ejemplo, el registro de errores del servidor okerr debería estar vacío y, si contiene al menos una línea, recibiré una notificación y la comprobaré. Pero mail.log en el servidor de correo NO debe estar vacío (N minutos después de la rotación). Y a veces estaba vacío para nosotros después de una actualización del sistema, cuando logrotate no podía reiniciar rsyslog correctamente.
• linecount: número de líneas en el archivo (como wc -l). Lo usamos como un reemplazo más suave de vacío, cuando el registro de errores aún puede crecer, pero solo lentamente (por ejemplo, el robot de Google llega a algunas páginas cerradas). Hay un límite de 2 líneas en 20 minutos. Si es mayor, habrá una alerta.

Interesantes controles internos.

Si has estado leyendo “en diagonal” hasta este punto, ahora será más interesante leer con más atención.

copias de seguridad

Supervisa las copias de seguridad en el directorio. Nuestros archivos de copia de seguridad tienen nombres como “ServerName-20200530.tar.gz”. Para cada servidor en okerr, se crea el indicador ServerName-DATE.tar.gz (la fecha real cambia a la línea "DATE"). También se controla la presencia misma de una copia de seguridad nueva y su tamaño (por ejemplo, no puede ser inferior al 90% de la copia de seguridad anterior).

¿Qué se debe hacer para que se comience a rastrear una nueva copia de seguridad después de haber comenzado a crearla y colocarla en este directorio? ¡Nada! Este es un enfoque muy conveniente cuando no necesita hacer “nada” porque:

• No hacer “nada” es bastante rápido, ahorra tiempo
• Es difícil olvidarse de no hacer “nada”
• Es difícil no hacer “nada” mal, con un error. Nada es el método más confiable.

Si de repente dejan de aparecer archivos de copia de seguridad nuevos, habrá una alerta. Si, por ejemplo, ha desactivado uno de los servidores y no debería haber más copias de seguridad, deberá eliminar el indicador (a través de la interfaz web o desde el shell a través de la API).

maxfilesz

Realiza un seguimiento del tamaño de los archivos más grandes (normalmente: /var/log/*). Esto le permite detectar problemas impredecibles, por ejemplo, contraseñas de fuerza bruta o envío de spam a través del servidor.

estado de ejecución/línea de ejecución

Estos son dos módulos proxy importantes para ejecutar otros programas en el servidor. Runstatus informa el código de salida del programa al indicador. Por ejemplo, okerr no requiere (requiere) un módulo para verificar que los servicios systemd se estén ejecutando. Esto se hace a través de runstatus (ver más abajo). Runline: informa al servidor la línea que produce el programa. Por ejemplo, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" en la configuración de Runline en nuestro servidor crea un indicador servername:temp con la temperatura del procesador.

sql

Ejecuta una consulta numérica a MySQL e informa el resultado al indicador. En un caso simple, puede hacer, por ejemplo, "SELECCIONAR 1"; esto verificará que el DBMS en su conjunto esté funcionando.

Pero una aplicación mucho más interesante es, por ejemplo, realizar un seguimiento del número de pedidos en una tienda online. Si sabe que tiene 100 o más pedidos por hora, puede establecer el límite mínimo en 100 u 80. Luego, si sus ventas caen repentinamente, recibirá una alerta y podrá resolverlo.

Tenga en cuenta que no importa por qué motivo impredecible sucedió esto:

• El servidor simplemente no está disponible (desenergizado o sin red) y la alerta surgió del hecho de que el indicador estaba "podrido".
• El servidor está sobrecargado con algo, funciona lento o se pierden paquetes, es un inconveniente para los usuarios y se van sin realizar compras.
• El servidor está incluido en las listas de spam y no se aceptan correos electrónicos, los usuarios no pueden registrarse
• El presupuesto para la campaña publicitaria se ha agotado y los carteles no giran.

Puede haber varias razones, y todas ellas no pueden preverse de antemano y es técnicamente difícil de rastrear. Pero puede controlar cómodamente el parámetro final (órdenes) y determinar a partir de ellos que la situación es sospechosa y merece ser solucionada.

Indicadores lógicos

Permite el uso de expresiones booleanas (sintaxis de Python) a través de un módulo. evaluar(artículo sobre Habré). Los datos del proyecto y sus indicadores están disponibles para su expresión. Por ejemplo, en el capítulo anterior sobre verificación de SQL, es posible que haya notado un punto débil: durante el día podemos tener 100 ventas por hora, pero por la noche, 20, y esto es común, no es un problema. ¿Qué tengo que hacer? El indicador entrará en pánico constantemente por la noche.

Puedes crear dos indicadores, día y noche. Haga que ambos sean “silenciosos” (no enviarán alertas). Y crear un indicador lógico que requiera que el indicador de día esté bien antes de las 20:00, y después de las 20:00 basta con que el indicador de noche esté bien.

Otro ejemplo del uso de un indicador lógico es escalada. Por ejemplo, un gerente de proyecto se da de baja de las alertas (no necesita hacerlo, los administradores deben responder a los problemas normales), pero se suscribe a un indicador lógico que se vuelve rojo si algún indicador del proyecto no se corrige dentro del tiempo asignado.

Además, es posible establecer el horario permitido para trabajar, por ejemplo, de 3 a 5 am. No nos importa si los servidores y los sitios fallan durante este tiempo. Pero a las 5:00 tienen que trabajar. Si no funcionan en otro momento - alerta. El indicador lógico también le permite tener en cuenta la redundancia del servidor. Si tiene 5 servidores web, los administradores pueden desactivar 1 o 2 servidores en cualquier momento. Pero si hay menos de 3 de 5 servidores en batalla, habrá una alerta.

Los ejemplos anteriores no son otras funciones, ni algunas características que deban activarse y configurarse. Okerra no tiene todas estas funciones, pero existe un módulo lógico que le permite implementar esta funcionalidad (aproximadamente como en un lenguaje de programación; si tenemos operadores aritméticos, entonces no necesitamos una función especial para calcular el 20% de IVA desde el idioma, siempre puedes hacerlo tú mismo y adaptarlo a tus necesidades).

El indicador lógico es probablemente uno de los pocos temas relativamente complejos en okerr, pero la buena noticia es que no es necesario que lo domines hasta que sea necesario. Pero al mismo tiempo, amplían enormemente las capacidades y mantienen el sistema en sí bastante simple.

Agregar sus propios cheques

Realmente me gustaría transmitir la idea de que okerr no es un conjunto de miles de cheques listos para usar para todas las ocasiones, sino por el contrario, en primer lugar, un motor simple con una capacidad simple para crear sus propios cheques. Crear sus propios controles en okerr no es una tarea para piratas informáticos, codesarrolladores de sistemas o al menos usuarios avanzados de okerr, pero es una tarea factible para cualquier administrador que instaló Linux por primera vez hace un mes.

Los controles de salarios mínimos se realizan a través del módulo. estado de ejecución:

Esta línea en la configuración. estado de ejecución le notificará si /bin/true de repente no se inicia o devuelve algo distinto de 0.

true_OK=/bin/true

Solo una línea, y aquí ya estamos un poco expandido funcionalidad okerr.

Incluso una verificación de este tipo ya tiene su valor: si de repente su servidor falla, el indicador correspondiente en el servidor okerr no se actualizará de manera oportuna y, una vez transcurrido el tiempo, aparecerá una alerta.

Esta comprobación notificará que el servidor apache2 ha fallado (bueno, nunca se sabe...):

apache_OK="systemctl is-active --quiet apache2"

Entonces, si habla algún lenguaje de programación y al menos puede escribir scripts de shell, entonces ya puede agregar sus propias comprobaciones.

Más difícil: puedes escribir (en cualquier idioma) tu propio módulo para okerrmod. En el caso más simple se ve así:

#!/usr/bin/python3

print("STATUS: OK")

¿No es muy difícil? El módulo debe realizar la verificación por sí mismo y enviar los resultados a STDOUT. Un módulo más complejo proporciona, por ejemplo, esto:

$ okerrmod --dump df
NAME: pi:df-/
TAGS: df
METHOD: numerical|maxlim=90
DETAILS: 49.52%, 13.9G/28.2G used, 13.0G free
STATUS: 49.52

NAME: pi:df-/boot
TAGS: df
METHOD: numerical|maxlim=90
DETAILS: 84.32%, 53.1M/62.9M used, 9.9M free
STATUS: 84.32

Actualiza varios indicadores a la vez (separados por una línea vacía), los crea si es necesario, indica detalles de verificación y una etiqueta mediante la cual es fácil encontrar los indicadores necesarios en el tablero.

Telegram

Hay un robot de Telegram @OkerrBot. No es necesario saturar su teléfono con aplicaciones separadas (no me gusta que para Pyaterochka necesite una aplicación con un mapa, para Lenta otra, para MTS una tercera, y así sucesivamente para todos, todos, todos). Un telegrama es suficiente. A través de Telegram puede recibir alertas inmediatamente, verificar el estado del proyecto y dar una orden para volver a verificar todos los indicadores problemáticos. Salimos del teatro/avión, no mantuvimos el dedo en el pulso durante dos horas, encendimos el teléfono, presionamos un botón en el chatbot y nos aseguramos de que todo estuviera bien.

Páginas de estado

Hoy en día, las páginas de estado son casi imprescindibles para cualquier negocio que tenga TI, una actitud responsable hacia la confiabilidad y que trate a sus clientes/usuarios con respeto.

Imagine una situación: un usuario quiere hacer algo, ver información o realizar un pedido y algo no funciona. No sabe qué está pasando, de qué lado está el problema y cuándo se resolverá. ¿Quizás su empresa simplemente tiene un sitio web que no funciona? ¿O se rompió hace seis meses y se arreglará en dos años? Pero necesitas comprar un refrigerador ahora, ya está en el carrito... Y es completamente diferente cuando una persona ve que algo anda mal contigo (al menos está claro que el problema no está de su lado), que el Se ha descubierto el problema, que ya está trabajando en él y tal vez incluso haya anotado el tiempo aproximado para corregirlo. El usuario puede suscribirse y recibir una notificación por correo electrónico cuando se solucione el problema y pueda hacer lo que quiera (comprar un frigorífico).

Los problemas y el tiempo de inactividad le suceden a todo el mundo. Pero los usuarios y socios confían más en aquellos que son más transparentes y responsables en su enfoque al respecto.

aquí está revisión de otros 10 proyectos que le permiten crear páginas de estado. A continuación se muestran ejemplos de cómo se ven estas páginas de proyectos. Python и Dropbox. página de estado de Okerr.

Failover

Para no alargar aún más este artículo, volveré a consultar mi artículo anterior: Conmutación por error simple para un sitio web . Si puede crear un servidor duplicado y utilizar la conmutación por error, básicamente no tendrá un tiempo de inactividad prolongado: tan pronto como se detecte un problema, los usuarios serán redirigidos automáticamente a un servidor de respaldo que funcione. Y me parece que esta es una característica muy interesante y llamativa que rara vez está disponible en ningún lugar.

Bajos requisitos del sistema

Para los servidores de okerr utilizamos máquinas con RAM a partir de 2Gb. Para sensores de red, incluso 512 MB son suficientes. La parte del cliente es generalmente casi nula. (Bolsa de plastico okerrupdate pesa 26 Kb, pero requiere Python3 y bibliotecas estándar). El cliente se ejecuta desde un script cron, por lo que no tiene consumo de memoria persistente. Entre las máquinas que monitoreamos, tenemos sensores (VPS súper barato con 512 Mb de RAM) y una Raspberry Pi. Es posible incluso sin la parte del cliente. enviar actualizaciones a través de curl! (vea abajo)

Teniendo esto en cuenta - okerr, probablemente más gratis sistema de monitoreo de los disponibles, porque incluso para usar otro sistema gratuito de código abierto como Zabbix o Nagios, es necesario asignarle recursos (servidor), y esto ya es dinero. Además, todavía se requiere algo de mantenimiento del servidor. Con okerr, esta parte se puede quitar. O no tienes que eliminarlo y usar tu propio servidor, dependiendo de lo que más te guste.

API e integración en software propietario

Arquitectura sencilla y abierta. okerr tiene uno bastante simple API, con el que es fácil trabajar. ¿Necesita crear 1000 indicadores? Un script de shell de 3 a 4 líneas hará esto. ¿Necesita reconfigurar 1000 indicadores? También es muy fácil. Por ejemplo, queremos volver a verificar todos nuestros certificados HTTPS desde un sensor ruso:

#!/bin/sh

for indicator in `okerrclient --api-filter sslcert`
do
    echo set location for $indicator
    okerrclient --api-set location=ru retest=1 --name $indicator
done

Puede actualizar el indicador utilizando nuestro módulo de cliente, incluso sin él, simplemente mediante curl.

# short and nice (using okerrupdate and config file)
$ okerrupdate MyIndicator OK

# only curl is enough!
$ curl -d 'textid=MyProject&name=MyIndicator&secret=MySecret&status=OK' https://bravo.okerr.com/

Puede actualizar los indicadores directamente desde su programa. Por ejemplo, enviar señales de latidos para que okerr sepa que está funcionando y emita una alarma si falla o se congela. Por cierto, los componentes de okerr hacen precisamente eso: okerr se monitorea a sí mismo y los problemas en casi cualquier módulo serán detectados y generarán una alerta sobre el problema. (Y en el caso de "casi", se verifican desde otro servidor)

Aquí está el código (simplificado) en nuestro bot de Telegram:

from okerrupdate import OkerrProject, OkerrExc

op = OkerrProject()
uptimei = op.indicator("{}:telebot_uptime".format(hostname))
...
uptimei.update('OK', 'pid: {} Uptime: {} cmds: {}'.format(
        os.getpid(), dhms(uptime), commands_cnt))

Existe una biblioteca para actualizar indicadores de programas Python. okerrupdate, para cualquier otro idioma no hay bibliotecas, pero puede llamar al script okerrupdate o realizar una solicitud HTTP al servidor okerr.

Cómo nos ayuda okerr

Okerr cambió nuestras vidas. En efecto. Quizás otro sistema de monitoreo podría hacer lo mismo, pero trabajar con okerr es fácil y sencillo para nosotros y tiene todas las funciones que necesitábamos (agregamos las que no tenía). Por cierto, si faltan algunas funciones, pregunta y las agregaré (no lo prometo, pero quiero que okerr sea el mejor sistema de monitoreo para proyectos pequeños y medianos). O mejor aún, agréguelo usted mismo: es fácil.

Logramos vivir según el principio "aprender sobre todos los problemas del kerra". Si de repente ocurre un problema del que no supimos gracias a okerr, agregamos una marca a okerr. (en este caso, por “nosotros” me refiero a nosotros como usuarios del sistema, no a codesarrolladores). Al principio esto era común, pero ahora se ha vuelto muy raro.

Monitoreo

A través de okerr monitoreamos los tamaños de registro en todos los servidores. Por supuesto, es imposible leer atentamente cada línea del registro con los ojos, pero el simple hecho de controlar la tasa de crecimiento ya da mucho. A través de esto, descubrimos el envío de spam y las búsquedas de contraseñas por fuerza bruta, y cuando algunas de las aplicaciones "se vuelven locas", algo no les funciona y lo repiten una y otra vez (cada vez agregando un par de líneas al registro). ).

Certificados SSL. Casi inmediatamente después del lanzamiento Vamos a cifrar Nuestro cliente comenzó a proporcionar certificados SSL gratuitos a sus clientes (alrededor de mil). ¡Y resultó ser un infierno para la administración! El hecho es que los sitios están "en vivo", los clientes periódicamente les piden que hagan algo, los programadores lo hacen. Pueden transferir el sitio con total libertad a otro DocumentRoot, por ejemplo. O agregue una reescritura incondicional a la configuración del host virtual. Naturalmente, después de esto, la renovación automática de certificados falla. Ahora tenemos todos los hosts SSL agregados a okerr automáticamente a través de otra de nuestras útiles utilidades del paquete. a2conf. simplemente lancemos a2okerr.py — y si aparecen varios sitios nuevos en el servidor, aparecerán automáticamente en okerr. Si de repente por alguna razón el certificado no se renueva, tres semanas antes de que caduque, lo sabremos y descubriremos por qué no se actualiza, tal perro. a2certbot.py del mismo paquete: ayuda mucho con esto (verifica inmediatamente los problemas más probables y escribe lo que se verificó bien y dónde es más probable que haya un problema).

Monitoreamos la fecha de vencimiento de todos nuestros dominios. Y todos nuestros servidores de correo que envían correo también se comparan con más de 50 listas negras diferentes. (Y a veces caen en ellos). Por cierto, ¿sabías que los servidores de correo de Google también están en la lista negra? Solo para realizar una autoevaluación, agregamos mail-wr1-f54.google.com a los servidores monitoreados, ¡y todavía está en la lista negra de SORBS! (Se trata del valor de los “anti-spammers”)

Copias de seguridad: ya escribí anteriormente lo fácil que es monitorearlas con okerr. Pero monitoreamos tanto las últimas copias de seguridad en nuestro servidor como (usando una utilidad separada que usa okerr) las copias de seguridad que cargamos en Amazon Glacier. Y sí, los problemas ocurren de vez en cuando. No es de extrañar que estuvieran mirando.

Usamos el indicador de escalada. Muestra si algún problema no se ha solucionado durante mucho tiempo. Y yo mismo, cuando resuelvo algunos problemas, a veces puedo olvidarme de ellos. La escalada es un buen recordatorio, incluso si usted mismo se está monitoreando.

En general, creo que la calidad de nuestro trabajo ha aumentado en un orden de magnitud. Casi no hay tiempo de inactividad (o el cliente no tiene tiempo de notarlo. ¡Simplemente shh!), mientras que la cantidad de trabajo se ha reducido y las condiciones de trabajo se han vuelto más tranquilas. Hemos pasado del trabajo de emergencia de tapar agujeros con cinta adhesiva a un trabajo tranquilo y medido, cuando muchos problemas se predicen de antemano y hay tiempo para prevenirlos. Incluso los problemas que han ocurrido también se han vuelto más fáciles de solucionar: en primer lugar, nos enteramos antes de que los clientes entren en pánico y, en segundo lugar, a menudo sucede que el problema está relacionado con un trabajo reciente (mientras estaba haciendo una cosa, rompí otra). Entonces hace calor. Es más fácil para los rastros lidiar con eso.

Pero hubo otro caso...

¿Sabías que en el popular Debian 9 (Stretch), un paquete tan popular como phpmyadmin todavía (¡durante muchos meses!) se encuentra en estado vulnerable? (CVE-2019-6798). Cuando surgió la vulnerabilidad, rápidamente la cubrimos de diferentes maneras. Pero configuré el monitoreo de la página de seguimiento de seguridad en okerr para saber cuándo aparecerá una solución "hermosa" (a través de la suma SHA1 del contenido). El indicador me movió varias veces, la página cambió, pero como puedes ver, todavía (¡desde enero de 2019!) no indica que el problema se haya solucionado. Tal vez, por cierto, ¿alguien sepa cuál es el problema de que un paquete tan importante siga siendo vulnerable durante más de un año?

Otra vez en una situación similar: tras una vulnerabilidad en SSH, fue necesario actualizar todos los servidores. Y cuando estableces una tarea, necesitas controlar su ejecución. (Los subordinados tienden a malinterpretar, olvidar, confundirse y cometer errores). Por lo tanto, primero agregamos una verificación de versión SSH a okerr en todos los servidores y, a través de okerr, nos aseguramos de que las actualizaciones se implementaran en todos los servidores. (¡Conveniente! Elegí este tipo de indicador y puedes ver inmediatamente qué servidor tiene cada versión). Cuando estuvimos seguros de que la tarea se completó en todos los servidores, eliminamos los indicadores.

Un par de veces hubo una situación en la que surge cierto problema y luego desaparece por sí solo. (¿probablemente familiar para todos?). Cuando te das cuenta, cuando lo compruebas (y no hay nada que comprobar), todo ya está funcionando bien. Pero luego se vuelve a romper. Esto nos sucedió, por ejemplo, con productos que subimos a Amazon Marketplace (MWS). En algún momento, el inventario cargado era incorrecto (cantidades incorrectas de bienes y precios incorrectos). Lo descubrimos. Pero para poder resolverlo, era importante descubrir el problema de inmediato. Desafortunadamente, MWS, como todos los servicios de Amazon, es un poco lento, por lo que siempre hubo un retraso, pero aun así pudimos comprender al menos de manera aproximada la conexión entre el problema y los scripts que lo causan (lo comprobamos, nos quedamos atascados). al okerr, y lo comprobó inmediatamente recibiendo una alerta).

Recientemente, un proveedor de alojamiento europeo grande y caro, que utiliza nuestro cliente, añadió a la colección un caso interesante. ¡De repente, TODOS nuestros servidores desaparecieron del radar! Primero, el propio cliente (¡más rápido que okerra!) notó que el sitio con el que estaba trabajando no se abría e hizo un ticket al respecto. ¡Pero no sólo un sitio cayó, sino todos! (¡Natasha, lo dejamos todo!). Aquí Okerr comenzó a enviar vendas largas para los pies con todos los indicadores que se iluminaban para él. Pánico, pánico, corremos en círculos (¿qué más podemos hacer?). Entonces todo se levantó. Resulta que había un mantenimiento de rutina en el centro de datos (una vez cada muchos años) y, por supuesto, deberíamos habernos advertido. Pero les pasó algún tipo de problema y no nos avisaron. Bueno, más infartos, menos infartos. Pero después de que todo se haya restaurado, ¡debes volver a verificar todo! No puedo imaginar cómo lo haría con mis manos. Okerr probó todo en unos minutos. Resultó que la mayoría de los servidores simplemente no estaban disponibles temporalmente, pero funcionaron. Algunos estaban sobrecargados, pero también se mantuvieron como debían. De todas las pérdidas, perdimos dos copias de seguridad, que según la corona deberían haber sido creadas y cargadas mientras transcurría este plátano lleno. Ni siquiera me molesté en crearlos, apenas un día después llegaron alertas de que todo estaba bien, habían aparecido copias de seguridad. Me gusta mucho este ejemplo porque okerr resultó ser muy útil en una situación en la que ni siquiera habíamos pensado de antemano, pero ese es el propósito del monitoreo: resistir lo impredecible.

Para los sensores Okerr utilizamos el hosting más barato posible (donde la calidad y la fiabilidad no son importantes, se aseguran entre sí). Recientemente encontramos un alojamiento muy bueno y súper económico, las pruebas comparativas son increíbles. Pero... a veces resulta que las conexiones salientes de la máquina virtual se realizan desde otra IP (vecina). Milagros. módulo client_ip con https://diagnostic.opendns.com/myip obtiene la IP incorrecta. Y de los registros del servidor del indicador se desprende claramente que la actualización también provino de esta IP vecina. Ocupémonos del soporte ahora. Es bueno que nos hayamos dado cuenta de esto en tiempos de paz. Pero, por ejemplo, a menudo sucede que el acceso se registra de acuerdo con la lista blanca de IP, y si el servidor a veces parpadea así por un corto tiempo, puede intentar detectar este problema durante mucho tiempo.

Bueno, una cosa más, ya que estamos hablando de alojamiento VPS, siempre utilizamos servidores económicos (hetzner, ovh, scaleway). Me gusta mucho tanto en términos de puntos de referencia como de estabilidad. También utilizamos el Amazon EC2, mucho más caro, para otros proyectos. Entonces, gracias a okerr, tenemos nuestra propia opinión informada. Ambos caen. Y no diría que durante el largo período de nuestras observaciones, los alojamientos baratos como Hetzner resultaron ser notablemente menos estables que EC2. Por lo tanto, si no está atado a otras funciones de Amazon, ¿por qué pagar más? 🙂

¿Qué será lo próximo?

Si a estas alturas aún no te he asustado de Okerr, ¡pruébalo! Puedes ir directamente a este enlace cuenta demo de okerr (¡Haga clic ahora!) Pero tenga en cuenta que solo hay una cuenta de demostración para todos, por lo que si hace algo, alguien más en la misma cuenta puede interferir con usted al mismo tiempo. O (mejor) regístrese a través del enlace a operador externo - todo es sencillo, sin SMS. Si no te gusta usar tu correo electrónico real, puedes usar uno desechable, como mailinator (recomiendo getnada.com). Estas cuentas pueden eliminarse con el tiempo, pero estarán bien para realizar pruebas.

Después del registro, se le pedirá que realice una capacitación (realice varias tareas de capacitación no muy difíciles). Los límites iniciales son muy pequeños, pero para entrenamiento o un servidor son suficientes. Después de completar la formación, se aumentarán los límites (por ejemplo, el número máximo de indicadores).

De la documentación - en primer lugar WIKI en el lado del servidor y en el cliente (wiki de actualización de okerrupdate). Pero si algo no está claro, escriba al soporte (at) okerr.com o deje un ticket; intentaremos resolverlo todo rápidamente.

Si lo usas seriamente y estos límites aumentados no son suficientes, escribe al soporte y lo aumentaremos (gratis).

¿Le gustaría instalar el servidor okerr en su servidor? Aquí repositorio okerr-dev. Recomendamos instalar en una máquina virtual limpia, luego puede hacerlo simplemente con un script de instalación. En su máquina virtual, sin restricciones :-). Bueno, de nuevo, si pasa algo, siempre intentaremos ayudar.

Queremos que este proyecto despegue, para que el mundo sea más fiable gracias a nosotros. Gracias al software y los servicios gratuitos, el mundo se ha vuelto más amigable y se está desarrollando de manera más dinámica. Las fuentes se pueden almacenar en github gratuito, para el correo puede usar gmail gratuito. Usamos gratis trabajos frescos para soporte. Para nada de esto, no necesita pagar por los servidores, no necesita descargarlos ni configurarlos, y no necesita resolver varios problemas operativos. Cada nuevo proyecto, cada equipo tiene inmediatamente correo, repositorios y CRM. Y todo esto es de muy alta calidad, gratuito e inmediato. Queremos que ocurra lo mismo con el seguimiento: las pequeñas empresas y proyectos podrían utilizar okerr de forma gratuita e incluso en la fase de nacimiento y crecimiento tendrían la fiabilidad de proyectos serios para adultos.

Fuente: habr.com