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.

Foto de Mikhail Vasiliev, Unsplash.Com

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).

Genmon

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).

404

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:

El monitor de sitio web m√°s simple

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!

Texto completo del guión con comentarios. ¡No te olvides de hacer los cambios necesarios!
 #!/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 $?) # errr = CURL error code https://curl.haxx.se/libcurl/c/libcurl-errors.html code=$(echo "$info" | grep HTTP | grep -v 'HTTP/2 200') date=$(echo "$info" | grep -i 'date:') dlay=$(echo "$info" | grep  | sed -e 's///') # code = Response code = 200? # => empty, otherwise response code string # # date = from HTTP Header of the server responded, like: # Date: Sun, 10 Feb 2019 05:01:50 GMT # # dlay = Response delay ("time_total") from CURL, like: # 0.25321 #printf 'errr: %s\n' "$errr" #printf 'code: %s\n' "$code" #printf '%s\n' "$date" #printf 'dlay: %s\n' "$dlay" 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/') prev=$(cat /home/me/Progs/iNet/monitor/site.log | grep -e 'date:' | tail -1) # = Previously logged date, like: # date: Sun, 10 Feb 2019 # Day logged before vs day returned by the server; usually the same if [[ $curr != $prev ]]; then # Write date etc., at the beginning of every day: 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 elif [[ -n $code ]]; then # If the response had HTTP error code - log it: printf '%s %s ? %s\n' "$time" "$dlay" "$code" >>/home/me/Progs/iNet/monitor/site.log elif (( $(echo "$dlay > 0.3" | bc -l) )); then # If the response delay was large - log it: printf '%s %s %s\n' "$time" "$dlay" "$code" >>/home/me/Progs/iNet/monitor/site.log else # If it's the start of an hour - just log the time echo "$time" | grep -e :00: | cat >>/home/me/Progs/iNet/monitor/site.log fi # To screen: printf '%s\n%s\n%s' "$time" "$dlay" "$code" # On CURL error: 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 



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 ...

Source: https://habr.com/ru/post/439894/


All Articles