Às vezes, você precisa monitorar rapidamente um novo serviço, mas não há infraestrutura / experiência pronta em mãos. Neste guia, em meia hora, implementaremos uma ferramenta para monitorar qualquer serviço da Web usando apenas as ferramentas internas do ubuntu: bash, cron e curl. Usaremos o telegrama para enviar alertas.
"Cherry on the cake" será o envolvimento emocional dos usuários. É verificado nas pessoas - funciona.
Quando criamos um chatbot no serviço de telemedicina Doctor Near para determinar o nível de estresse do usuário, precisávamos de monitoramento. Em algumas horas, foi feito um miniprojeto, que não apenas funciona muito bem, mas também adiciona um feedback positivo.
Para começar, obtenha um repositório com scripts:
git clone https://github.com/rshekhovtsov/msms.git
Vá para a pasta msms e trabalhe nela.
Se o telegrama estiver bloqueado, use um proxy. A opção mais fácil e mais confiável é a torção:
sudo apt install tor sudo apt install torsocks
Como exemplo, configuraremos o monitoramento da página inicial do google.com em três etapas.
PASSO 1. Crie um bot no telegrama e obtenha o ID do usuário
Para adicionar um novo destinatário, você precisa solicitar que ele inicie o bot no telegrama, execute recipients-setup.sh e adicione o ID ao arquivo.
PASSO 2. Configure o monitoramento
A descrição do serviço ocorre criando um arquivo ini na pasta de serviços. Cinco parâmetros precisam ser definidos:
- MSMS_SERVICE_NAME : nome do serviço - será usado em alertas e logs de monitoramento.
- MSMS_SERVICE_ENDPOINT : o ponto final do serviço em que entraremos em contato com o curl.
- MSMS_CURL_PARAMS : parâmetros de curvatura adicionais, veja o exemplo abaixo.
- MSMS_EXPECTED : resposta esperada do serviço. Utilizado se a resposta for curta.
- MSMS_EXPECTED_FILE : nome do arquivo com a resposta esperada do serviço. Se especificado, substitui MSMS_EXPECTED.
- MSMS_RECIPIENTS : arquivo com uma lista de destinatários da notificação.
A solicitação no google.com retorna um html fixo com um redirecionamento; vamos usá-lo como a resposta esperada do servidor:
curl google.com > services/google-response.html
Crie o arquivo services / google.ini:
MSMS_SERVICE_NAME='google front page'
No
MSMS_CURL_PARAMS você pode especificar tudo o que a ondulação pode fazer, incluindo:
- Desative as mensagens de ondulação para não entupir o console e registrar:
-s - Defina o tempo limite da conexão com o serviço que está sendo verificado (em segundos):
--connect-timeout 3 - Definir tempo limite da resposta:
-m 7 - Desabilite a verificação de certificado para SSL (por exemplo, se um certificado autoassinado for usado):
--insecure - Especifique o tipo de solicitação http:
-X POST - Especifique os cabeçalhos:
-H "Content-Type: application/json" - Especifique o corpo da solicitação como uma sequência ou arquivo. Exemplo para o arquivo:
-d @request.json
Desativamos as notificações e definimos o tempo limite de 3 segundos. em conexão e 7 seg. para receber uma resposta do serviço.
Atenção : especifique os valores dos parâmetros entre aspas simples, como no exemplo. Infelizmente, o bash nesse sentido é bastante frágil e uma
borboleta acidentalmente voada no lugar errado, uma citação, pode levar à
morte do universo com erros difíceis de diagnosticar.
Montamos o monitoramento. Verifique se está tudo bem:
sudo chmod +x ./monitoring.sh torsocks ./monitoring.sh
O script deve exibir uma mensagem do formulário:
2020-01-10 12:14:31 health-check "google front page": OK
PASSO 3. Ajuste a programação
Configure um agendamento de monitoramento no cron:
sudo crontab -e
Adicione uma linha para verificar google.com a cada minuto:
*/1 * * * * torsocks < >/monitoring.sh >> < >/monitoring.log 2>&1
Adicione um alerta todos os dias às 11h00, confirmando o próprio monitoramento. Para fazer isso, passe o parâmetro DAILY para o script:
0 11 * * * torsocks < >/monitoring.sh DAILY >> < >/monitoring.log 2>&1
2>&1 - técnica padrão que redireciona erros para o fluxo de saída principal. Como resultado, eles também serão incluídos no log de monitoramento.
Salve as alterações e capture-as com o comando:
sudo service cron reload
Você pode ler mais sobre como configurar o cron, por exemplo,
aqui .
Assim, a cada minuto, um script de monitoramento será lançado, que será acessado via gol no google.com.br. Se a resposta recebida for diferente da esperada, o script enviará uma notificação no telegrama à lista de destinatários. O log de auditoria é mantido no arquivo Monitoring.log
Se você precisar adicionar outro serviço, simplesmente criamos um novo arquivo ini para ele na pasta services e, se necessário, criamos uma lista separada de destinatários. Todo o resto funcionará automaticamente.
Se o serviço verificado ficar indisponível, um alerta será enviado a cada minuto. Se você não conseguir restaurar rapidamente o serviço, poderá desativar temporariamente as notificações nas propriedades do bot no telegrama.
Agora, vamos dar uma olhada nos recursos adicionais e na implementação de scripts.
Modelos de mensagens e envolvimento emocional
Para tornar a comunicação com o bot mais animada, chamamos Manechka, adicionamos o avatar de imagem correspondente e especialistas em relações públicas profissionais engajados para criar textos de mensagens. Você pode usar nossas realizações ou mudar a seu gosto.
Por exemplo, assim:
ou mesmo assim:
Porque não
O nome e o avatar do bot são definidos via
@botfather .
Os modelos de mensagens estão localizados na pasta de
modelos :
- curl-fail.txt : mensagem enviada quando curl retornou um código de erro diferente de zero. Geralmente fala da impossibilidade de entrar em contato com o serviço.
- daily.txt : mensagem diária confirmando que o monitoramento de serviço está funcionando.
- service-fail.txt : mensagem enviada quando a resposta do serviço é diferente do esperado.
Vamos examinar as possibilidades de personalização usando o exemplo de modelos de mensagens internos.
Os modelos usam emojis. Infelizmente, o habr não os exibe.
Para selecionar emojis, é conveniente usar a pesquisa em
emojipedia.org :
Você simplesmente copia e cola o caractere apropriado no texto do modelo (este é o unicode usual).
- curl-fail.txt:
, ... \"$MSMS_SERVICE_NAME\" \`CURL EXIT CODE: $EXIT_CODE\`
Usamos o nome do serviço especificado (variável MSMS_SERVICE_NAME ) e a variável de script interna com o código de terminação de ondulação ( EXIT_CODE ). Também formatamos a mensagem usando a marcação de marcação de telegrama : os caracteres `` '' enquadram o texto de largura fixa. Como aspas e apóstrofes são caracteres oficiais do bash, nós os escapamos com o caractere "\". Os nomes de variáveis são precedidos por um sinal "$".
Resultado:
- service-fail.txt:
, ... \"$MSMS_SERVICE_NAME\" , : \`$RESPONSE\`
Resultado:
Aqui usamos outra variável de script: RESPONSE . Ele contém a resposta do serviço.
- daily.txt:
, ! , c : \"$MSMS_SERVICE_NAME\" ... ?
Resultado:
Vamos seguir para a implementação de scripts.
Script de monitoramento
Monitoring.sh faz a descoberta automática simples - pega todos os arquivos ini da pasta services e para cada um deles executa o script principal com a lógica para verificar e enviar alertas:
Para gerar uma mensagem diária sobre o status de monitoramento, o script pode receber o parâmetro DAILY.
Observe que, quando o script é iniciado, a pasta atual muda para serviços. Isso permite que os arquivos ini especifiquem caminhos de arquivo relativos aos serviços.
Script para verificar e enviar alertas
msms.sh contém a lógica básica de verificar um serviço e enviar alertas.
Trabalhar com telegrama:
Criamos um URL para acessar a API REST do telegrama usando a chave privada armazenada no arquivo.
A função send_message usa curl para enviar mensagens para essa API REST, utilizando o ID do destinatário do arquivo especificado em ini. Nos dados que enviamos, indicamos que usamos marcação de mensagem:
parse_mode="Markdown" .
Imprima a data atual e carregue o arquivo ini.
echo $(date '+%Y-%m-%d %H:%M:%S')
A linha mágica
. $2 . $2 executa o arquivo ini passado como o segundo parâmetro como um script comum, inserindo os valores especificados nele nas variáveis de ambiente.
Faça o download da resposta esperada do arquivo se o parâmetro
MSMS_EXPECTED_FILE estiver
MSMS_EXPECTED_FILE :
if [ -n "$MSMS_EXPECTED_FILE" ]; then MSMS_EXPECTED="$(cat "$MSMS_EXPECTED_FILE")" fi
Execute uma verificação de serviço enviando alertas, se necessário:
RESPONSE="$(eval curl $MSMS_CURL_PARAMS \"$MSMS_SERVICE_ENDPOINT\")" EXIT_CODE=$? if [[ $EXIT_CODE != 0 ]]; then echo health-check \"$MSMS_SERVICE_NAME\" FAILED: CURL EXIT WITH $EXIT_CODE MESSAGE="$(cat ../templates/curl-fail.txt)" MESSAGE=$(eval echo $MESSAGE) send_message "$MESSAGE" elif [[ "$RESPONSE" != "$MSMS_EXPECTED" ]]; then echo health-check \"$MSMS_SERVICE_NAME\" FAILED: "$RESPONSE" MESSAGE="$(cat ../templates/service-fail.txt)" MESSAGE=$(eval echo $MESSAGE) send_message "$MESSAGE" else echo health-check \"$MSMS_SERVICE_NAME\": OK fi
Primeiro, atribuímos a variável
RESPONSE ao resultado do comando curl desse serviço.
Expressão
EXIT_CODE=$? coloca o resultado do último comando, ou seja, enrolar. Se você precisar enviar um alerta, o modelo será lido no arquivo correspondente e a correspondência para os destinatários será
send_message usando o
send_message .
O último bloco processa o parâmetro DAILY:
if test "$1" = "DAILY"; then echo health-check \"$MSMS_SERVICE_NAME\" DAILY MESSAGE="$(cat ../templates/daily.txt)" MESSAGE=$(eval echo $MESSAGE) send_message "$MESSAGE" fi
Ele envia uma mensagem confirmando a integridade do próprio monitoramento.
Obtendo uma lista do ID do usuário
recipients-setup.sh chama a API do telegrama para obter as últimas mensagens endereçadas ao bot:
curl -s https://api.telegram.org/bot$(cat telegram-api-key.txt)/getUpdates \ | python recipients-setup.py
Ele usa a magia python para listar bem a saída. Isso é opcional, você pode simplesmente pegar o id desejado do json, que o comando emitirá:
torsocks curl -s https://api.telegram.org/bot$(cat telegram-api-key.txt)/getUpdates
Conclusão
Assim, você pode usar scripts prontos e modelos de mensagens, configurando apenas serviços e listas observáveis para notificações; Você pode criar uma nova "identidade" para o bot; e você pode tomar sua decisão com base no proposto.
Como opções para desenvolvimento adicional, a configuração e o gerenciamento do monitoramento no próprio bot se sugerem, mas aqui você não pode prescindir do python. Se alguém colocar as mãos na minha frente - você sabe onde enviar a solicitação pull :-)