Statping: Monitoriza el estado de todos tus servicios

¡Ha pasado ya más de un año y medio desde que este blog comenzó su andadura! Y en todo ese tiempo he ido publicando aquí los servicios que he ido integrando en mi propia nube personal. Echando la vista atrás, me he dado cuenta de que son más de los que creía en un principio... Y mantener toda esa infraestructura acaba llevando tiempo, no lo voy a negar.

Si seguís el blog desde los inicios, sabréis que hay servicios más críticos y servicios que he ido desplegando por curiosidad, pero que no han llegado a pasar de ahí. Para los primeros, hago uso de máquinas VPS con el fin de poder disponer de ellos desde cualquier lugar sin necesidad de depender de mi proveedor de Internet, y así de paso mantener separada mi nube local de la personal. Pero con el tiempo, esos servicios han crecido y me he visto obligado a monitorizar cuándo dejaban de estar disponibles y poder intervenir cuanto antes en volver a tenerlos funcionando. Buscando soluciones, di con una bastante útil: Statping.

Statping no es más que un servicio que nos permitirá monitorizar el estado de nuestros servicios y páginas web con una interfaz bastante limpia, de manera sencilla y con soporte a notificaciones, avisos, alertas, gráficas, plug-ins... Está escrito en Go y, cómo no, es open source.

Instalación de Statping

Para variar, lo vamos a desplegar como un contenedor Docker. En este caso es algo tan sencillo como lo siguiente:

version: "2.1"

services:
  statping:
    image: adamboutcher/statping-ng
    container_name: statping
    restart: always
    user: 1000:1000
    volumes:
      - ./data:/app
    networks:
      - public
    labels:
      - "traefik.enable=true"
      - "traefik.port=8080"
      - "traefik.backend=statping"
      - "traefik.frontend.rule=Host:stats.midomin.io"
      - "traefik.docker.network=public"
      - "traefik.http.routers.statping-secure.entrypoints=https"
      - "traefik.http.routers.statping-secure.rule=Host(`stats.midomin.io`)"
      - "traefik.http.routers.statping-secure.tls=true"
      - "traefik.http.routers.statping-secure.tls.certresolver=certlocal"
      - "traefik.http.services.statping.loadbalancer.server.port=8080"

networks:
  public:
    external: true

Como podéis ver, no tiene nada de extraño o especial. Lo más destacado es que pongáis el UID/GID correspondiente a vuestro usuario y grupo (si es distinto). Le definimos un volumen donde guardará la base de datos y la información de nuestros servicios, así como la configuración, y lo agregamos a la red que controla Traefik, con las etiquetas correspondientes, para poder acceder a su interfaz por HTTPS y de una manera sencilla, accediendo simplemente a https://stats.midomin.io. Para arrancarlo, bastará con el comando docker-compose up -d.

Configuración inicial

Una vez hemos arrancado el servicio y accedido a la URL inicial, veremos que nos lleva a una página de configuración, donde deberemos seleccionar el idioma, la base de datos que queremos usar (para nuestro caso, nos llega de sobra con la SQLite) y otros datos como el nombre que queremos darle al servicio (obligatorio rellenar ese campo), descripción, dominio en el que se encuentra y, lo más importante, un usuario y una contraseña. Una vez rellenemos todo y lo guardemos, nos redirigirá a la página principal, donde tendremos unos servicios por defecto creados.

Añadir servicios

Para añadir nuestros servicios, deberemos acceder primero al Dashboard (abajo del todo de la página está el enlace... en ese sentido no son muy intuitivos). Una vez hecho el login, veremos que en la parte superior nos aparece un menú. Dentro de Servicios podremos crear los que necesitemos, así como grupos para poder clasificarlos (yo los uso, por ejemplo, para separar los servicios por VPS). Si vamos a Crear, veremos que hay 3 tipos de datos a introducir:

• Información del servicio: En este apartado rellenamos la información relativa al servicio que queremos monitorizar: Nombre, descripción, protocolo del servicio (HTTP, TCP, UDP, gRPC...), grupo en el que lo queremos clasificar, un enlace permanente para que pueda ser consultado directamente, si queremos que esa métrica sea pública o no y cada cuánto comprobaremos su estado.
• Detalles de la petición: La parte más crítica. Aquí deberemos agregar la URL donde está nuestro servicio. Según el protocolo seleccionado en el apartado anterior, nos pedirá una URL y un método (GET, POST...) o una IP y puerto, por ejemplo. Marcaremos el tiempo máximo que le damos al servicio para responder (a partir del cual se considerará que no está disponible) y demás datos. Por ejemplo, para HTTP podremos definir el código de respuesta (un 2xx normalmente), si en las cabeceras debe venir algo específico o si en el cuerpo de la respuesta debe haber algo concreto (por ejemplo, si nuestro servicio responde con un 200 pero sólo lo consideramos disponible si en el cuerpo viene un {status: AVAILABLE}, mismamente). En este apartado, según el servicio que estemos controlando, podremos afinar más o menos si lo necesitamos.
• Opciones de notificación: Por último, en este apartado definiremos si queremos recibir notificaciones de estado de este servicio, cuántos errores consecutivos deben darse antes de recibir una alerta y si deseamos que se nos notifique constantemente o no. Esto es útil si, por ejemplo, consideramos que un servicio que falla 1 vez puede que no esté caído, poder especificar que, al menos, falle 3 veces consecutivas, siendo cada una de ellas cada minuto (definido en el primer apartado). Y en caso de detectar dicha caída, queremos que sólo nos lo notifique una vez, pues ya intervendremos, y no queremos estar recibiendo cada 3 minutos la misma alerta (que nos puede llegar a cansar...).

Con todo esto, podremos crear nuestra monitorización. Si volvemos a nuestro Dashboard podremos ver algo tal que así:

Como podéis ver en la imagen anterior, el Dashboard nos proporciona información del estado de cada servicio, así como del tiempo de respuesta medio, su latencia... Y nos permite definir anuncios y notificar incidentes.

Si nos vamos a la página principal (la URL inicial, sin ninguna ruta en ella), lo que veremos será algo similar a esto:

La imagen de arriba representa la página principal de Statping. En ella veremos los servicios que tenemos dados de alta si tenemos iniciada la sesión o sólo aquellos que hayamos marcado como públicos, así como los últimos fallos que se han producido y los incidentes y anuncios publicados para cada uno de ellos.

Notificaciones

Sin embargo, de poco nos vale un Dashboard para detectar cuándo un servicio se nos cae si no lo estamos mirando constantemente, ¿verdad? El último paso que nos quedaría por crear se encuentra dentro de la Configuración, a la cual accederemos desde el menú superior.

En ella, veremos que hay un apartado de Notificaciones con bastantes opciones. Podremos elegir la que más nos convenga. En mi caso, configuré Telegram para recibir allí cuándo un servicio se cae o vuelve a estar disponible, pero en lugar de hacerlo con un canal (ya que lo quiero para que me notifique sólo a mí, que son servicios privados míos), lo hice configurando un webhook. La configuración es tan sencilla como la de la siguiente imagen, reemplazando <TOKEN> por el token de nuestro bot de Telegram, claro está:

Podremos probar un mensaje de OK y uno de error desde la propia configuración. Con eso sabremos si la tenemos bien realizada. Si todo ha ido bien, veremos algo como:

Os dejo también un caso más real. El otro día hubo un mantenimiento programado de este blog y dejé programada su actualización a eso de las 6 y pico de la mañana. Cuando me levanté al día siguiente, en mi Telegram tenía un mensaje tal que así:

Como veis, recibí un mensaje de cuándo fue la última vez que estuvo disponible. Cuando se completó la actualización del blog y volvió a arrancar, Statping lo detectó y me lo notificó con otro mensaje:

Fue algo más bien puntual (apenas duró 5 minutos desde que lo detectó), pero fui consciente de que, durante ese tiempo, el blog no fue accesible.

Conclusiones

Obviamente, la gracia de todo esto es levantar Statping en un servidor distinto al que contenga los servicios que queréis monitorizar, o de lo contrario, será poco útil si esa conexión se cae... Yo lo tengo en mi red local, pues el objetivo es controlar los servicios que tengo en mis VPS. Y para los servicios de mi red local, tengo una RPi viejita aparte que los controla, aunque en este caso sólo monitoriza que no se caigan o peten, ya que la disponibilidad de los mismos se reduce a la LAN y las notificaciones sólo me llegarían dentro de ella, y fuera sólo si mi ISP no está caído.

En cualquier caso, es una herramienta muy útil que os puede ayudar, y mucho, a monitorizar vuestros servicios y en la que podéis delegar esa responsabilidad, dejando que sean las notificaciones las que os avisen de los cambios.

Por último, deciros que existe una aplicación móvil que también puede recibir notificaciones, además de personalizar algunas cosas más... Pero eso lo reservan para usuarios de pago. No es muy cara (a fecha de esta entrada apenas rondaba los 5€), si veis que lo que ofrece os atrae... Yo de momento la tengo por curiosidad sólo, ya que realmente con las notificaciones y la versión web me es más que suficiente (quizá si siguen aumentando los servicios a monitorizar o el blog se populariza tanto que merece la pena hacer públicas sus estadísticas...)

Si te ha gustado la entrada, o te ha sido útil y quieres ayudarme a pagar los gastos que conlleva el servidor y mantener así el blog libre completamente de anuncios, puedes hacer una donación en Bitcoin en la siguiente dirección: