Há dois anos eu já fiz um post Failover simples para um site sobre ok. Agora há algum desenvolvimento do projeto, e também publiquei código fonte do lado do servidor okerr em licença aberta, é por isso que decidi escrever esta breve resenha sobre Habr.

[ tamanho grande ]

A quem possa interessar

Isso pode ser do seu interesse se você trabalha em uma equipe pequena ou sozinho. Você não tem monitoramento e não tem certeza se realmente precisa dele. Ou você tentou algum monitoramento popular e sério “para os grandes”, mas de alguma forma “não decolou” para você, ou funciona em uma configuração quase padrão e não mudou muito sua vida. E também - se você definitivamente não planeja alocar um funcionário inteiro (ou mesmo um departamento) para monitorar o painel de monitoramento pelo menos algumas horas por dia ou configurá-lo.

Por que okerr é incomum

A seguir mostrarei características interessantes do okerra que o distinguem de alguns outros sistemas de monitoramento.

Okerr é um monitoramento híbrido

Durante o monitoramento interno, um “agente” está em execução nas máquinas monitoradas, que transmite dados para o servidor de monitoramento (por exemplo, espaço livre em disco). Quando externo, o servidor realiza verificações na rede (por exemplo, ping ou disponibilidade do site). Cada abordagem tem suas limitações. Okerr usa ambas as opções. As verificações dentro dos servidores são realizadas por um agente muito leve (30 KB) ou por seus próprios scripts e aplicativos, e as verificações de rede são realizadas por meio de sensores okerr em diferentes países.

okerr não é apenas software, mas também um serviço

A parte do servidor de qualquer monitoramento é grande e complexa, é difícil de instalar e configurar e requer recursos. Com okerr você pode instalar seu próprio servidor de monitoramento (é gratuito e de código aberto), ou pode simplesmente usar apenas a parte cliente e utilizar o serviço do nosso servidor. Também grátis.

Se o monitoramento permite compensar e encobrir a falta de confiabilidade em servidores e aplicações, surge então uma questão filosófica - quem é o guarda? Como o monitoramento nos informará sobre um problema se ele próprio “morreu” por algum motivo, separadamente ou junto com seus outros recursos (por exemplo, o canal para o data center caiu)? Ao utilizar o serviço externo okerr - esse problema está resolvido - você receberá um alerta mesmo que todo o data center com seus servidores fique sem energia ou seja atacado por zumbis.

Claro, existe o risco de o próprio servidor okerr ficar indisponível, isso é verdade (como você sabe, 90% da confiabilidade é sempre obtida de forma simples e “gratuita”, 99% com um mínimo de esforço, e cada nove subsequentes é exponencialmente mais difícil). Mas, em primeiro lugar, as chances de isso acontecer são menores e, em segundo lugar, o problema só pode passar despercebido se coincidir com problemas nos nossos servidores. Se tivermos 99.9% de confiabilidade e você tiver 99.9% (números não muito altos), então a chance de uma falha não detectada é de 0.1% de 0.1% = 0.0001%. Adicionar três noves à sua confiabilidade quase sem esforço e sem custo é muito bom!

Outra vantagem do monitoramento como serviço é que um provedor de hospedagem ou web studio pode instalar um servidor okerr e fornecer acesso aos clientes como um serviço adicional pago ou gratuito. Seus concorrentes possuem apenas hospedagem e sites, mas você possui hospedagem confiável com monitoramento.

Okerr é sobre indicadores

O indicador é uma “lâmpada”. Possui dois estados principais - verde (OK) ou vermelho (ERR). O projeto contém muitos indicadores agrupados (por exemplo, por servidor). Na página principal do projeto você vê imediatamente que ou tudo está verde (e você pode fechá-lo), ou algo está vermelho e precisa ser corrigido. Ao fazer a transição entre esses estados, um alerta é enviado. Uma vez por dia, durante a configuração, um resumo do projeto é enviado.

Cada indicador okerr possui condições integradas pelas quais ele muda de estado (no Zabbix isso é chamado de gatilho). Por exemplo, a média de carga não deve ser superior a 2 (é claro, isso é configurável). E para cada verificação interna (carga média, disco livre, ...) existe um watchdog. Se por algum motivo não recebermos uma confirmação bem-sucedida na hora marcada, um erro será registrado e um alerta será enviado.

Nosso padrão habitual de trabalho é verificar os e-mails pela manhã, e olhar o resumo entre outras cartas (agendamos no início do trabalho). Se tudo estiver bem nele, fazemos outras coisas importantes (mas por segurança, podemos olhar rapidamente o painel do okerra e ter certeza de que tudo está verde neste momento). Se chegar um alerta, reagimos.

Claro que é possível simplesmente manter indicadores “informativos” (para ver a imagem da rede a partir do monitoramento), mas tudo é feito para criar de forma simples, fácil e rápida indicadores específicos para monitoramento automático e envio de alertas.

A finalidade para a qual você está configurando o okerr está nos alertas, para que você possa criar um indicador em um minuto, ele poderia “dormir” por um ano, apenas aceitar atualizações, e quando um ano depois algo quebrar, ele acende e envia um alerta. O minuto que você gastou criando um indicador valeu a pena; você aprendeu sobre o problema imediatamente, antes de qualquer outra pessoa. É possível que eles tenham consertado antes que alguém percebesse. Algo que sobe rapidamente não é considerado que caiu!

segurança

Seria uma pena se você configurasse o monitoramento para aumentar a confiabilidade, mas, como resultado, você será atacado na rede por meio dele e há muitas vulnerabilidades de rede em diferentes ferramentas de monitoramento (Zabbix, Nagios).

Agente (okerrmod do pacote okerrupdate) em execução no sistema não é um servidor de rede, mas um cliente. Portanto, não há portas abertas adicionais no servidor monitorado, o cliente funciona facilmente atrás de um firewall ou NAT e é muito difícil (eu diria “impossível”) de hackear a rede, pois a princípio não escuta a rede soquete.

Cobertura total de monitoramento

Agora, nossa regra é que aprendamos sobre todos os problemas técnicos com o okerr. Se de repente a regra for violada (okerr não avisou sobre sua ocorrência iminente (se isso for possível) ou que já ocorreu) - adicionamos verificações ao okerr.

Verificações externas

Um conjunto bastante típico:

sibilo
estado http
verificar a validade e atualização do certificado SSL (avisará se estiver prestes a expirar)
abra a porta TCP e coloque um banner nela
http grep (a página [não deve] conter texto específico)
hash sha1 para capturar alterações na página.
DNS (o registro DNS deve ter um valor específico)
WHOIS (avisará se o domínio estiver prestes a ficar ruim)
Antispam DNSBL (verificação do host em mais de 50 listas negras antispam de uma só vez)

Verificações internas

Além disso, um conjunto bastante padrão (mas facilmente expansível).

df (espaço livre em disco)
carga média
opentcp (soquetes de escuta TCP abertos - notificará se algo foi iniciado ou travou)
uptime - apenas tempo de atividade no servidor. Notificará se houve alteração (ou seja, o servidor está sobrecarregado)
cliente_ip
dirsize - usamos para rastrear quando os rootfs de nossa máquina virtual excedem o tamanho permitido, sem introduzir restrições estritas, e o tamanho dos diretórios iniciais dos usuários
vazio e não vazio - monitora arquivos que deveriam estar vazios (ou não vazios). Por exemplo, o log de erros do próprio servidor okerr deve estar vazio e, se houver pelo menos uma linha nele, receberei uma notificação e verificarei. Mas mail.log no servidor de email NÃO deve estar vazio (N minutos após a rotação). E às vezes ficava vazio para nós após uma atualização do sistema, quando o logrotate não conseguia reiniciar o rsyslog corretamente.
linecount - número de linhas no arquivo (como wc -l). Nós o usamos como um substituto mais suave para vazio, quando o log de erros ainda pode crescer, mas apenas lentamente (por exemplo, o Googlebot acessa algumas páginas fechadas). Há um limite de 2 linhas em 20 minutos. Se for maior, haverá um alerta

Verificações internas interessantes

Se você leu “diagonalmente” até agora, agora será mais interessante ler com mais atenção.

backups

Monitora backups no diretório. Nossos arquivos de backup têm nomes como “ServerName-20200530.tar.gz”. Para cada servidor no okerr, o indicador ServerName-DATE.tar.gz é criado (a data real muda para a linha “DATE”). A presença de um novo backup e seu tamanho também são monitorados (por exemplo, não pode ser inferior a 90% do backup anterior).

O que precisa ser feito para que um novo backup comece a ser rastreado depois de começarmos a criá-lo e colocá-lo neste diretório? Nada! Esta é uma abordagem muito conveniente quando você não precisa fazer “nada” porque:

Fazer “nada” é muito rápido, economiza tempo
É difícil esquecer de não fazer “nada”
É difícil não fazer “nada” de errado, com erro. Nada é o método mais confiável

Se de repente novos arquivos de backup pararem de aparecer, haverá um alerta. Se, por exemplo, você desativou um dos servidores e não deve haver mais backups, será necessário excluir o indicador (através da interface web ou do shell via API).

maxfilesz

Mantém o controle do tamanho dos arquivos maiores (normalmente: /var/log/*). Isso permite detectar problemas imprevisíveis, por exemplo, senhas de força bruta ou envio de spam pelo servidor.

status de execução/linha de execução

Estes são dois módulos proxy importantes para executar outros programas no servidor. Runstatus reporta o código de saída do programa ao indicador. Por exemplo, okerr não (requer) um módulo para verificar se os serviços do systemd estão em execução. Isso é feito via runstatus (veja abaixo). Runline - reporta ao servidor a linha que o programa produz. Por exemplo, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" na configuração do Runline em nosso servidor cria um indicador servername:temp com a temperatura do processador.

sql

Executa uma consulta numérica ao MySQL e reporta o resultado ao indicador. Em um caso simples, você pode fazer, por exemplo, “SELECT 1” - isso verificará se o SGBD como um todo está funcionando.

Mas uma aplicação muito mais interessante é, por exemplo, rastrear o número de pedidos em uma loja online. Se você sabe que tem 100 ou mais pedidos por hora, pode definir o limite mínimo para 100 ou 80. Então, se suas vendas caírem repentinamente, você receberá um alerta e poderá descobrir.

Observe que não importa por que motivo imprevisível isso aconteceu:

O servidor simplesmente está indisponível (desenergizado ou sem rede), e o alerta veio do fato do indicador estar “podre”.
O servidor está sobrecarregado com alguma coisa, funciona devagar ou perde pacotes, incomoda os usuários e eles saem sem fazer compras
O servidor está incluído nas listas de spam e os e-mails dele não são aceitos, os usuários não podem se registrar
O orçamento da campanha publicitária acabou, os banners não estão girando.

Pode haver uma série de razões e todas elas não podem ser previstas com antecedência e são tecnicamente difíceis de rastrear. Mas você pode monitorar convenientemente os parâmetros finais (pedidos) e determinar a partir deles que a situação é suspeita e merece ser tratada.

Indicadores lógicos

Permite o uso de expressões booleanas (sintaxe Python) através de um módulo avaliar(artigo sobre Habré). Os dados do projeto e seus indicadores estão disponíveis para expressão. Por exemplo, no capítulo sobre verificação de SQL acima, você deve ter notado um ponto fraco - durante o dia podemos ter 100 vendas por hora, mas à noite - 20, e isso é comum, não é um problema. O que devo fazer? O indicador entrará em pânico constantemente à noite.

Você pode criar dois indicadores, dia e noite. Deixe ambos “silenciosos” (eles não enviarão alertas). E crie um indicador lógico que exija que o indicador diurno esteja OK antes das 20h, e depois das 00h basta que o indicador noturno esteja OK.

Outro exemplo de uso de um indicador lógico é escalada. Por exemplo, um gerente de projeto cancela a assinatura de alertas (ele não precisa fazer isso, os administradores devem responder a problemas normais), mas assina um indicador lógico que fica vermelho se algum indicador do projeto não for corrigido dentro do tempo estipulado.

Além disso, é possível definir o horário permitido para o trabalho, por exemplo, das 3h às 5h. Não nos importamos se servidores e sites travarem durante esse período. Mas às 5h eles têm que trabalhar. Se não funcionarem em nenhum outro momento - alerta. O indicador lógico também permite levar em consideração a redundância do servidor. Se você tiver 00 servidores web, os administradores poderão desligar 5 ou 1 servidores a qualquer momento. Mas se houver menos de 2 dos 3 servidores em batalha, haverá um alerta.

Os exemplos acima não são funções ok, nem alguns recursos que precisam ser ativados e configurados. Okerra não possui todas essas funções, mas existe um módulo lógico que permite implementar essa funcionalidade (aproximadamente como em uma linguagem de programação - se tivermos operadores aritméticos, não precisamos de uma função especial para calcular o IVA de 20% do idioma, você sempre pode fazer isso sozinho, de acordo com suas necessidades).

O Logic Indicator é provavelmente um dos poucos tópicos relativamente complexos no okerr, mas a boa notícia é que você não precisa dominá-lo até que seja necessário. Mas, ao mesmo tempo, eles expandem bastante as capacidades, ao mesmo tempo que mantêm o sistema em si bastante simples.

Adicionando seus próprios cheques

Eu realmente gostaria de transmitir a ideia de que okerr não é um conjunto de milhares de cheques prontos para todas as ocasiões, mas pelo contrário - antes de tudo - um mecanismo simples com uma capacidade simples de criar seus próprios cheques. Criar suas próprias verificações no okerr não é uma tarefa para hackers, co-desenvolvedores de sistemas ou pelo menos usuários avançados do okerr, mas uma tarefa viável para qualquer administrador que instalou o Linux pela primeira vez há um mês.

A consulta do salário mínimo é feita por meio do módulo status de execução:

Esta linha na configuração status de execução irá notificá-lo se /bin/true de repente não iniciar ou retornar algo diferente de 0.

true_OK=/bin/true

Apenas uma linha - e aqui já estamos um pouco expandiram funcionalidade okerr.

Mesmo essa verificação já tem seu valor: se o seu servidor travar repentinamente, o indicador correspondente no servidor okerr não será atualizado em tempo hábil e, após o tempo passar, um alerta aparecerá.

Esta verificação irá notificar que o servidor Apache2 travou (bem, nunca se sabe...):

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

Portanto, se você fala alguma linguagem de programação e pelo menos consegue escrever scripts de shell, já pode adicionar suas próprias verificações.

Mais difícil - você pode escrever (em qualquer idioma) seu próprio módulo para okerrmod. No caso mais simples, fica assim:

#!/usr/bin/python3

print("STATUS: OK")

Não é muito difícil? O módulo deve fazer a verificação sozinho e enviar os resultados para STDOUT. Um módulo mais complexo fornece, 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

Atualiza vários indicadores ao mesmo tempo (separados por uma linha vazia), cria-os se necessário, indica detalhes de verificação e uma tag pela qual é fácil encontrar os indicadores necessários no dashboard.

Existe um bot do Telegram @OkerrBot. Você não precisa sobrecarregar seu telefone com aplicativos separados (não gosto que para Pyaterochka você precise de um aplicativo com um mapa, para Lenta outro, para MTS um terceiro e assim por diante para todos, todos, todos). Um telegrama é suficiente. Através do Telegram você pode receber alertas imediatamente, verificar o status do projeto e dar um comando para verificar novamente todos os indicadores problemáticos. Saímos do teatro/avião, não mantivemos o controle por duas horas, ligamos o telefone, apertamos um botão no chatbot e nos certificamos de que estava tudo bem.

Páginas de status

Hoje em dia, as páginas de status são quase obrigatórias para qualquer negócio que tenha TI, uma atitude responsável em relação à confiabilidade e que trate seus clientes/usuários com respeito.

Imagine uma situação: um usuário deseja fazer algo, visualizar informações ou fazer um pedido e algo não funciona. Ele não sabe o que está acontecendo, de que lado está o problema e quando será resolvido. Talvez sua empresa simplesmente tenha um site não funcional? Ou quebrou há seis meses e será consertado em dois anos? Mas você precisa comprar uma geladeira agora, já está no carrinho... E é completamente diferente quando uma pessoa vê que algo está errado com você (pelo menos fica claro que o problema não está do lado dela), que o o problema foi descoberto, que você já está trabalhando nele e talvez até anotou o tempo aproximado para correção. O usuário pode se inscrever e receber uma notificação por e-mail quando o problema for resolvido e ele poderá fazer o que quiser (comprar uma geladeira).

Problemas e tempo de inatividade acontecem com todos. Mas os utilizadores e parceiros confiam mais naqueles que são mais transparentes e responsáveis na sua abordagem a este assunto.

aqui é revisão de outros 10 projetos que permitem criar páginas de status. Aqui estão alguns exemplos da aparência dessas páginas do projeto Python и Dropbox. página de status do okerr.

Failover

Para não tornar este artigo ainda mais longo, voltarei mais uma vez ao meu artigo anterior - Failover simples para um site . Se você puder criar um servidor duplicado, usando o failover, basicamente não terá um longo tempo de inatividade - assim que um problema for detectado, os usuários serão automaticamente redirecionados para um servidor de backup em funcionamento. E me parece que esse é um recurso muito interessante e brilhante que raramente está disponível em qualquer lugar.

Baixos requisitos de sistema

Para servidores okerr, utilizamos máquinas com RAM a partir de 2Gb. Para sensores de rede, até 512 MB são suficientes. A parte do cliente geralmente é quase zero. (Saco de plástico okerrupdate pesa 26 Kb, mas requer Python3 e bibliotecas padrão). O cliente é executado a partir de um script cron, portanto, não tem consumo de memória persistente. Entre as máquinas que monitoramos, temos sensores (VPS superbarato com 512Mb de RAM) e um Raspberry Pi. É possível mesmo sem a parte do cliente enviar atualizações via curl! (Veja abaixo)

Levando isso em consideração - okerr, provavelmente mais grátis sistema de monitoramento dentre os disponíveis, pois mesmo para usar outro sistema open source gratuito como Zabbix ou Nagios, é necessário alocar recursos (servidor) para ele, e isso já é dinheiro. Além disso, ainda é necessária alguma manutenção no servidor. Com okerr, esta parte pode ser removida. Ou você não precisa removê-lo e usar seu próprio servidor, dependendo do que você mais gosta.

API e integração em software proprietário

Arquitetura simples e aberta. okerr tem um bem simples API, que é fácil de trabalhar. Precisa criar 1000 indicadores? Um script shell de 3-4 linhas fará isso. Precisa reconfigurar 1000 indicadores? Também é muito fácil. Por exemplo, queremos verificar novamente todos os nossos certificados HTTPS de um sensor russo:

#!/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

Você pode atualizar o indicador usando nosso módulo cliente, mesmo sem ele, apenas via 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/

Você pode atualizar os indicadores diretamente do seu programa. Por exemplo, enviar sinais de batimento cardíaco para que o okerr saiba que está em execução e acione um alarme se travar ou congelar. A propósito, os componentes do okerr fazem exatamente isso - o okerr monitora a si mesmo e problemas em quase todos os módulos serão detectados e gerarão um alerta sobre o problema. (E no caso deste “quase” - eles são verificados de outro servidor)

Aqui está o código (simplificado) em nosso bot de telegrama:

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 uma biblioteca para atualização de indicadores de programas Python okerrupdate, não há bibliotecas para qualquer outro idioma, mas você pode chamar o script okerrupdate ou fazer uma solicitação HTTP ao servidor okerr.

Como okerr nos ajuda

Okerr mudou nossas vidas. De fato. Talvez outro sistema de monitoramento pudesse fazer o mesmo, mas trabalhar com okerr é fácil e simples para nós e tem todas as funções que precisávamos (adicionamos o que não tinha). A propósito, se faltarem alguns recursos, pergunte e eu os adicionarei (não prometo, mas quero que o okerr seja o melhor sistema de monitoramento para projetos de pequeno e médio porte). Ou melhor ainda, adicione você mesmo - é fácil.

Conseguimos viver de acordo com o princípio “aprender sobre todos os problemas com o kerra”. Se de repente ocorrer um problema que não aprendemos com okerr, adicionamos uma verificação ao okerr. (neste caso, por “nós” quero dizer nós como usuários do sistema, não como co-desenvolvedores). No início isso era comum, mas agora se tornou muito raro.

Monitoramento

Através do okerr monitoramos os tamanhos dos logs em todos os servidores. É claro que é impossível ler atentamente cada linha do log com os olhos, mas simplesmente monitorar a taxa de crescimento já dá muito. Com isso, descobrimos correspondências de spam e pesquisas de senha de força bruta, e quando alguns dos aplicativos “enlouquecem”, algo não funciona para eles e eles repetem isso de novo e de novo (cada vez adicionando algumas linhas ao log ).

Certificados SSL. Quase imediatamente após o lançamento LetsEncrypt nosso cliente começou a fornecer certificados SSL gratuitos para seus clientes (cerca de mil deles). E acabou sendo um inferno para a administração! O fato é que os sites estão “ao vivo”, os clientes pedem periodicamente que façam alguma coisa, os programadores fazem. Eles podem transferir o site de forma totalmente gratuita para outro DocumentRoot, por exemplo. Ou adicione uma reescrita incondicional à configuração do virtualhost. Naturalmente, depois disso, a renovação automática dos certificados é interrompida. Agora temos todos os hosts SSL adicionados ao okerr automaticamente através de outro de nossos utilitários úteis do pacote a2conf. Vamos apenas lançar a2okerr.py — e se vários novos sites aparecerem no servidor, eles aparecerão automaticamente no okerr. Se de repente, por algum motivo, o certificado não for renovado, três semanas antes de o certificado expirar, estaremos sabendo e descobriremos por que ele não foi atualizado, que cachorro. a2certbot.py do mesmo pacote - ajuda muito nisso (verifica imediatamente os problemas mais prováveis - e escreve bem o que foi verificado e onde é mais provável que haja um problema).

Monitoramos a data de expiração de todos os nossos domínios. E todos os nossos servidores de e-mail que enviam e-mails também são verificados em mais de 50 listas negras diferentes. (E às vezes eles caem neles). A propósito, você sabia que os servidores de e-mail do Google também estão na lista negra? Apenas para autoteste, adicionamos mail-wr1-f54.google.com aos servidores monitorados e ainda está na lista negra do SORBS! (Trata-se do valor dos “anti-spammers”)

Backups - já escrevi acima como é fácil monitorá-los com okerr. Mas monitoramos os backups mais recentes em nosso servidor e (usando um utilitário separado que usa okerr) os backups que carregamos no Amazon Glacier. E, sim, problemas acontecem de vez em quando. Não admira que eles estivessem assistindo.

Usamos o indicador de escalonamento. Mostra se algum problema não foi resolvido há muito tempo. E eu mesmo, quando resolvo alguns problemas, às vezes posso esquecê-los. A escalada é um bom lembrete, mesmo se você estiver monitorando a si mesmo.

No geral, acredito que a qualidade do nosso trabalho aumentou em uma ordem de grandeza. Quase não há tempo de inatividade (ou o cliente não tem tempo para perceber. Apenas shh!), enquanto a quantidade de trabalho diminuiu e as condições de trabalho ficaram mais calmas. Passamos do trabalho emergencial com remendos de buracos com fita adesiva para um trabalho calmo e comedido, quando muitos problemas são previstos com antecedência e há tempo para evitá-los. Mesmo os problemas que aconteceram também se tornaram mais fáceis de resolver: em primeiro lugar, ficamos sabendo deles antes que os clientes entrem em pânico e, em segundo lugar, muitas vezes acontece que o problema está relacionado ao trabalho recente (enquanto eu fazia uma coisa, quebrei outra) - então está quente. É mais fácil para os rastros lidarem com isso.

Mas houve outro caso...

Você sabia que no popular Debian 9 (Stretch) um pacote tão popular como o phpmyadmin ainda está (por muitos meses!) no status vulnerável? (CVE-2019-6798). Quando a vulnerabilidade surgiu, rapidamente a abordamos de diferentes maneiras. Mas configurei o monitoramento da página do rastreador de segurança no okerr para saber quando uma solução “bonita” será lançada (por meio da soma SHA1 do conteúdo). O indicador me estremeceu várias vezes, a página mudou, mas como vocês podem ver, ainda (desde janeiro de 2019!) não indica que o problema foi resolvido. A propósito, talvez alguém saiba qual é o problema de um pacote tão importante ainda estar vulnerável por mais de um ano?

Outra vez em situação semelhante: após uma vulnerabilidade no SSH, foi necessário atualizar todos os servidores. E quando você define uma tarefa, você precisa controlar a execução. (Os subordinados tendem a entender mal, esquecer, ficar confusos e cometer erros). Portanto, primeiro adicionamos uma verificação de versão SSH ao okerr em todos os servidores e, por meio do okerr, garantimos que as atualizações fossem implementadas em todos os servidores. (Conveniente! Escolhi este tipo de indicador e você pode ver imediatamente qual servidor possui qual versão). Quando tivemos certeza de que a tarefa foi concluída em todos os servidores, removemos os indicadores.

Algumas vezes houve uma situação em que surge um determinado problema e depois desaparece por conta própria. (provavelmente familiar para todos?). Quando você percebe, quando você verifica – e não há nada para verificar – tudo já está funcionando bem. Mas então ele quebra novamente. Isso aconteceu, por exemplo, com produtos que carregamos no Amazon Marketplace (MWS). Em algum momento, o estoque carregado estava incorreto (quantidades erradas de mercadorias e preços errados). Nós descobrimos isso. Mas, para descobrir isso, era importante descobrir o problema imediatamente. Infelizmente, o MWS, como todos os serviços da Amazon, é um pouco lento, então sempre houve um atraso, mas ainda assim, conseguimos pelo menos entender aproximadamente a conexão entre o problema e os scripts que o causam (fizemos uma verificação, travamos para o okerr, e verifiquei imediatamente recebendo um alerta).

Um case interessante foi recentemente adicionado à coleção por um grande e caro hoster europeu, que nosso cliente usa. De repente, TODOS os nossos servidores desapareceram do radar! Primeiro, o próprio cliente (mais rápido que o okerra!) percebeu que o site com o qual ele trabalhava não estava abrindo e fez um ticket a respeito. Mas não apenas um site caiu, mas todos eles! (Natasha, largamos tudo!). Aqui Okerr começou a enviar longos envoltórios para os pés com todos os indicadores que acendiam para ele. Pânico, pânico, corremos em círculos (o que mais podemos fazer?). Então tudo subiu. Acontece que havia manutenção de rotina no data center (uma vez a cada muitos anos) e, claro, deveríamos ter sido avisados. Mas aconteceu algum tipo de problema com eles e não nos avisaram. Bem, mais ataques cardíacos, menos ataques cardíacos. Mas depois que tudo estiver restaurado, você precisa verificar tudo novamente! Não consigo imaginar como faria isso com as mãos. Okerr testou tudo em poucos minutos. Acontece que a maioria dos servidores estava simplesmente temporariamente indisponível, mas funcionava. Alguns estavam sobrecarregados, mas também se levantaram como deveriam. De todas as perdas, perdemos dois backups, que segundo a coroa deveriam ter sido criados e carregados enquanto acontecia essa banana cheia. Nem me preocupei em criá-los, apenas um dia depois chegaram alertas de que estava tudo bem, os backups haviam aparecido. Gosto muito deste exemplo porque o okerr acabou por ser muito útil numa situação que nem tínhamos pensado antecipadamente, mas esse é o propósito do acompanhamento - resistir ao imprevisível.

Para os sensores Okerr, usamos a hospedagem mais barata possível (onde qualidade e confiabilidade não são importantes, eles garantem um ao outro). Então, recentemente encontramos uma hospedagem muito boa e super barata, os benchmarks são demais. Mas... às vezes acontece que as conexões de saída da máquina virtual são feitas de outro IP (vizinho). Milagres. Módulo Client_ip com https://diagnostic.opendns.com/myip obtém o IP errado. E pelos logs do servidor do indicador fica claro que a atualização também veio desse IP vizinho. Vamos lidar com o suporte agora. É bom que tenhamos notado isso em tempos de paz. Mas, por exemplo, muitas vezes acontece que o acesso é registrado de acordo com a lista branca de IP - e se o servidor às vezes pisca assim por um curto período de tempo - você pode tentar detectar esse problema por muito tempo.

Bom, mais uma coisa – já que estamos falando de hospedagem VPS – sempre usamos hospedagem barata (hetzner, ovh, scaleway). Gosto muito dele tanto em termos de benchmarks quanto de estabilidade. Também usamos o Amazon EC2, muito mais caro, para outros projetos. Portanto, graças ao okerr, temos a nossa própria opinião informada. Ambos caem. E eu não diria que, durante o longo período de nossas observações, hospedagem barata como o hetzner acabou sendo visivelmente menos estável que o EC2. Portanto, se você não está vinculado a outros recursos da Amazon, por que pagar mais? 🙂

Qual é o próximo?

Se nesta fase eu ainda não assustei você de Okerr, então tente! Você pode ir diretamente para este link conta de demonstração okerr (Clique agora!) Mas lembre-se de que existe apenas uma conta demo para todos, portanto, se você fizer algo, outra pessoa na mesma conta poderá interferir com você ao mesmo tempo. Ou (melhor) cadastre-se através do link para okerr externo - tudo é simples, sem SMS. Se você não gosta de usar seu e-mail real, você pode usar um descartável, como o mailinator (recomendo getnada. com). Essas contas podem ser excluídas com o tempo, mas poderão ser testadas.

Após o registro, você será solicitado a realizar um treinamento (realizar várias tarefas de treinamento não muito difíceis). Os limites iniciais são muito pequenos, mas para treinamento ou um servidor são suficientes. Após a conclusão do treinamento, os limites (por exemplo, o número máximo de indicadores) serão aumentados.

Da documentação - em primeiro lugar WIKI no lado do servidor e no cliente (wiki okerrupdate). Mas se algo não estiver claro, escreva para support (at) okerr.com ou deixe um ticket - tentaremos resolver tudo rapidamente.

Se você usa isso a sério e esses limites aumentados não são suficientes, escreva para o suporte e nós aumentaremos (de graça).

Gostaria de instalar o servidor okerr no seu servidor? Aqui repositório okerr-dev. Recomendamos a instalação em uma máquina virtual limpa, então você pode simplesmente fazer isso com um script de instalação. Na sua máquina virtual - sem restrições :-). Bem, novamente, se acontecer alguma coisa, sempre tentaremos ajudar.

Queremos que este projeto decole, para que o mundo se torne mais confiável graças a nós. Graças ao software e aos serviços gratuitos, o mundo tornou-se mais amigável e está a desenvolver-se de forma mais dinâmica. As fontes podem ser armazenadas no github gratuito; para e-mail, você pode usar o Gmail gratuito. Nós usamos gratuitamente freshworks para suporte. Para nada disso, você não precisa pagar por servidores, não precisa baixar e configurar e não precisa resolver vários problemas operacionais. Cada novo projeto, cada equipe possui imediatamente mail, repositórios e CRM. E tudo isso é de altíssima qualidade, gratuito e imediato. Queremos que seja o mesmo para o monitoramento - pequenas empresas e projetos poderiam usar o okerr gratuitamente e mesmo na fase de nascimento e crescimento ter a confiabilidade de projetos sérios para adultos.

Fonte: habr.com

Visão geral do sistema de monitoramento híbrido Okerr