🥇Como escrevi meu monitoramento

Decidi compartilhar minha história. Pode até ser que alguém encontre útil essa solução orçamentária para um problema bem conhecido.

Quando eu era jovem e cheio de energia, não sabia onde direcioná-la, então decidi fazer um pouco de freelancing. Consegui rapidamente aumentar minha reputação e encontrei alguns clientes fixos que solicitaram meu suporte para gerenciar seus servidores de forma contínua.

A primeira coisa que pensei foi na necessidade de monitoramento. Decidi fazer como as pessoas inteligentes, não inventar a roda e olhar opções prontas, como Munin ou Zabbix. Mas logo percebi que a versão Web requer uma boa conexão à internet, especialmente ao abrir pela primeira vez no celular. Se você está relaxando na natureza, longe da cidade, é difícil conseguir uma conexão estável. Portanto, escolhi a opção de monitoramento via console.

Para monitoramento via console, o atop e o programa para leitura de logs do atop — atopsar — me ajudaram bastante. Eles já foram mencionados no habr, o atop foi até analisado, mas quase nada foi dito sobre o atopsar.

Instalação

Instalação muito simples, apenas três comandos.

#Centos

yum install atop

#Debian/Ubuntu

apt-get install atop

Depois posso configurar o monitoramento de acordo com as minhas necessidades ou usar as configurações padrão.

#Debian/Ubuntu/Centos

/etc/default/atop

Arquivo padrão:

 #cat /etc/default/atop
INTERVAL=60                    #Время, через которое создаётся снимок нагрузки в секундах, по умолчанию каждые 10 минут
LOGPATH="/var/log/atop"        #Путь до папки хранения логов
OUTFILE="$LOGPATH/daily.log"   #Название файла логов за сегодняшний день

Adicionando ao autostart
#Debian/Ubuntu/Centos

systemctl enable atop

Iniciando o atop como um daemon
#Debian/Ubuntu/Centos

systemctl start atop

Para os preguiçosos, compilei em um único comando
#Centos

yum install atop && systemctl enable atop && systemctl start atop

#Debian/Ubuntu

apt-get install atop && systemctl enable atop && systemctl start atop

Atopsar

Junto com o atop, também é instalado o atopsar, que é um analisador de logs binários em console conveniente, mantido pelo daemon atop. Claro, você pode ler os logs também com o próprio atop, mas não é tão prático se você precisa capturar um longo intervalo de tempo.

Um pequeno guia sobre como usar o atopsar.

Ao iniciar o atopsar sem chaves, abre o log do dia atual e exibe a carga em cada núcleo separadamente e a linha idl para todos os núcleos.

As chaves que uso:

-A = exibir todas as informações do log
-c = exibir informações sobre a carga dos núcleos do processador, chave padrão
-m = carga da memória e swap
-d = atividade do disco
-O = top-3 processos com carga no CPU
-G = top-3 processos com carga na RAM
-D = top-3 processos com carga no disco
-N = top-3 processos com carga na rede
-r = especificar o caminho do log que você deseja ler, se precisar ver a carga nos dias anteriores
-b = tempo a partir do qual começar a exibir
-e = hora em que deve ser finalizada a saída
-M = cria uma coluna adicional no final, onde é marcada a criticidade da linha (+ há carga, * — carga crítica)

Com a monitorização, podemos entender a razão do comportamento incorreto do servidor a qualquer momento.

Notificações

Portanto, a monitorização da carga existe, mas ainda assim não permite encontrar e resolver problemas rapidamente. Precisamos de notificações sobre quaisquer problemas que surgirem.

Eu sou o único que monitora os servidores, então é necessário notificar onde eu sempre poderei ver e reagir de alguma forma.

No início, havia SMS — rápido, confiável, gratuito. Mas depois, os operadores móveis fecharam o envio gratuito de SMS através de seus gateways.
E-mail — demora, podem haver problemas de entrega.
Mensageiros — é necessário instalar no telefone, é preciso criar bots.

Como resultado da pesquisa, o mensageiro Telegram foi escolhido pela sua simplicidade e pelo aplicativo conveniente para telefone e desktop.

Criei meu bot com a ajuda do botfather.
Depois, coloquei no servidor alguns scripts que monitoram a carga do servidor (IDL, smartct e outros), a presença de erros do tipo "oom killer", erros ao criar backups e outras operações que precisam ser controladas.

Os scripts são bastante simples, escritos em bash; por exemplo, verificação de LA e notificação sobre o excesso de Load Average em relação ao número de núcleos em servidor.

if [ ${LA[0]} -gt 2000 ] || [ ${LA[1]} -gt 3000 ] || [ ${LA[2]} -gt 4000 ]
    then
        wget -O /dev/null "https://api.telegram.org/$bot_id:$bot_key/sendMessage?chat_id=$chat_id&text=No servidor $ip LA $LAd"
        wget -O /dev/null "https://api.telegram.org/$bot_id:$bot_key/sendMessage?chat_id=$chat_id&text=`top -b -n 1 | grep Cpu`"
        wget -O /dev/null "https://api.telegram.org/$bot_id:$bot_key/sendMessage?chat_id=$chat_id&text=Top 5 processos `top -b -n 1 | grep -A 5 'PID USER' | tail -5`"
    fi

A simplicidade da sintaxe oferece muitas opções de uso (qualquer um que tenha um mínimo de conhecimento da linguagem de programação pode escrever/adicionar).

A única ressalva — se o servidor estiver na Rússia (e você não tiver IPv6 no servidor), será necessário usar um proxy. Para isso, no início do script, deve-se especificar a linha de conexão ao proxy:

export https_proxy=http://login:senha@IP.endereço:porta

Isso não é o fim

Você está caminhando pelas montanhas com uma mochila nas costas, desfrutando de uma pausa da civilização, e de repente, seu telefone, capturando uma conexão, recebe uma notificação sobre um problema no seu servidor. O que fazer? O estado de paz foi varrido como pelo vento. Ligaria para a esposa e ditaria os comandos? Haha!

Era urgente pensar em uma forma de resolver os problemas rapidamente e sem uma boa conexão de internet. Aqui, mais uma vez, o mensageiro (#TelegramViva) me salvou. Ensinei meu bot a se comunicar apenas comigo, ignorando todos os outros. Agora, juntamente com a notificação sobre o problema, recebo um pouco mais de dados, que me ajudam a entender a fonte do problema e tentar resolvê-lo remotamente. Basta enviar uma mensagem para o bot, levantar o telefone um pouco mais alto para que a mensagem seja enviada, e voilà — o bot vai fazer seu trabalho. Assim, posso, por exemplo, encerrar um processo indesejado, reiniciar um daemon, bloquear um IP e muito mais.

Aqui também transferi solicitações futuras necessárias de clientes, como redefinição urgente de senhas para usuários (porque “Aaaargh, não conseguimos acessar o servidor, estamos perdendo milhões!”), busca de um usuário com acesso a uma pasta específica, ativação e desativação do site, entre outras. Claro que estou sempre aprimorando a funcionalidade do bot, já que a criatividade dos clientes às vezes traz pedidos inesperados que não havia planejado. Mas os principais estão satisfeitos.

Há também uma versão para VK, mas ela não se espalhou muito.

Agora viajo tranquilamente e exploro este mundo, sem medo de que algo quebre e eu não consiga descobrir ou consertar.

Fonte: habr.com