Como simplesmente monitorar o status do site

Para monitorar remotamente o desempenho dos servidores, os profissionais usam sistemas de software especiais, como Zabbix ou Icinga . Porém, se você é proprietário ou administrador iniciante de um ou dois sites com uma carga pequena, não há necessidade de grandes sistemas de monitoramento. O principal parâmetro é se o site atende rapidamente aos usuários. Portanto, você pode monitorar o trabalho do site usando um programa simples de qualquer computador conectado à Internet.



Vamos escrever esse script agora - o monitoramento mais simples da disponibilidade e velocidade do site. Este programa pode ser executado em um computador doméstico, smartphone e assim por diante. O programa tem apenas duas funções:

• mostra na tela o tempo durante o qual seu site fornece páginas aos usuários,
• no caso de respostas lentas do site ou erros, o programa grava dados em um arquivo (um “log” ou um arquivo de log). Vale a pena verificar esses dados periodicamente para corrigir problemas quando eles estão apenas começando. Portanto, teremos o cuidado de registrar esses logs em um formulário claro e conveniente para visualização rápida.

Descreverei cada etapa em detalhes para que até mesmo um iniciante familiarizado com a gravação de arquivos em lotes (bat e cmd no DOS e Windows, sh em sistemas como o UNIX) possa descobrir isso sem problemas e adaptar o script às suas necessidades. Mas peço que você não use esse script sem pensar, porque se usado incorretamente, ele pode não fornecer resultados adequados e, além disso, absorver muito tráfego .

Descreverei um script para um sistema operacional como o Linux e seu uso em um computador doméstico. Pelos mesmos princípios, isso pode ser feito em outras plataformas. E para aqueles que estão apenas olhando para as possibilidades do Linux, mais um exemplo pode ser interessante: que ferramenta simples e poderosa são seus scripts.

1. Organização primeiro

Vamos criar uma pasta separada para este programa e criar 3 arquivos nele. Por exemplo, eu tenho esta pasta / home / me / Progs / iNet / monitor (aqui me é o nome do meu usuário, Progs / iNet é a minha pasta para programas relacionados à Internet e monitor é o nome desse programa, a partir da palavra monitor, ou seja, Como sou o único usuário deste computador, mantenho esses arquivos entre minhas pastas pessoais (/ home) em uma seção separada do disco, o que me permite salvá-los ao reinstalar o sistema. Nesta pasta, haverá arquivos:

• README.txt - aqui está uma descrição (em caso de esclerose): que tipo de programa, informações básicas, etc.
• mon.sh - haverá um programa que pesquisa o site.
• server.log - aqui ele gravará indicadores de status do site. No nosso caso, essa é simplesmente a data, hora e duração da resposta do site (além de informações adicionais se o servidor responder com um erro com nossa solicitação).

(Para a conveniência de editar e, se houver, restaurar arquivos, você pode incluir esta pasta no sistema de controle de versão do Git; aqui não vou descrevê-la).

2. Persistentemente e relaxado

Executaremos o arquivo mon.sh com um pequeno intervalo regular, por exemplo, 60 segundos. Usei a ferramenta padrão fornecida pelo sistema operacional (mais precisamente, o ambiente da área de trabalho).

Meu ambiente de área de trabalho é o Xfce. Esta é uma das opções mais populares para Linux. Gosto do Xfce porque permite personalizar quase completamente todo o ambiente - do jeito que você gosta. Ao mesmo tempo, o Xfce é um pouco mais compacto e mais rápido que dois outros sistemas conhecidos - Gnome e KDE. (Outras opções também são interessantes - por exemplo, o ambiente LXDE é ainda mais rápido e fácil que o Xfce, mas até agora não é tão rico em recursos).

A ferramenta de que precisamos, no caso do Xfce, é um plug-in para o painel de trabalho do Generic Monitor. Normalmente, ele já está instalado, mas, se não, o Instalador o encontrará facilmente: “Genmon” (descrição: xfce4-genmon-plugin ). Este é um plugin que pode ser adicionado ao painel e definido nas configurações: (1) o comando a ser executado e (2) a frequência de sua execução em segundos. No meu caso, o comando:

/home/me/Progs/iNet/monitor/mon.sh

(ou, equivalentemente, ~ / Progs / iNet / monitor / mon.sh).

3. Quando o programa ainda não existe, já existem erros

Se você concluiu todas essas etapas agora - criou arquivos e iniciou o plug-in no painel -, verá o resultado do lançamento do nosso programa lá (mensagem de erro: o arquivo mon.sh não é um programa). Em seguida, para tornar o arquivo executável, acesse nossa pasta e defina a permissão para executar -

• ou gerenciador de arquivos: Propriedades - Permissões - Permite que este arquivo seja executado como um programa;
• ou um comando do terminal: chmod 755 mon.sh

E no próprio arquivo, escrevemos as primeiras linhas:

#!/bin/bash # Monitor server responses (run this every 60 seconds): # info=$(curl -I -o /dev/stdout -w '%{time_total}' --url https://example.ru/ -m 9 -s) errr=$(echo $?) 

Em vez de "example.ru", substitua o nome do seu site, cujo estado você observará. E se funcionar em http, coloque http em vez de https. A linha #! / Bin / bash significa que este é um script a ser iniciado pelo programa Bash (o bash é provavelmente o mais comum para a execução de scripts no Linux). Para trabalhar com outro shell, é indicado em vez do Bash. As linhas restantes com uma acentuada no início são comentários. A primeira linha de código em si é info = $ () e, entre parênteses, é o comando curl com parâmetros. Tal construção - algo = $ (algo) - significa "executar o comando entre colchetes e atribuir o resultado à variável à esquerda". Nesse caso, chamei a variável "info". Este comando entre colchetes - curl (no jargão referido por alguns como "Kurl") - envia uma solicitação para a rede no endereço especificado e retorna a resposta do servidor. (Meu conhecido disse, explicando: "Como o guindaste resmunga - e recebe uma resposta de outro guindaste no céu".) Considere as opções:

 curl -I -o /dev/stdout -w '%{time_total}' --url https://example.ru/ -m 9 -s 

-I significa que não solicitamos a página inteira, mas apenas seus "cabeçalhos HTTP". Toda vez que não precisamos do texto completo da página para garantir que o site esteja funcionando. Como verificaremos o site com frequência, é importante tornar o tamanho dos dados transmitidos o menor possível. Isso economiza tráfego, eletricidade e carga no servidor - e vida selvagem.

A propósito, preste atenção à quantidade de tráfego disponível (não utilizado por mês) na hospedagem. Abaixo, você verá a quantidade de dados transmitidos e poderá calcular se possui reservas suficientes; se houver, o período de verificação do site pode ser aumentado para 5, 10 ou até 30 a 60 minutos. Embora neste caso a imagem não seja tão completa - e pequenas interrupções podem passar despercebidas; mas, em geral, ao monitorar um site, é mais importante detectar problemas de longo prazo do que uma única interrupção. Além disso, qual tráfego você pode pagar no computador que está chamando? No meu caso - um PC de mesa com tráfego ilimitado - isso não é tão importante; mas para um dispositivo móvel ou tarifa com limites, vale a pena calcular e, possivelmente, aumentar os intervalos de inspeção.

4. O passo segue o passo, exceto o primeiro passo

Vamos além: -o / dev / stdout significa "enviar a resposta recebida pelo Kurl do servidor para tal e tal arquivo". E, neste caso, este não é um arquivo no disco, mas / dev / stdout - dispositivo de saída padrão. Normalmente, o "dispositivo de saída padrão" é a nossa tela, onde podemos ver os resultados do programa. Porém, no script, geralmente direcionamos essa "saída padrão" para processamento adicional (agora - salve-a na variável info). E então, na maioria das vezes, enviamos os resultados das equipes para variáveis ​​ou os passamos para as próximas equipes em uma cadeia. Para criar cadeias a partir de comandos, use o operador de tubulação ("Tubulação"), exibido como uma barra vertical ("|").

-w '% {time_total} eyayu' : aqui -w significa "formatar e fornecer essas e outras informações adicionais a um dispositivo de saída padrão". Especificamente, estamos interessados ​​em time_total - quanto tempo a transmissão de solicitação-resposta entre nós e o servidor levou. Você provavelmente sabe que existe um comando mais simples, o ping, para solicitar rapidamente um servidor e obter uma resposta dele, pong. Mas o Ping verifica apenas se o servidor de hospedagem está ativo e o sinal vai e volta por tanto tempo. Isso mostra a velocidade máxima de acesso, mas ainda não nos diz nada sobre a rapidez com que o site produz conteúdo real. O ping pode funcionar rapidamente e, ao mesmo tempo, o site pode ficar lento ou não funcionar - devido a alta carga ou a alguns problemas internos. Portanto, usamos exatamente o Kurla e obtemos o tempo real em que o servidor exibe nosso conteúdo.

(E por esse parâmetro, você pode avaliar se o servidor está funcionando com eficiência para suas tarefas, se o tempo de resposta típico é conveniente para os usuários. Existem problemas - por exemplo, meus sites em muitos sites de hospedagem diminuíram com o tempo e eu tive que procurar outra hospedagem).

Você notou as letras estranhas "eyu" depois de {time_total}? Eu os adicionei como um rótulo exclusivo, que provavelmente não estará nos cabeçalhos enviados a nós pelo servidor (embora faça suposições sobre o que seus usuários terão ou não terão, é uma má forma e o caminho para o abismo. Não faça isso! .. Ou, quando você faz , pelo menos tenha vergonha de você). Por esse rótulo (espero), podemos facilmente extrair as informações necessárias de um monte de linhas na variável info. Portanto, curl -w '% {time_total} ehayu' (com os demais parâmetros corretos) nos dará algo como:

0.215238eyayu

Este é o número de segundos que levou para acessar o site, além de nosso rótulo. (Além deste parâmetro, na variável info, estaremos interessados ​​principalmente no "Código de status" - o código de status ou, simplesmente, o código de resposta do servidor. Geralmente, quando o servidor emite o arquivo solicitado, o código é "200". Quando a página não é encontrada , esse é o famoso 404. Quando há erros no servidor, geralmente é 500 com alguma coisa).

5. Criatividade - o pai do autoteste

Os demais parâmetros de nossa curvatura são os seguintes:

 --url https://example.ru/ -m 9 -s 

o que significa: solicitar tal endereço; o tempo máximo de resposta é de 9 segundos (você pode definir menos, porque um usuário raro aguardará uma resposta do site por tanto tempo, ele rapidamente descobrirá que o site não está funcionando). E "-s" significa silencioso, ou seja, curl não nos fornece detalhes desnecessários.

A propósito, geralmente não há muito espaço no painel da área de trabalho; portanto, para depurar um script, é melhor executá-lo a partir do terminal (em sua pasta, usando o comando ./mon.sh). E para o plug-in do painel, colocaremos uma longa pausa entre os lançamentos do comando - digamos, 3600 segundos.

Para depuração, podemos executar essa curvatura sem colchetes e ver o que ela produz. (A partir disso e calcular o consumo de tráfego). Veremos principalmente um conjunto de cabeçalhos HTTP, como:

 HTTP/1.1 302 Found Server: QRATOR Date: Sun, 11 Feb 2019 08:06:57 GMT Content-Type: text/html; charset=UTF-8 Connection: keep-alive Keep-Alive: timeout=15 X-Powered-By: PHP/7.2.14-1+ubuntu16.04.1+deb.sury.org+1 Location: https://habr.com/ru/ X-Frame-Options: SAMEORIGIN X-Content-Type-Options: nosniff Strict-Transport-Security: max-age=63072000; includeSubDomains; preload X-Cache-Status: HIT 0.033113 

A primeira linha aqui vemos "HTTP / 1.1 302 encontrado" - o que significa: o protocolo de transferência de dados é "HTTP / 1.1", o código de resposta do servidor é "302 encontrado". Ao solicitar outra página, pode ser o código "301 movido permanentemente" etc. Em outro exemplo, a resposta normal do meu servidor é "HTTP / 2 200". Se o seu servidor normalmente responde de maneira diferente, substitua-o por "resposta / 200" neste script.

A última linha, como vemos, Kurl fornece, em quantos segundos recebemos a resposta do servidor, com nosso rótulo atribuído.

Interessante: podemos configurar o site para que ele relate nossos pedidos (e somente neles!) Informações adicionais sobre seu estado - por exemplo, no cabeçalho HTTP "caseiro". Digamos qual é a carga nos processadores do site, quanta memória livre e espaço em disco ele possui e com que rapidez o banco de dados está funcionando. (Obviamente, para isso, o site deve ser dinâmico, ou seja, as solicitações devem ser processadas pelo programa - em PHP, Node.JS, etc. Outra opção é usar software especial no servidor). Mas talvez ainda não precisemos desses detalhes. O objetivo deste script é simplesmente monitorar regularmente o desempenho geral do site. Em caso de problemas - já trataremos do diagnóstico por outros meios. Portanto, agora estamos escrevendo o script mais simples que funcionará para qualquer site, mesmo estático, e sem configurações adicionais no servidor. No futuro, se desejado, será possível expandir os recursos do script; Enquanto isso, faça a base.

A string errr = $ (eco $?) Significa: escreva o resultado do comando “echo $?” Na variável errr. O comando echo significa imprimir algum texto no dispositivo de saída padrão (stdout) e os caracteres "$?" - Este é o código de erro atual (restante do comando anterior). Portanto, se nosso curl não conseguir acessar o servidor repentinamente, ele fornecerá um código de erro diferente de zero, e descobriremos isso verificando a variável errr.

6. Conveniência

Aqui, quero fazer uma pequena digressão de assuntos técnicos para tornar a leitura do texto mais interessante. (Se você não concordar, pule três parágrafos). Eu direi que toda atividade humana é apropriada à sua maneira. Mesmo quando uma pessoa bate intencionalmente sua testa contra uma parede (ou no chão ... no teclado ...), isso tem sua própria conveniência. Por exemplo, fornece uma saída para energia emocional - talvez não da melhor maneira, mas como pode. (Sim, e o próprio conceito de "melhor" não faz sentido do ponto de vista deste momento neste lugar - porque o melhor e o pior são possíveis apenas em comparação com outra coisa).

Estou escrevendo este texto agora, em vez de casos aparentemente mais importantes para mim - por quê? Em primeiro lugar, para fazer um balanço, revisar e classificar internamente as prateleiras do que aprendi escrevendo scripts nesses dois dias ... Remova-o da RAM e armazene-o. Em segundo lugar, dessa maneira, descanse um pouco ... Em terceiro lugar, espero que essa explicação mastigada seja útil para outra pessoa (e para mim, talvez um dia). Como, não importa se é o melhor, mas distinto lembrete sobre o assunto de scripts e solicitações de servidor.

Alguém, talvez, me corrija algo, e o resultado se tornará ainda melhor. Alguém receberá uma informação útil. É apropriado? Talvez ... isso é o que eu posso fazer agora e estou fazendo. Amanhã, talvez eu acorde e reavalie as ações atuais ... mas essa reavaliação também fornecerá algo útil para a vida adulta.

Portanto, ao atender a solicitação, temos dois dados:

• o bloco principal de informações do servidor (se, é claro, a resposta do servidor veio), nós as escrevemos na variável info;
• código de erro do comando curl (0, se não houver erros) - gravado na variável errr.

Precisamente porque ambos os totais - informações e código de erro - são necessários, eu os escrevi em variáveis ​​e não repasse imediatamente os totais de Kurl para outras equipes através do Pipe. Mas agora neste script é hora de subir nos canos:

 code=$(echo "$info" | grep HTTP | grep -v 'HTTP/2 200') date=$(echo "$info" | grep -i 'date:') dlay=$(echo "$info" | grep  | sed -e 's///') 

Em cada uma dessas linhas, escrevemos outra variável - salvamos os resultados da execução de comandos. E em cada caso não é uma equipe, mas uma corrente; o primeiro link é o mesmo em todo lugar: echo "$ info" - retorna ao fluxo do dispositivo de saída padrão (stdout) o próprio bloco de informações que salvamos e recebemos do curl. Mais abaixo no canal, esse fluxo é passado para o comando grep. O Grep seleciona de todas as linhas apenas aquelas em que corresponde ao padrão. (A opção -i significa "diferencia maiúsculas de minúsculas"). Como você pode ver, no primeiro caso, selecionamos a linha que contém "HTTP". Essa linha, extraída da pilha do restante, é passada pelo canal para o comando grep -v 'HTTP / 2 200' . Aqui, a opção -v é o oposto da opção -e , filtra as linhas onde esse padrão é encontrado. Total, na variável de código, haverá uma linha com o código de resposta do servidor (como “HTTP / 1.1 302 encontrado”), mas apenas se não for 'HTTP / 2 200'. Portanto, filtrei as linhas que meu site envia no caso normal e salvo apenas as respostas "anormais". (Se você tiver uma resposta normal do servidor, substitua-a lá).

Da mesma forma, na variável date, escrevemos a linha na qual o servidor emitiu sua data e hora atuais. Isso é algo como " data: dom, 11 de fevereiro de 2019 às 08:06:57 GMT " (geralmente no fuso horário GMT, também conhecido como UTC). Precisamos escrever a data (mas apenas uma vez por dia!) Em nosso arquivo de log ("log de status do servidor") - server.log. E, ao mesmo tempo, exibiremos esse tempo na tela. Você pode escrever uma data e hora no log do seu computador, mas por conveniência, nós as aceitamos, já que o servidor as enviou de qualquer maneira.

É semelhante à nossa terceira variável, dlay (da palavra em inglês delay - delay). Selecionamos a linha em nosso rótulo de concurso "eeyu", na qual mantivemos a duração da espera por uma resposta do servidor. Removemos esse rótulo, que não é mais necessário, usando o comando sed - e salvamos o resultado.

Agora, se imprimirmos essas variáveis ​​para verificação - por exemplo, adicionando as linhas ao nosso script:

 printf 'errr: %s\n' "$errr" printf 'code: %s\n' "$code" printf '%s\n' "$date" printf 'dlay: %s\n' "$dlay" 

você deve obter algo como:

 errr: 0 code: date: Mon, 11 Feb 2019 12:46:18 GMT dlay: 0.236549 

Total: o código de erro do curl é zero (o que significa que funcionou bem). Código de status do servidor - não gravado (como era normal). Data e hora. A duração da resposta. Resta exibir corretamente o que você precisa na tela e, se necessário, gravar em um arquivo.

Isso é o mais interessante: o quê, sob quais condições e como gravar?

7. Conclusões complicadas

Para não incomodá-lo com mais detalhes, eu lhe digo brevemente (e há diretórios suficientes em todos esses comandos na Internet). A propósito, a brevidade é um dos principais objetivos que alcançaremos ao escrever neste log. Então, será conveniente para a visualização e nunca ocupará muito espaço em disco (diferente de outros logs que crescem em megabytes por dia).

Primeiro: certifique-se de escrever a data no log apenas uma vez, e não em cada linha. Para fazer isso, selecione da data variável individualmente a data atual (curr) e a hora (hora):

 curr=$(echo "$date" | sed -e 's/\(20[0-9][0-9]\).*$/\1/') time=$(echo "$date" | sed -e 's/^.*\ \([0-9][0-9]:.*\)\ GMT\r$/\1/') 

E também consideramos linhas com datas do arquivo de log e pegamos a última data (anterior):

 prev=$(cat /home/me/Progs/iNet/monitor/site.log | grep -e 'date:' | tail -1) 

Se nossa data atual (curr) não for igual à data anterior (do arquivo, prev), então um novo dia chegou (ou, digamos, o arquivo de log estava vazio); depois escreva a nova data no arquivo:

 if [[ $curr != $prev ]]; then printf '%s\n' "$curr" >>/home/me/Progs/iNet/monitor/site.log printf '%s %s %s\n' "$time" "$dlay" "$code" >>/home/me/Progs/iNet/monitor/site.log 

... e, ao mesmo tempo, registramos as informações atuais: hora, atraso no recebimento de uma resposta do site, código de resposta do site (se não comum):

  printf '%s %s %s\n' "$time" "$dlay" "$code" >>/home/me/Progs/iNet/monitor/site.log 

Isso ajudará a navegar: esse e aquele dia começaram com uma velocidade do site. Em outros casos, não vamos desorganizar o arquivo com entradas desnecessárias. Obviamente, anotá-la-emos se recebermos um código de status incomum do servidor:

 elif [[ -n $code ]]; then printf '%s %s %s\n' "$time" "$dlay" "$code" >>/home/me/Progs/iNet/monitor/site.log 

E também escreva se o tempo de resposta do servidor for maior que o normal. Meu site geralmente era responsável por 0,23 a 0,25 segundos; portanto, registro respostas que levaram mais de 0,3 segundos:

 elif (( $(echo "$dlay > 0.3" | bc -l) )); then printf '%s %s\n' "$time" "$dlay" >>/home/me/Progs/iNet/monitor/site.log 

Finalmente, uma vez por hora, simplesmente registro o tempo recebido do servidor - como um sinal de que ele está vivo e ao mesmo tempo como uma espécie de marcação do arquivo:

 else echo "$time" | grep -e :00: | cat >>/home/me/Progs/iNet/monitor/site.log fi 

Obtemos o conteúdo do arquivo em que a marcação com registros horários ajuda visualmente, sem ler, a ver quando a carga é maior ou menor (mais registros por hora):

 19:42:28 0.461214 19:53:29 0.443956 20:00:29 20:09:30 2.156462 20:10:29 0.358294 20:45:29 0.313378 20:51:30 0.563886 20:54:30 0.307219 21:00:30 0.722343 21:01:30 0.310284 21:09:30 0.379662 21:10:31 1.305779 21:12:35 5.799455 21:23:31 1.054537 21:24:31 1.230391 21:40:31 0.461266 21:42:37 7.140093 22:00:31 22:12:37 5.724768 22:14:31 0.303500 22:42:37 5.735173 23:00:32 23:10:32 0.318207 date: Mon, 11 Feb 2019 00:00:34 0.235298 00:01:33 0.315093 01:00:34 01:37:41 5.741847 02:00:36 02:48:37 0.343234 02:56:37 0.647698 02:57:38 1.670538 02:58:39 2.327980 02:59:37 0.663547 03:00:37 03:40:38 0.331613 04:00:38 04:11:38 0.217022 04:50:39 0.313566 04:55:45 5.719911 05:00:39 

E, finalmente, exibimos informações na tela. Além disso, se a curvatura falhar, exibimos e escrevemos uma mensagem sobre ela (e, ao mesmo tempo, executamos o Ping e efetuamos login para verificar se o servidor está ativo):

 printf '%s\n%s\n%s' "$time" "$dlay" "$code" if (( $errr != 0 )); then date >>/home/me/Progs/iNet/monitor/site.log date printf 'CURL Request failed. Error: %s\n' "$errr" >>/home/me/Progs/iNet/monitor/site.log printf 'CURL Request failed. Error: %s\n' "$errr" pung=$(ping -c 1 178.248.237.68) printf 'Ping: %s\n----\n' "$pung" >>/home/me/Progs/iNet/monitor/site.log printf 'Ping: %s\n' "$pung" fi 

Substitua o endereço IP na cadeia de ping pelo endereço IP real do seu site.

8. Posfácio

O resultado do trabalho:



À esquerda no painel, você pode ver a hora no UTC e a capacidade de resposta atual do site. À direita está o log: é visível para o rally, mesmo com uma rolagem superficial, durante que horas a carga foi mais ou menos. Você também pode perceber respostas anormalmente lentas (picos; embora ainda não esteja claro de onde elas vêm).

Isso é tudo. O script acabou sendo simples, em carvalho, e pode ser aprimorado: trabalho em otimização, portabilidade, aprimoramento de notificações e exibições, levando em consideração o proxy e o cache ...

Mas já nesse tipo de programa, provavelmente ele pode dar uma idéia do estado do seu site. E que seja um site sabiamente apropriado, útil para pessoas e todas as criaturas!



PS. Após a discussão (em 12/02/2019):

Como eu esperava, os especialistas escreveram muitos comentários interessantes.

Tendo refletido sobre isso, posso responder à pergunta rsashka , qual é a vantagem desse script.

Outras ferramentas, como o NetData (graças a tchspprt pela dica!), Fornecem uma grande variedade de dados que não serão armazenados por muito tempo. O NetData é uma boa ferramenta quando você trabalha todos os dias, mantém sites profissionalmente. Bom para diagnosticar problemas atuais.

Um roteiro como o meu é ficar de olho enquanto faz outras coisas. O script não requer estudo e configurações especiais. Isso não é ruim para os leigos. E seus logs ocupam tão pouco espaço que não podem ser apagados. Eles podem se acumular ao longo dos anos, e nos anos N + 1 você pode ver: "Uau, em 2019, meu tempo de resposta foi uma vez e meia menor! .."

Ou seja, essa solução tem seu próprio nicho - principalmente para administradores que não são do sistema constantemente. (Como tchspprt diz : "É sobre como alimentar o gato de um vizinho em férias").

A andreymal recomendou uma maneira interessante de levar em conta e visualizar a carga do site, sem recursos adicionais, simplesmente através dos registros de acesso no site. E você pode criar belos gráficos neles. Provavelmente vou tentar esta opção e postar no Github o que aconteceu.

unnforgiven aconselhou outra solução interessante - provavelmente uma simples (instale prometheus, blackbox e alermanager via docker compositer). No meu VPS simples e barato, não é suficiente para essa memória; e Linux com um kernel antigo - o Docker não será iniciado. Mas obrigado pela opção!

Outra dicatchspprt : Grafite + Prometeu + Grafana. Ou forneça ao script belos gráficos (gnuplot ou rrdtool).

Mcalexvrn recomenda uma ferramenta simples: uptimerobot . Obrigada

Agradeço a todos por uma variedade de informações! Que seja útil para as pessoas ...