Hai dous anos xa fixen unha publicación Conmutación por fallo simple para un sitio web sobre okerr. Agora hai algo de desenvolvemento do proxecto, e tamén o publiquei okerr código fonte do lado do servidor en licenza aberta, por iso decidín escribir esta pequena recensión sobre Habr.

[ tamaño completo ]

A quen lle poida interesar

Isto pode ser do teu interese se traballas en equipo pequeno ou só. Non tes vixilancia e non estás seguro de se realmente o necesitas. Ou probaches un seguimento serio popular "para os grandes", pero dalgún xeito "non despegou" para ti, ou funciona nunha configuración case predeterminada e non cambiou moito a túa vida. E tamén - se definitivamente non planea asignar un empregado completo (ou mesmo un departamento) para supervisar o panel de control polo menos un par de horas ao día ou configuralo.

Por que okerr é inusual

A continuación mostrarei características interesantes da okerra que a distinguen dalgúns outros sistemas de vixilancia.

Okerr é un monitor híbrido

Durante a supervisión interna, está a executarse un "axente" nas máquinas supervisadas, que transmite datos ao servidor de supervisión (por exemplo, espazo libre en disco). Cando é externo, o servidor realiza comprobacións na rede (por exemplo, ping ou dispoñibilidade do sitio web). Cada enfoque ten as súas limitacións. Okerr usa ambas opcións. As comprobacións dentro dos servidores son realizadas por un axente moi lixeiro (30 Kb) ou os teus propios scripts e aplicacións, e as comprobacións de rede realízanse a través de sensores okerr en diferentes países.

okerr non é só software, senón tamén un servizo

A parte do servidor de calquera monitorización é grande e complexa, é difícil de instalar e configurar e require recursos. Con okerr podes instalar o teu propio servidor de vixilancia (é gratuíto e de código aberto), ou simplemente podes usar só a parte cliente e usar o servizo do noso servidor. Tamén gratuíto.

Se a supervisión permítelle compensar e cubrir a falta de fiabilidade nos servidores e aplicacións, xorde unha pregunta filosófica: quen é o garda? Como nos informará o seguimento dun problema se este mesmo "morreu" por algún motivo, por separado ou xunto cos outros recursos (por exemplo, a canle ao centro de datos caeu)? Cando use o servizo externo okerr -este problema está resolto- recibirá unha alerta aínda que todo o centro de datos cos seus servidores estea sen enerxía ou sexa atacado por zombies.

Por suposto, existe o risco de que o propio servidor okerr non estea dispoñible, isto é certo (como sabes, o 90% da fiabilidade sempre se obtén de forma sinxela e "gratuíta", o 99% cun mínimo de esforzo, e cada nove posteriores é exponencialmente máis difícil). Pero, en primeiro lugar, as posibilidades de que isto ocorra son menores e, en segundo lugar, o problema pode pasar desapercibido só se coincide con problemas nos nosos servidores. Se temos unha fiabilidade do 99.9% e tes un 99.9% (números non demasiado altos), entón a probabilidade de que un fallo non se detecte é do 0.1% do 0.1% = 0.0001%. Engadir tres nove á túa fiabilidade case sen esforzo e sen custo é moi bo!

Outra vantaxe do seguimento como servizo é que un provedor de hospedaxe ou estudo web pode instalar un servidor okerr e proporcionar acceso aos clientes como servizo adicional de pago ou gratuíto. Os teus competidores só teñen aloxamento e sitios web, pero tes un hospedaxe fiable con seguimento.

Okerr trata de indicadores

O indicador é unha "bombilla". Ten dous estados principais: verde (OK) ou vermello (ERR). O proxecto contén moitos indicadores agrupados (por exemplo, por servidor). Na páxina principal do proxecto, inmediatamente ves que ou todo é verde (e podes pechalo) ou algo está iluminado en vermello e hai que corrixilo. Cando se realiza a transición entre estes estados, envíase unha alerta. Unha vez ao día, mentres o estás configurando, envíase un resumo do proxecto.

Cada indicador okerr ten condicións integradas polas que cambia de estado (en Zabbix chámase disparador). Por exemplo, a media de carga non debe ser superior a 2 (por suposto, isto é configurable). E para cada comprobación interna (media de carga, libre de disco,...) hai un vixilante. Se por algún motivo non recibimos unha confirmación exitosa á hora sinalada, rexistrarase un erro e envíase unha alerta.

O noso patrón de traballo habitual é consultar os correos electrónicos pola mañá, e mirar o resumo entre outras cartas (prográmolo ao comezo do traballo). Se todo está ben nel, facemos outras cousas importantes (pero para estar seguros, podemos mirar rapidamente o panel de control de okerra e asegurarnos de que todo estea verde neste momento). Se chega unha alerta, reaccionamos.

Por suposto, é posible simplemente manter indicadores "informativos" (para ver a imaxe da rede desde o seguimento), pero todo se fai para crear de forma sinxela, sinxela e rápida indicadores específicos para o seguimento automático e o envío de alertas.

O propósito para o que estás configurando okerr está nas alertas, para que poidas crear un indicador nun minuto, podería "durmir" durante un ano, só aceptas actualizacións e, cando un ano despois, algo rompe, acendese e envíase unha alerta. O minuto que dedicou a crear un indicador pagou a pena; soubo do problema inmediatamente, antes que ninguén. É posible que o solucionaran antes de que ninguén se decatase. Algo que se levanta rapidamente non se considera que caeu!

Безопасность

Sería unha mágoa se configuras a monitorización para aumentar a fiabilidade, pero como resultado, é atacado pola rede a través dela e hai moitas vulnerabilidades de rede en diferentes ferramentas de monitorización (Zabbix, Nagios).

Axente (okerrmod do paquete okerrupdate) que se executa no sistema non é un servidor de rede, senón un cliente. Polo tanto, non hai portos adicionais abertos no servidor supervisado, o cliente traballa facilmente detrás dun firewall ou NAT e é moi difícil (eu diría "imposible") piratear a rede, xa que en principio non escoita a rede. enchufe.

Cobertura total de seguimento

Agora a nosa regra é que aprendemos todos os problemas técnicos de okerr. Se de súpeto se infrinxe a regra (okerr non avisou sobre a súa aparición inminente (se isto é posible) ou que xa ocorreu) - engadimos comprobacións a okerr.

Comprobacións externas

Un conxunto bastante típico:

• pingar
• estado http
• comprobando a validez e frescura do certificado SSL (avisará se está a piques de caducar)
• abra o porto TCP e o banner nel
• http grep (a páxina [non debe] conter texto específico)
• sha1 hash para detectar os cambios de páxina.
• DNS (o rexistro DNS debe ter un valor específico)
• WHOIS (avisará se o dominio está a piques de fallar)
• DNSBL antispam (comprobación do host contra máis de 50 listas negras antispam á vez)

Comprobacións internas

Ademais, un conxunto bastante estándar (pero facilmente ampliable).

• df (espazo libre en disco)
• carga media
• opentcp (abrir sockets de escoita TCP - notificará se algo comezou ou fallou)
• uptime - só tempo de actividade no servidor. Notificará se cambiou abaixo (é dicir, o servidor sobrecargouse)
• cliente_ip
• disize - usámolo para rastrexar cando os rootfs da nosa máquina virtual superan o tamaño permitido, sen introducir restricións estritas, e o tamaño dos directorios de inicio dos usuarios
• empty and nonempty: supervisa os ficheiros que deberían estar baleiros (ou non baleiros). Por exemplo, o rexistro de erros do propio servidor okerr debería estar baleiro e, se mesmo hai unha liña nel, recibirei unha notificación e comprobarei. Pero mail.log no servidor de correo NON debe estar baleiro (N minutos despois da rotación). E ás veces estaba baleiro para nós despois dunha actualización do sistema, cando logrotate non podía reiniciar rsyslog correctamente.
• linecount - número de liñas no ficheiro (como wc -l). Utilizámolo como un substituto máis suave para o baleiro, cando o rexistro de erros aínda pode crecer, pero só lentamente (por exemplo, Googlebot chega a algunhas páxinas pechadas). Hai un límite de 2 liñas en 20 minutos. Se é máis alto, haberá unha alerta

Interesantes comprobacións internas

Se estiveches lendo "en diagonal" ata este momento, agora será máis interesante ler con máis atención.

copias de seguridade

Supervisa as copias de seguridade no directorio. Os nosos ficheiros de copia de seguranza teñen nomes como "ServerName-20200530.tar.gz". Para cada servidor en okerr, créase o indicador ServerName-DATE.tar.gz (a data real cambia á liña "DATE"). Tamén se supervisa a propia presenza dunha copia de seguridade nova e o seu tamaño (por exemplo, non pode ser inferior ao 90% da copia de seguridade anterior).

Que hai que facer para que comece a rastrexar unha nova copia de seguranza despois de que comezamos a creala e poñelas neste directorio? Nada! Este é un enfoque moi cómodo cando precisas facer "nada" porque:

• Non facer "nada" é bastante rápido, aforra tempo
• É difícil esquecer "non facer nada"
• É difícil facer "nada" mal, cun erro. Nada é o método máis fiable

Se de súpeto deixan de aparecer ficheiros de copia de seguranza novos, haberá unha alerta. Se, por exemplo, desactivaches un dos servidores e non debería haber máis copias de seguridade, terás que eliminar o indicador (a través da interface web ou do shell a través da API).

maxfilesz

Fai un seguimento do tamaño dos ficheiros máis grandes (normalmente: /var/log/*). Isto permítelle detectar problemas imprevisibles, por exemplo, contrasinais de forza bruta ou envío de spam a través do servidor.

runstatus/runline

Estes son dous módulos proxy importantes para executar outros programas no servidor. Runstatus informa do código de saída do programa ao indicador. Por exemplo, okerr non (require) un módulo para comprobar que os servizos systemd estean en execución. Isto faise mediante runstatus (ver máis abaixo). Liña de execución: informa ao servidor da liña que produce o programa. Por exemplo, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" na configuración Runline do noso servidor crea un indicador servername:temp coa temperatura do procesador.

SQL

Executa unha consulta numérica a MySQL e informa do resultado ao indicador. Nun caso sinxelo, podes facer, por exemplo, "SELECT 1": isto comprobará que o DBMS funciona como un todo.

Pero unha aplicación moito máis interesante é, por exemplo, o seguimento do número de pedidos nunha tenda en liña. Se sabes que tes 100 ou máis pedidos por hora, podes establecer o límite mínimo en 100 ou 80. Entón, se as túas vendas caen de súpeto, recibirás unha alerta e poderás descubrilo.

Teña en conta que non importa por que motivo imprevisible ocorreu isto:

• O servidor simplemente non está dispoñible (desactivado ou sen rede) e a alerta veu polo feito de que o indicador estaba "podre".
• O servidor está sobrecargado con algo, funciona lentamente ou pérdense paquetes, é un inconveniente para os usuarios e saen sen facer compras
• O servidor está incluído nas listas de correo non desexado e non se acepta o correo do mesmo, os usuarios non poden rexistrarse
• O orzamento da campaña publicitaria esgotouse, as pancartas non xiran.

Pode haber moitas razóns, e todas non se poden prever de antemán, e técnicamente é difícil de rastrexar. Pero pode supervisar convenientemente o parámetro final (pedidos) e determinar a partir deles que a situación é sospeitosa e merece ser tratada.

Indicadores lóxicos

Permite o uso de expresións booleanas (sintaxe Python) a través dun módulo validar(artigo sobre Habré). Os datos do proxecto e os seus indicadores están dispoñibles para a súa expresión. Por exemplo, no capítulo anterior sobre a comprobación de SQL, quizais teña notado un punto débil: durante o día podemos ter 100 vendas por hora, pero pola noite, 20, e isto é común, non é un problema. Qué debería facer? O indicador entrará en pánico constantemente pola noite.

Podes crear dous indicadores, día e noite. Facer os dous "silencios" (non enviarán alertas). E crea un indicador lóxico que requira que o indicador de día estea correcto antes das 20:00 e despois das 20:00 é suficiente para que o indicador nocturno estea correcto.

Outro exemplo de uso dun indicador lóxico é escalada. Por exemplo, un xestor de proxecto cancela a subscrición das alertas (non ten necesidade de facelo, os administradores deben responder aos problemas normais), pero subscríbese a un indicador lóxico que se volve vermello se algún indicador do proxecto non se corrixe no tempo previsto.

Ademais, é posible establecer o horario permitido para o traballo, por exemplo, de 3 a 5 da mañá. Non nos importa se os servidores e os sitios fallan durante este tempo. Pero ás 5:00 horas teñen que traballar. Se non funcionan noutro momento, alerta. O indicador lóxico tamén permite ter en conta a redundancia do servidor. Se tes 5 servidores web, os administradores poden desactivar 1 ou 2 servidores en calquera momento. Pero se hai menos de 3 de cada 5 servidores en batalla, haberá unha alerta.

Os exemplos anteriores non son funcións correctas, nin algunhas funcións que deben ser activadas e configuradas. Okerra non ten todas estas funcións, pero hai un módulo lóxico que che permite implementar esta funcionalidade (Aproximadamente como nunha linguaxe de programación: se temos operadores aritméticos, non necesitamos unha función especial para calcular o 20% de IVE). desde o idioma, sempre pode facelo vostede mesmo para adaptalo ás súas necesidades).

O indicador lóxico é probablemente un dos poucos temas relativamente complexos en okerr, pero a boa noticia é que non tes que dominalo ata que o precises. Pero ao mesmo tempo, amplían moito as capacidades, mantendo o sistema en si bastante sinxelo.

Engadindo os teus propios cheques

Gustaríame transmitir a idea de que okerr non é un conxunto de miles de comprobacións preparadas para todas as ocasións, senón pola contra, en primeiro lugar, un motor sinxelo cunha simple habilidade para crear os teus propios cheques. Crear as túas propias comprobacións en okerr non é unha tarefa para hackers, co-desenvolvedores do sistema ou polo menos usuarios avanzados de okerr, senón unha tarefa factible para calquera administrador que instalou Linux por primeira vez hai un mes.

A comprobación do salario mínimo realízase a través do módulo estado de execución:

Esta liña na configuración estado de execución notificarache se /bin/true de súpeto non se inicia ou devolve algo que non sexa 0.

true_OK=/bin/true

Só unha liña - e aquí xa estamos un pouco expandido funcionalidade okerr.

Incluso tal comprobación xa ten o seu valor: se de súpeto o teu servidor falla, o indicador correspondente no servidor okerr non se actualizará a tempo e, unha vez transcorrido o tempo, aparecerá unha alerta.

Esta comprobación notificará que o servidor apache2 fallou (ben, nunca se sabe...):

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

Entón, se falas calquera linguaxe de programación, e polo menos podes escribir scripts de shell, xa podes engadir as túas propias comprobacións.

Máis difícil: podes escribir (en calquera idioma) o teu propio módulo para okerrmod. No caso máis sinxelo, ten o seguinte aspecto:

#!/usr/bin/python3

print("STATUS: OK")

Non é moi difícil? O módulo debe facer a comprobación por si mesmo e enviar os resultados a STDOUT. Un módulo máis complexo dá, por exemplo, isto:

$ 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 á vez (separados por unha liña baleira), créaos se é necesario, indica detalles de verificación e unha etiqueta pola que é fácil atopar os indicadores necesarios no panel.

Telegrama

Hai un bot de Telegram @OkerrBot. Non necesitas desordenar o teu teléfono con aplicacións separadas (non me gusta que para Pyaterochka necesites unha aplicación cun mapa, para Lenta outra, para MTS unha terceira, e así sucesivamente para todos, todos, todos). Un telegrama é suficiente. A través de telegram pode recibir alertas de inmediato, comprobar o estado do proxecto e dar un comando para comprobar de novo todos os indicadores problemáticos. Saímos do teatro/avión, non mantivemos o pulso durante dúas horas, acendemos o teléfono, prememos un botón do chatbot e asegurámonos de que todo estaba ben.

Páxinas de estado

Hoxe en día, as páxinas de estado son case imprescindibles para calquera empresa que teña TI, unha actitude responsable ante a fiabilidade e que trate aos seus clientes/usuarios con respecto.

Imaxina unha situación: un usuario quere facer algo, ver información ou facer un pedido e algo non funciona. Non sabe o que está a pasar, de que lado está o problema e cando se resolverá. Quizais a túa empresa simplemente teña un sitio web non funcional? Ou rompeuse hai seis meses e arranxarase en dous anos? Pero cómpre mercar agora un frigorífico, xa está no carro... E outra cousa é completamente diferente cando unha persoa ve que algo che pasa (polo menos está claro que o problema non está do seu lado), que descubriuse o problema, que xa estás traballando nel, e quizais mesmo anotou o tempo aproximado para a corrección. O usuario pode subscribirse e recibir unha notificación por correo electrónico cando se solucione o problema e pode facer o que queira (mercar unha neveira).

Os problemas e o tempo de inactividade ocorren con todos. Pero os usuarios e socios confían máis nos que son máis transparentes e responsables no seu enfoque.

Aquí revisión doutros 10 proxectos que che permiten crear páxinas de estado. Aquí tes exemplos do aspecto destas páxinas do proxecto Pitão и Dropbox. páxina de estado de okerr.

Failover

Para non prolongar aínda máis este artigo, volverei a referirme ao meu artigo anterior - Conmutación por fallo simple para un sitio web . Se podes crear un servidor duplicado e, a continuación, usar a conmutación por fallo, basicamente non terás moito tempo de inactividade; en canto se detecte un problema, os usuarios serán redirixidos automaticamente a un servidor de copia de seguranza que funcione. E paréceme que esta é unha característica moi interesante e brillante que raramente está dispoñible en calquera lugar.

Baixos requisitos do sistema

Para os servidores okerr, usamos máquinas con RAM de 2 Gb. Para sensores de rede, ata 512 Mb son suficientes. A parte do cliente é xeralmente case cero. (Bolsa de plástico okerrupdate pesa 26 Kb, pero require Python3 e bibliotecas estándar). O cliente execútase desde un script cron, polo que non consume memoria persistente cero. Entre as máquinas que monitorizamos, temos sensores (VPS super-barato con 512 Mb de RAM) e unha Raspberry Pi. É posible mesmo sen a parte do cliente enviar actualizacións a través de curl! (Ver abaixo)

Tendo isto en conta - okerr, probablemente máis gratuíto sistema de vixilancia dos dispoñibles, porque incluso para usar outro sistema de código aberto gratuíto como Zabbix ou Nagios, cómpre destinarlle recursos (servidor), e isto xa é diñeiro. Ademais, aínda é necesario algún mantemento do servidor. Con okerr, esta parte pódese eliminar. Ou non tes que eliminalo e usar o teu propio servidor, dependendo do que máis che guste.

API e integración en software propietario

Arquitectura sinxela e aberta. okerr ten un moi sinxelo API, que é fácil de traballar. Necesitas crear 1000 indicadores? Un guión de shell de 3-4 liñas fará isto. Necesitas reconfigurar 1000 indicadores? Tamén é moi doado. Por exemplo, queremos comprobar todos os nosos certificados HTTPS dun 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

Podes actualizar o indicador usando o noso módulo cliente, aínda sen el, só a través de 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/

Podes actualizar os indicadores directamente desde o teu programa. Por exemplo, enviar sinais de latido do corazón para que okerr saiba que está a funcionar e activa unha alarma se falla ou se conxela. Por certo, os compoñentes de okerr fan exactamente iso: okerr monitorízase a si mesmo e detectaranse problemas en case calquera módulo e xerarán unha alerta sobre o problema. (E no caso deste "case" - son comprobados doutro servidor)

Aquí está o código (simplificado) no noso 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))

Hai unha biblioteca para actualizar indicadores dos programas Python okerrupdate, para calquera outro idioma non hai bibliotecas, pero pode chamar ao script okerrupdate ou facer unha solicitude HTTP ao servidor okerr.

Como nos axuda okerr

Okerr cambiou as nosas vidas. Por suposto. Quizais outro sistema de monitorización poida facer o mesmo, pero traballar con okerr é sinxelo e sinxelo para nós e ten todas as funcións que necesitabamos (engadimos o que non tiña). Por certo, se faltan algunhas funcións, pregunta e engadirei (non o prometo, pero quero que okerr sexa o mellor sistema de seguimento para proxectos pequenos-medianos). Ou mellor aínda, engádeo vostede mesmo: é doado.

Conseguimos vivir segundo o principio de "aprender todos os problemas do kerra". Se de súpeto ocorre un problema do que non nos enteramos de okerr, engadimos unha verificación a okerr. (neste caso, por "nós" refírome a nós como usuarios do sistema, non co-desenvolvedores). Ao principio isto era común, pero agora volveuse moi raro.

Seguimento

A través de okerr monitorizamos os tamaños dos rexistros en todos os servidores. Por suposto, é imposible ler coidadosamente todas as liñas do rexistro cos teus ollos, pero simplemente controlar a taxa de crecemento xa dá moito. A través diso, descubrimos o correo lixo e as buscas de contrasinais de forza bruta, e cando algunhas das aplicacións "tolean", algo non lles funciona e repíteno unha e outra vez (cada vez engadindo un par de liñas ao rexistro ).

Certificados SSL. Case inmediatamente despois do lanzamento Permite cifrar o noso cliente comezou a proporcionar certificados SSL gratuítos aos seus clientes (uns mil deles). E resultou ser un inferno para a administración! O caso é que os sitios están "en vivo", os clientes pídenlles periodicamente que fagan algo, os programadores fano. Poden transferir completamente libremente o sitio a outro DocumentRoot, por exemplo. Ou engade unha reescritura incondicional á configuración de virtualhost. Por suposto, despois disto, a renovación automática dos certificados rompe. Agora temos todos os hosts SSL engadidos a okerr automaticamente a través doutra das nosas utilidades útiles do paquete a2conf. Imos só lanzar a2okerr.py — e se aparecen varios sitios novos no servidor, aparecerán automaticamente en okerr. Se de súpeto por algún motivo non se renova o certificado, tres semanas antes de que caduque o certificado, estaremos ao tanto e descubriremos por que non se actualiza, tal can. a2certbot.py do mesmo paquete -axuda moito con isto (comproba inmediatamente os problemas máis probables- e escribe ben o que se comprobou e onde hai máis probable un problema).

Seguimos a data de caducidade de todos os nosos dominios. E todos os nosos servidores de correo que envían correo tamén están comprobados con máis de 50 listas negras diferentes. (E ás veces caen neles). Por certo, sabías que os servidores de correo de Google tamén están na lista negra? Só para facer a autoproba, engadimos mail-wr1-f54.google.com aos servidores supervisados ​​e aínda está na lista negra de SORBS. (Isto é sobre o valor de "anti-spammers")

Copias de seguridade: xa escribín arriba o fácil que é supervisalas con okerr. Pero monitorizamos tanto as copias de seguridade máis recentes do noso servidor como (utilizando unha utilidade separada que usa okerr) as copias de seguridade que cargamos en Amazon Glacier. E, si, os problemas ocorren de cando en vez. Non é de estrañar que estivesen mirando.

Usamos o indicador de escalada. Mostra se algún problema non se solucionou durante moito tempo. E eu mesmo, cando resolvo algúns problemas, ás veces podo esquecerme deles. A escalada é un bo recordatorio, aínda que se estea supervisando.

En xeral, creo que a calidade do noso traballo aumentou nunha orde de magnitude. Case non hai tempo de inactividade (ou o cliente non ten tempo para notalo. Só shh!), mentres que a cantidade de traballo reduciuse e as condicións de traballo fixéronse máis tranquilas. Pasamos dos traballos de emerxencia con parches de buratos con cinta a un traballo tranquilo e medido, cando se prevén moitos problemas de antemán e hai tempo para evitalos. Mesmo os problemas que ocorreron tamén se fixeron máis fáciles de solucionar: en primeiro lugar, decatámonos deles antes de que os clientes entren en pánico e, en segundo lugar, adoita ocorrer que o problema está relacionado con traballos recentes (mentres estaba facendo unha cousa, rompei outra) - polo que fai calor É máis doado que os trazos poidan tratar con iso.

Pero houbo outro caso...

Sabías que no popular Debian 9 (Stretch) un paquete tan popular como phpmyadmin aínda está (por moitos meses!) no estado vulnerable? (CVE-2019-6798). Cando xurdiu a vulnerabilidade, cubrimos axiña de diferentes xeitos. Pero configurei o seguimento da páxina de seguimento de seguridade en okerr para saber cando sairá unha solución "bonita" (a través da suma SHA1 do contido). O indicador torceume varias veces, a páxina cambiou, pero como podes ver, aínda (desde xaneiro de 2019!) non indica que o problema fose resolto. Quizais, por certo, alguén sabe cal é o problema de que un paquete tan importante segue sendo vulnerable durante máis dun ano?

Outra vez nunha situación semellante: tras unha vulnerabilidade en SSH, foi necesario actualizar todos os servidores. E cando estableces unha tarefa, cómpre controlar a execución. (Os subordinados tenden a malinterpretar, esquecerse, confundirse e cometer erros). Polo tanto, primeiro engadimos unha comprobación da versión SSH a okerr en todos os servidores, e a través de okerr asegurámonos de que as actualizacións se lanzaran en todos os servidores. (Conveniente! Eu escollín este tipo de indicador, e inmediatamente podes ver que servidor ten que versión). Cando estabamos seguros de que a tarefa se completaba en todos os servidores, eliminamos os indicadores.

Un par de veces houbo unha situación na que un certo problema xorde, e despois desaparece por si só. (probablemente familiar para todos?). Cando te decatas, cando comprobas -e non hai nada que comprobar-, xa todo funciona ben. Pero despois rompe outra vez. Isto ocorreu, por exemplo, con produtos que cargamos en Amazon Marketplace (MWS). Nalgún momento, o inventario cargado foi incorrecto (cantidades incorrectas de mercadorías e prezos incorrectos). Descubrimos. Pero para descubrilo, era importante descubrir o problema de inmediato. Desafortunadamente, MWS, como todos os servizos de Amazon, é un pouco lento, polo que sempre houbo un atraso, pero aínda así, puidemos comprender, polo menos, aproximadamente a conexión entre o problema e os scripts que o causan (fixemos unha comprobación, atascamos ao okerr e comprobouno inmediatamente recibindo unha alerta).

Recentemente engadiuse á colección un caso interesante por parte dun amplo e caro hoster europeo, que utiliza o noso cliente. De súpeto, TODOS os nosos servidores desapareceron do radar! En primeiro lugar, o propio cliente (máis rápido que okerra!) decatouse de que o sitio co que estaba a traballar non se abría e fixo un ticket ao respecto. Pero non só un sitio caeu, senón todos! (Natasha, deixámolo todo!). Aquí Okerr comezou a enviar longas envolturas de pé con todos os indicadores que se iluminaban para el. Pánico, pánico, corremos en círculos (que máis podemos facer?). Entón todo subiu. Resulta que no centro de datos había un mantemento rutineiro (unha vez cada moitos anos) e, por suposto, deberíamos ter sido avisados. Pero pasoulles algún tipo de problema e non nos avisaron. Pois máis ataques cardíacos, menos ataques cardíacos. Pero despois de que todo estea restaurado, cómpre comprobar todo. Non podo imaxinar como o faría coas miñas mans. Okerr probou todo en poucos minutos. Resultou que a maioría dos servidores simplemente non estaban dispoñibles temporalmente, pero funcionaron. Algúns estaban sobrecargados, pero tamén se erguían como debían. De todas as perdas, perdemos dúas copias de seguridade, que segundo a coroa deberían ter sido creadas e cargadas mentres se producía esta banana chea. Nin sequera me molestei en crealos, só un día despois chegaron as alertas de que todo estaba ben, apareceran as copias de seguridade. Gústame moito este exemplo porque okerr resultou ser moi útil nunha situación na que nin sequera pensabamos de antemán, pero ese é o propósito da vixilancia: resistir o imprevisible.

Para os sensores Okerr, usamos o hospedaxe máis barato posible (onde a calidade e a fiabilidade non son importantes, asegúranse mutuamente). Entón, recentemente atopamos un aloxamento moi bo e súper barato, os puntos de referencia son incribles. Pero... ás veces resulta que as conexións de saída da máquina virtual fanse desde outra IP (veciña). Milagres. Módulo Client_ip con https://diagnostic.opendns.com/myip obtén a IP incorrecta. E dos rexistros do servidor do indicador está claro que a actualización tamén veu desta IP veciña. Imos xestionar o apoio agora. É bo que o notamos en tempo de paz. Pero, por exemplo, adoita ocorrer que o acceso está rexistrado segundo a lista branca de IP -e se o servidor ás veces parpadea así durante un breve tempo- podes tentar detectar este problema durante moito tempo.

Ben, unha cousa máis, xa que falamos de hospedaxe VPS, sempre usamos outros económicos (hetzner, ovh, scaleway). Gústame moito tanto en puntos de referencia como en estabilidade. Tamén usamos o Amazon EC2 moito máis caro para outros proxectos. Entón, grazas a okerr, temos a nosa propia opinión informada. Caen os dous. E non diría que durante o longo período das nosas observacións, hospedaxes baratos como hetzner resultaron ser sensiblemente menos estables que EC2. Polo tanto, se non estás vinculado a outras funcións de Amazon, por que pagar máis? 🙂

Cal é o próximo?

Se neste momento aínda non te asustei de Okerr, probalo! Podes ir directamente a esta ligazón conta de demostración okerr (Fai clic agora!) Pero ten en conta que só hai unha conta de demostración para todos, polo que se fai algo, é posible que outra persoa na mesma conta interfira contigo ao mesmo tempo. Ou (mellor) rexistrarse a través da ligazón a okerr fóra do sitio - todo é sinxelo, sen SMS. Se non che gusta usar o teu correo electrónico real, podes usar un desbotable, como mailinator (recomendo getnada.com). Estas contas poden eliminarse co paso do tempo, pero estarán ben para as probas.

Despois da inscrición, solicitaráselle unha formación (realizar varias tarefas de adestramento non moi difíciles). Os límites iniciais son moi pequenos, pero para a formación ou un servidor son suficientes. Despois de completar a formación, aumentaranse os límites (por exemplo, o número máximo de indicadores).

A partir da documentación - en primeiro lugar WIKI no lado do servidor e no cliente (okerrupdate wiki). Pero se algo non está claro, escribe ao soporte (en) okerr.com ou deixa un ticket: tentaremos solucionalo todo rapidamente.

Se o usas en serio e estes límites aumentados non son suficientes, escribe ao soporte e aumentarémolo (de balde).

Quere instalar o servidor okerr no seu servidor? Aquí repositorio okerr-dev. Recomendamos a instalación nunha máquina virtual limpa, entón simplemente pode facelo cun script de instalación. Na túa máquina virtual - sen restricións :-). Ben, de novo, se pasa algo, sempre tentaremos axudar.

Queremos que este proxecto despegue, para que o mundo sexa máis fiable grazas a nós. Grazas ao software e aos servizos libres, o mundo fíxose máis amigable e desenvólvese de forma máis dinámica. As fontes pódense almacenar en github gratuíto, para o correo podes usar gmail gratuíto. Usamos gratis frescos para apoio. Para nada disto, non precisa pagar por servidores, non precisa descargar e configurar e non precisa resolver varios problemas operativos. Cada proxecto novo, cada equipo ten inmediatamente correo, repositorios e CRM. E todo isto é de moi alta calidade e gratuíto e inmediatamente. Queremos que sexa o mesmo para o seguimento: as pequenas empresas e proxectos poderían usar okerr de balde e mesmo na fase de nacemento e crecemento teñen a fiabilidade de proxectos serios para adultos.

Fonte: www.habr.com