Cómo simplemente monitorear el estado del sitio

Para controlar de forma remota el rendimiento de los servidores, los profesionales utilizan sistemas de software especiales, como Zabbix o Icinga . Pero, si usted es un propietario novato o administrador de uno o dos sitios web con una carga pequeña, entonces no hay necesidad de grandes sistemas de monitoreo. El parámetro principal es si el sitio sirve rápidamente a los usuarios. Por lo tanto, puede monitorear el trabajo del sitio utilizando un programa simple desde cualquier computadora conectada a Internet.



Escribamos este script ahora: el monitoreo más simple de la disponibilidad y la velocidad del sitio. Este programa se puede ejecutar en una computadora doméstica, teléfono inteligente, etc. El programa tiene solo dos funciones:

• muestra en la pantalla el tiempo durante el cual su sitio ofrece páginas a los usuarios,
• en caso de respuestas lentas del sitio o errores, el programa escribe datos en un archivo (un "registro" o un archivo de registro). Vale la pena verificar estos datos de vez en cuando para solucionar problemas cuando recién comienzan. Por lo tanto, nos encargaremos de registrar estos registros de forma clara y conveniente para una visualización rápida.

Describiré cada paso en detalle para que incluso un principiante que esté un poco familiarizado con la escritura de archivos por lotes (bat y cmd en DOS y Windows, sh en sistemas como UNIX) pueda resolverlo sin problemas y pueda adaptar el script a sus necesidades. Pero le pido que no use este script sin pensar, porque si se usa incorrectamente, puede no dar resultados adecuados y, además, engullir mucho tráfico .

Describiré un script para un sistema operativo como Linux y su uso en una computadora doméstica. Por los mismos principios, esto se puede hacer en otras plataformas. Y para aquellos que solo están mirando las posibilidades de Linux, un ejemplo más puede ser interesante, qué herramienta tan simple y poderosa son sus scripts.

1. Organización primero

Crearemos una carpeta separada para este programa y crearemos 3 archivos en él. Por ejemplo, tengo esta carpeta / home / me / Progs / iNet / monitor (aquí estoy el nombre de mi usuario, Progs / iNet es mi carpeta para programas relacionados con Internet, y monitor es el nombre de este programa, de la palabra monitor, es decir Como soy el único usuario de esta computadora, guardo dichos archivos entre mis carpetas personales (/ home) en una sección separada del disco, lo que me permite guardarlos al reinstalar el sistema). En esta carpeta habrá archivos:

• README.txt: aquí hay una descripción (en caso de esclerosis): qué tipo de programa, información básica, etc.
• mon.sh: habrá un programa que sondea el sitio.
• server.log: aquí registrará los indicadores de estado del sitio. En nuestro caso, esto es simplemente la fecha, hora y duración de la respuesta del sitio (más información adicional si el servidor responde con un error con nuestra solicitud).

(Para la conveniencia de editar y, en todo caso, restaurar archivos, puede incluir esta carpeta en el sistema de control de versiones de Git; aquí no la describiré).

2. Persistente y relajado

Ejecutaremos el archivo mon.sh con un pequeño intervalo regular, por ejemplo, 60 segundos. Utilicé la herramienta estándar proporcionada por el sistema operativo (más precisamente, el entorno de escritorio).

Mi entorno de escritorio es Xfce. Esta es una de las opciones más populares para Linux. Me gusta Xfce porque te permite personalizar casi por completo todo el entorno, tal como lo deseas. Al mismo tiempo, Xfce es algo más compacto y más rápido que otros dos sistemas conocidos: Gnome y KDE. (Otras opciones también son interesantes, por ejemplo, el entorno LXDE es aún más rápido y fácil que Xfce, pero hasta ahora no es tan rico en funciones).

La herramienta que necesitamos, en el caso de Xfce, es un complemento para el panel de trabajo del Monitor genérico. Por lo general, ya está instalado, pero si no, el instalador lo encontrará fácilmente: "Genmon" (descripción: xfce4-genmon-plugin ). Este es un complemento que se puede agregar al panel y establecer en la configuración: (1) el comando que se ejecutará y (2) la frecuencia de su ejecución en segundos. En mi caso, el comando:

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

(o, de manera equivalente, ~ / Progs / iNet / monitor / mon.sh).

3. Cuando el programa aún no existe, ya hay errores

Si ya ha completado todos estos pasos (archivos creados e iniciado el complemento en el panel), verá el resultado de iniciar nuestro programa allí (mensaje de error: el archivo mon.sh no es un programa). Luego, para hacer que el archivo sea ejecutable, vaya a nuestra carpeta y configure su permiso para ejecutar:

• o administrador de archivos: Propiedades - Permisos - Permitir que este archivo se ejecute como un programa;
• o un comando desde la terminal: chmod 755 mon.sh

Y en el archivo mismo, escribimos las primeras líneas:

#!/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 $?) 

En lugar de "example.ru", sustituya el nombre de su sitio, cuyo estado observará. Y si funciona en http, coloque http en lugar de https. La línea #! / Bin / bash significa que este es un script que lanzará el programa Bash ( bash es probablemente el más común para ejecutar scripts en Linux). Para trabajar a través de otro shell, se indica en lugar de Bash. Las líneas restantes con un filo al principio son comentarios. La primera línea de código en sí es info = $ () y en estos corchetes está el comando curl con parámetros. Tal construcción, algo = $ (algo), significa "ejecutar el comando entre paréntesis y asignar el resultado a la variable de la izquierda". En este caso, llamé a la variable "información". Este comando entre paréntesis (curl (en la jerga conocida por algunos como "Kurl") envía una solicitud a la red en la dirección especificada y nos devuelve la respuesta del servidor. (Mi conocido dijo, explicando: "Cómo gruñe la grúa, y recibe una respuesta de otra grúa en el cielo"). Considere las opciones:

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

-Quiero decir que no solicitamos la página completa, sino solo sus "encabezados HTTP". Cada vez que no necesitamos el texto completo de la página para asegurarnos de que el sitio funciona. Como revisaremos el sitio con frecuencia, es importante hacer que el tamaño de los datos transmitidos sea lo más pequeño posible. Esto ahorra tráfico y electricidad, y la carga en el servidor, y la vida silvestre.

Por cierto, preste atención a la cantidad de tráfico adicional que tiene (no utilizado por mes) en el alojamiento. A continuación verá cuántos datos se transmiten y puede calcular si tiene suficientes reservas; en todo caso, el período de verificación del sitio se puede aumentar a 5, 10 o incluso 30-60 minutos. Aunque en este caso la imagen no será tan completa, y las interrupciones menores pueden pasar desapercibidas; pero, en general, al monitorear un sitio, es más importante detectar problemas a largo plazo que una sola interrupción. Además, ¿qué tráfico puede permitirse en la computadora que llama? En mi caso, una PC de escritorio con tráfico ilimitado, esto no es tan importante; pero para un dispositivo móvil o tarifa con límites, vale la pena calcular y, posiblemente, aumentar los intervalos de inspección.

4. El paso sigue al paso excepto el primer paso

Vayamos más allá: -o / dev / stdout significa "enviar la respuesta recibida por Kurl del servidor a tal o cual archivo". Y en este caso, este no es un archivo en el disco, sino / dev / stdout: dispositivo de salida estándar. Por lo general, el "dispositivo de salida estándar" es nuestra pantalla donde podemos ver los resultados del programa. Pero en el script, a menudo dirigimos esta "salida estándar" para su posterior procesamiento (ahora, guárdelo en la variable de información). Y luego, la mayoría de las veces, enviaremos los resultados de los equipos a variables o los pasaremos a los siguientes equipos en una cadena. Para crear cadenas a partir de comandos, use el operador de tubería ("Pipe"), que se muestra como una barra vertical ("|").

-w '% {time_total} eyayu' : aquí -w significa "formatear y dar tal información adicional a un dispositivo de salida estándar". Específicamente, estamos interesados ​​en time_total: cuánto tiempo llevó la transmisión de solicitud-respuesta entre nosotros y el servidor. Probablemente sepa que hay un comando más simple, ping, para solicitar rápidamente un servidor y obtener una respuesta de él, pong. Pero Ping solo verifica que el servidor de alojamiento esté vivo, y la señal va y viene por tanto tiempo. Esto muestra la velocidad máxima de acceso, pero aún no nos dice nada acerca de qué tan rápido el sitio produce contenido real. Ping puede funcionar rápidamente y, al mismo tiempo, el sitio puede ralentizarse o no funcionar, debido a una gran carga o algunos problemas internos. Por lo tanto, usamos exactamente Kurla y obtenemos la hora real en que el servidor muestra nuestro contenido.

(Y con este parámetro puede juzgar si el servidor funciona de manera eficiente para sus tareas, si su tiempo de respuesta típico es conveniente para los usuarios. No hay problemas, por ejemplo, mis sitios en muchos sitios de alojamiento se han ralentizado con el tiempo, y tuve que buscar otro alojamiento).

¿Has notado las extrañas letras "eyu" después de {time_total}? Los agregué como una etiqueta única, que probablemente no estará en los encabezados que nos envían desde el servidor (aunque hacer suposiciones sobre lo que sus usuarios tendrán y no tendrán es una mala forma y el camino hacia el abismo. ¡No haga esto! ... O, cuando lo haga , al menos avergonzarse de ti). Con esta etiqueta (espero), podemos extraer fácilmente la información que necesitamos de un montón de líneas en la variable de información. Entonces, curl -w '% {time_total} ehayu' (con los parámetros restantes correctos) nos dará algo como:

0.215238eyayu

Esta es la cantidad de segundos que tardó en acceder al sitio, más nuestra etiqueta. (Además de este parámetro, en la variable de información nos interesará principalmente el "Código de estado": el código de estado o, simplemente, el código de respuesta del servidor. Por lo general, cuando el servidor emite el archivo solicitado, el código es "200". Cuando no se encuentra la página , este es el famoso 404. Cuando hay errores en el servidor, a menudo es 500 con algo).

5. Creatividad: el padre de la autoevaluación

Los parámetros restantes de nuestro rizo son los siguientes:

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

lo que significa: solicitar tal o cual dirección; el tiempo máximo de respuesta es de 9 segundos (puede configurar menos, ya que un usuario raro esperará una respuesta del sitio durante tanto tiempo, rápidamente encontrará que el sitio no funciona). Y "-s" significa silencio, es decir, curl no nos dirá detalles innecesarios.

Por cierto, generalmente no hay mucho espacio en el panel del escritorio, por lo tanto, para depurar un script, es mejor ejecutarlo desde la terminal (en su carpeta usando el comando ./mon.sh). Y para nuestro complemento de panel, pondremos una larga pausa entre los lanzamientos del comando, digamos, 3600 segundos.

Para la depuración, podemos ejecutar este rizo sin enmarcar los corchetes y ver qué produce. (A partir de esto y calcular el consumo de tráfico). Veremos principalmente un conjunto de encabezados 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 

La primera línea aquí vemos "HTTP / 1.1 302 encontrado", lo que significa: el protocolo de transferencia de datos es "HTTP / 1.1", el código de respuesta del servidor es "302 encontrado". Al solicitar otra página, este puede ser el código "301 movido permanentemente", etc. En otro ejemplo, la respuesta normal de mi servidor es "HTTP / 2 200". Si su servidor normalmente responde de manera diferente, sustitúyalo en lugar de “HTTP / 2 200” en este script.

La última línea, como vemos, Kurl da, en cuántos segundos recibimos la respuesta del servidor, con nuestra etiqueta asignada.

Interesante: podemos configurar el sitio para que informe sobre nuestras solicitudes (¡y solo sobre ellas!) Información adicional sobre su estado, por ejemplo, en el encabezado HTTP "casero". Digamos cuál es la carga en los procesadores del sitio, cuánta memoria libre y espacio en disco tiene y qué tan rápido funciona la base de datos. (Por supuesto, para esto, el sitio debe ser dinámico, es decir, las solicitudes deben ser procesadas por el programa, en PHP, Node.JS, etc. Otra opción es utilizar un software especial en el servidor). Pero quizás todavía no necesitamos realmente estos detalles. El propósito de este script es simplemente monitorear regularmente el rendimiento general del sitio. En caso de problemas, ya nos ocuparemos del diagnóstico por otros medios. Por lo tanto, ahora estamos escribiendo el script más simple que funcionará para cualquier sitio, incluso uno estático, y sin configuraciones adicionales en el servidor. En el futuro, si lo desea, será posible ampliar las capacidades del script; Mientras tanto, haga la base.

La cadena errr = $ (echo $?) Significa: escribir el resultado del comando "echo $?" En la variable errr. El comando echo significa imprimir texto en el dispositivo de salida estándar (stdout) y los caracteres "$?" - Este es el código de error actual (restante del comando anterior). Entonces, si nuestro curl de repente no puede llegar al servidor, dará un código de error distinto de cero, y descubriremos esto al verificar la variable errr.

6. Expediencia

Aquí quiero hacer una pequeña digresión de los asuntos técnicos para que leer el texto sea más interesante. (Si no está de acuerdo, omita tres párrafos). Diré que toda actividad humana es apropiada a su manera. Incluso cuando una persona golpea intencionalmente su frente contra una pared (o en el piso ... en el teclado ...), esto tiene su propia conveniencia. Por ejemplo, proporciona una salida para la energía emocional, tal vez no de la "mejor" manera, sino de cómo puede hacerlo. (Sí, y el concepto mismo de "mejor" no tiene sentido desde el punto de vista de este momento en este lugar , porque lo mejor y lo peor son posibles solo en comparación con otra cosa).

Estoy escribiendo este texto ahora, en lugar de casos aparentemente más importantes para mí, ¿por qué? En primer lugar, para hacer un balance, revisar y clasificar internamente los estantes de lo que aprendí al escribir guiones durante estos dos días ... Quítelo de la RAM y guárdelo. En segundo lugar, de esta manera tengo un poco de descanso ... En tercer lugar, espero que esta explicación masticada sea útil para otra persona (y para mí, quizás algún día). Cómo, no importa si es el mejor, pero un recordatorio distinto sobre el tema de los scripts y las solicitudes del servidor.

Alguien, tal vez, me corregirá en algo, y el resultado será aún mejor. Alguien obtendrá una pieza de información útil. ¿Es apropiado? Quizás ... esto es lo que puedo hacer ahora y lo estoy haciendo. Mañana, tal vez me despierte y reevalúe las acciones actuales ... pero esta reevaluación también proporcionará algo útil para la vida posterior.

Entonces, al cumplir con la solicitud, tenemos dos datos:

• el bloque principal de información del servidor (si, por supuesto, vino la respuesta del servidor), lo escribimos en la variable de información;
• código de error del comando curl (0, si no hay errores): escrito en la variable errr.

Precisamente porque se necesitan ambos totales, tanto información como un código de error, los escribí en variables y no pasé de inmediato los totales de Kurl a otros equipos a través de la tubería. Pero ahora en este script es hora de subir las tuberías:

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

En cada una de estas líneas escribimos otra variable: guardamos los resultados de la ejecución de comandos. Y en cada caso no es un equipo, sino una cadena; el primer enlace es el mismo en todas partes: echo "$ info" : regresa al flujo del dispositivo de salida estándar (stdout) el mismo bloque de información que guardamos, recibido de curl. Más adelante, esta secuencia se pasa al comando grep. Grep selecciona de todas las líneas solo aquellas en las que coincide con el patrón. (La opción -i significa "mayúsculas y minúsculas"). Como puede ver, en el primer caso seleccionamos la línea que contiene "HTTP". Esta línea, extraída del montón del resto, se pasa por la tubería al comando grep -v 'HTTP / 2 200' . Aquí, la opción -v es lo opuesto a la opción -e , filtra las líneas donde se encuentra dicho patrón. Total, en la variable de código habrá una línea con el código de respuesta del servidor (como "HTTP / 1.1 302 encontrado"), pero solo si no es 'HTTP / 2 200'. Así que filtro las líneas que envía mi sitio en el caso normal y guardo solo las respuestas "anormales". (Si tiene una respuesta normal del servidor, sustitúyala allí).

De manera similar, en la fecha variable escribimos la línea en la que el servidor emitió su fecha y hora actuales. Esto es algo así como " fecha: dom, 11 de febrero de 2019 08:06:57 GMT " (generalmente en la zona horaria GMT, también conocida como UTC). Necesitamos escribir la fecha (¡pero solo una vez al día!) En nuestro archivo de registro ("registro de estado del servidor") - server.log. Y al mismo tiempo, mostraremos este tiempo en la pantalla. Puede escribir una fecha y hora en el registro desde su computadora, pero por conveniencia las tomamos, ya que el servidor las envió de todos modos.

Es similar con nuestra tercera variable, dlay (de la palabra inglesa delay - delay). Seleccionamos la línea en nuestra etiqueta de licitación "eeyu" en la que mantuvimos la duración de la espera de una respuesta del servidor. Eliminamos esta etiqueta, que ya no es necesaria, utilizando el comando sed , y guardamos el resultado.

Ahora, si imprimimos estas variables para verificación, por ejemplo, agregando las líneas a nuestro script:

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

deberías obtener algo como:

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

Total: el código de error de curl es cero (lo que significa que funcionó bien). Código de estado del servidor: no registrado (como era normal). Fecha y hora La duración de la respuesta. Queda por mostrar correctamente lo que necesita en la pantalla y, si es necesario, escribir en un archivo.

Esto es lo más interesante: ¿qué, bajo qué condiciones y cómo grabar?

7. Conclusiones difíciles

Para no aburrirlo con más detalles, le contaré brevemente (y hay suficientes directorios buenos en todos estos comandos en Internet). Por cierto, la brevedad es uno de los objetivos principales que alcanzaremos al escribir en este registro. Entonces será conveniente para ver y nunca ocupará mucho espacio en disco (a diferencia de otros registros que crecen en megabytes por día).

Primero: nos aseguramos de escribir la fecha en el registro solo una vez, y no en cada línea. Para hacer esto, seleccione de nuestra fecha variable individualmente la fecha actual (curr) y la 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/') 

Y también consideramos líneas con fechas del archivo de registro y tomamos la última fecha (anterior):

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

Si nuestra fecha actual (curr) no es igual a la anterior (del archivo, anterior), entonces ha llegado un nuevo día (o, por ejemplo, el archivo de registro estaba vacío); luego escriba la nueva fecha en el archivo:

 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 

... y al mismo tiempo registramos la información actual: tiempo, demora en recibir una respuesta del sitio, código de respuesta del sitio (si no es normal):

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

Esto ayudará a navegar: tal y tal día comenzó con tal y tal velocidad del sitio. En otros casos, no abarrotemos el archivo con entradas innecesarias. Por supuesto, lo escribiremos si obtenemos un código de estado del servidor inusual:

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

Y también escriba si el tiempo de respuesta del servidor es más largo de lo habitual. Mi sitio generalmente era responsable de 0.23-0.25 segundos, por lo que registro las respuestas que tomaron más 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, una vez por hora, simplemente registro el tiempo recibido del servidor, como una señal de que está vivo, y al mismo tiempo como una especie de marcado del archivo:

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

Obtenemos el contenido del archivo donde el marcado con registros por hora ayuda visualmente, sin leer, para ver cuándo la carga es mayor o menor (más 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 

Y finalmente, mostramos información en la pantalla. Y también, si falla el curl, mostramos y escribimos un mensaje al respecto (y al mismo tiempo ejecutamos Ping e iniciamos sesión para verificar si el servidor está vivo):

 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 

Reemplace la dirección IP en la cadena de ping con la dirección IP real de su sitio.

8. Epílogo

El resultado del trabajo:



A la izquierda del panel, puede ver la hora en UTC y la capacidad de respuesta actual del sitio. A la derecha está el registro: es visible para el rally, incluso con un desplazamiento superficial, durante qué horas la carga fue más o menos. También puede notar respuestas anormalmente lentas (picos, aunque aún no está claro de dónde provienen).

Eso es todo El script resultó ser simple, roble, y se puede mejorar: trabajar en la optimización, portabilidad, mejora de notificaciones y pantallas, teniendo en cuenta el proxy y la memoria caché ...

Pero ya en este tipo de programa, probablemente puede dar una idea del estado de su sitio. ¡Y que sea un sitio sabiamente apropiado, útil para las personas y todas las criaturas!



PS. Después de la discusión (el 12/02/2019):

Como esperaba, los expertos escribieron muchos comentarios interesantes.

Después de pensarlo, puedo responder la pregunta de rsashka , ¿cuál es la ventaja de este script?

Otras herramientas, como NetData (¡gracias a tchspprt por la sugerencia!), Proporcionan una gran variedad de datos que no se almacenarán por mucho tiempo. NetData es una buena herramienta cuando trabaja todos los días, mantiene sitios web profesionalmente. Bueno para diagnosticar problemas actuales.

Un guión como el mío es vigilar mientras se hacen otras cosas. La secuencia de comandos no requiere estudios y configuraciones especiales. Esto no es malo para los laicos. Y sus registros ocupan tan poco espacio que no se pueden borrar en absoluto. Se pueden acumular a lo largo de los años, y en los años N + 1 se puede ver: "¡Guau, en 2019, mi tiempo de respuesta fue una vez y media menor! .."

Es decir, tal solución tiene su propio nicho, principalmente para los administradores que no son del sistema constantemente. (Como dice tchspprt : "Se trata de cómo alimentar al gato de un vecino en vacaciones").

andreymal aconsejó una forma interesante de tener en cuenta y luego ver la carga del sitio, sin fondos adicionales, simplemente a través de los registros de acceso en el sitio. Y puedes construir hermosos gráficos en ellos. Probablemente probaré esta opción y publicaré en Github lo que sucedió.

Ungforgiven aconsejó otra solución interesante, probablemente una simple (instale prometheus, blackbox y alermanager a través de Docker Composer). En mi simple y barato VPS no es suficiente para esta memoria; y Linux con un núcleo antiguo: Docker no se iniciará. Pero gracias por la opción!

Otro consejotchspprt : Grafito + Prometeo + Grafana. O proporcione al script gráficos hermosos (gnuplot o rrdtool).

Mcalexvrn recomienda una herramienta simple: uptimerobot . Gracias

¡Agradezco a todos por tanta información! Que sea útil para las personas ...