Introducción

¿Que vamos a hacer?

En pocas palabras, vamos a usar monitoreo sintético para nuestros servicios Web, vamos a instalar y configurar todo lo necesario para poder usar la plantilla *Website by Browser" de Zabbix.

"Warning!!!"

Si esperan una guía de esas de ‘pega esto en la consola y reza para que funcione’, esta no es. En esta guía quiero que le bajen un cambio y entiendan bien como funciona todo y como monitorearlo de la mejor manera y acorde con tu infraestructura. Vamos a hablar de casos reales, de arquitecturas que se van a encontrar en la calle y cómo abordarlas. Porque si no sabes lo que estás haciendo, no se puede hacer un monitoreo sintético de manera correcta.

Esto viene para largo, así que vayan por un café y algo para picar.

(Les juro que estoy tratando de hacerlo lo más corto posible!)

¿Qué es el monitoreo sintético?

Antes de meter las manos a la masa, vale la pena entender el concepto.

El monitoreo tradicional normalmente revisa componentes individuales:

  • CPU.
  • Memoria.
  • Disco.
  • Servicios.
  • Puertos.
  • Procesos.

Ejemplo:

Un chequeo puede decir:

Puerto 443 abierto.
Servicio HTTP responde.
Código HTTP 200.

Perfecto.

Pero eso solamente responde:

"¿El servicio está vivo?"

El monitoreo sintético responde una pregunta más importante:

"¿Un usuario puede utilizar realmente el servicio?"

Ejemplo:

Servidor web: OK
Base de datos: OK
Certificado: OK
HTTP: OK

Usuario:
"La página no carga".

¿Qué pasó?

Puede ser cualquiera de estas cosas:

  • La aplicación está esperando una consulta lenta.
  • Un recurso externo está bloqueando la carga.
  • El balanceador de carga está apuntando a otra IP/server.
  • Un componente frontend falló.
  • Un servicio interno no responde.
  • El registro DNS está mal.
  • Existe un problema que solamente aparece navegando.
  • JavaScript lento.
  • Imágenes que no cargan.
  • APIs externas caídas.
  • Content Security Policy (CSP), bloqueando contenido.
  • Errores frontend.
  • Recursos bloqueados.

Website by Browser permite detectar estos escenarios antes de que el usuario final sea nuestra alarma de monitoreo.

Arquitectura de Website by Browser

Antes de instalar cachureos es importante entender cómo funciona.

El flujo es:

  1. Zabbix recibe una tarea de monitoreo.
  2. Un Browser Poller toma esa tarea.
  3. El Browser Poller se comunica con el contenedor Selenium.
  4. Selenium controla Chrome.
  5. Chrome abre el sitio web.
  6. Se recopilan métricas.
  7. Zabbix almacena los resultados.

Vamos a usar un contenedor Docker para instalar Selenium, porque la separación mediante Docker tiene varias ventajas:

  • No llenamos el servidor Zabbix con dependencias gráficas.
  • Podemos actualizar Chrome fácilmente.
  • Podemos reemplazar Selenium sin tocar Zabbix.
  • Podemos aislar consumo de recursos.
  • La arquitectura queda más limpia.

Cada componente hace una sola cosa.

Requisitos previos

Antes de comenzar necesitamos:

Requisito Detalle
Zabbix Server Versión 7.4 o superior
Docker Instalado en el servidor Zabbix
Selenium Contenedor Chrome
Acceso root Necesario para configuración
Red Acceso hacia sitios monitoreados
DNS Resolución correcta desde Selenium

Para ambientes pequeños y medianos, Selenium puede ejecutarse en el mismo servidor Zabbix.

Para instalaciones grandes, con muchos sitios monitoreados, conviene separar Selenium en servidores dedicados. (ojo con la RAM que usa googole-chrome)

Instalación de Docker

Ahora que tenemos clara la película y la arquitectura, vamos a lo que vinimos.

Instalar dependencias necesarias

En sistemas basados en RHEL, Rocky Linux, AlmaLinux o derivados:

dnf install -y dnf-utils device-mapper-persistent-data lvm2

Estas dependencias permiten que Docker gestione correctamente sus componentes de almacenamiento.

Agregar repositorio oficial de Docker

dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo

Instalar Docker Engine

dnf install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Habilitar e iniciar Docker

systemctl enable --now docker

Verificar qué Docker quedó funcionando:

docker version

También podemos validar ejecutando un contenedor de prueba:

docker run hello-world

Si aparece el mensaje indicando qué Docker ejecutó correctamente el contenedor, estamos listos.

Crear contenedor Selenium Chrome

Ahora vamos a levantar el navegador que utilizará Zabbix.

La imagen utilizada será:

selenium/standalone-chrome

Esta imagen incluye:

  • Selenium Server.
  • Chrome.
  • Driver necesario para automatización.
  • Configuración lista para recibir conexiones.

Ejecutamos el contenedor:

docker run --rm \
--name zabbix-browser \
-e TZ=America/Santiago \
-p 4444:4444 \
-p 7900:7900 \
--shm-size=2g \
selenium/standalone-chrome:latest

Ajusten el TZ a la zona horaria que les corresponde

OJO!!! No le asignen un dns al contenedor, si lo hacen el contenedor no puede enviar los resultados de las consultas a zabix

Validar que Selenium está funcionando

Primero revisamos que el contenedor está ejecutándose:

docker ps | grep zabbix-browser

La salida debería mostrar algo similar:

selenium/standalone-chrome

Ahora probamos el endpoint de Selenium haciendo una consulta al puerto 4444 (que definimos al ejecutar el contenedor):

curl http://localhost:4444/status

Una respuesta correcta debería incluir:

"ready": true

Ejemplo:

{
  "value": {
    "ready": true
  }
}

Si obtenemos esta respuesta, Selenium está listo para recibir conexiones desde Zabbix.

Administrar el contenedor de Selenium-Chrome con systemd

Hasta este punto tenemos Selenium funcionando dentro de Docker.

Perfecto.

Pero ahora viene la pregunta importante:

  • ¿Qué pasa si el servidor reinicia?

  • ¿Quién levanta el contenedor?

  • ¿Quién valida que Selenium vuelva a estar disponible?

  • ¿Quién lo reinicia si Chrome queda colgado?

La respuesta correcta en un ambiente productivo es:

systemd.

Docker se encargará de ejecutar el contenedor.

systemd se encargará de administrar el servicio.

Cada herramienta haciendo lo que sabe hacer mejor.

¿Por qué no dejar solamente –restart en Docker?

Una configuración simple podría ser:

docker run \
--restart unless-stopped

Y funciona.

Para instalaciones pequeñas puede ser suficiente.

Pero cuando queremos una administración más profesional, systemd entrega más control:

  • Estado del servicio.
  • Dependencias.
  • Logs centralizados.
  • Inicio ordenado después del arranque.
  • Control mediante systemctl.
  • Integración con herramientas de administración.

Además, evita mezclar responsabilidades.

Docker administra contenedores.

systemd administra servicios.

Crear servicio systemd

Creamos el archivo:

vim /etc/systemd/system/zabbix-browser.service

Contenido:

[Unit]
Description=Selenium Chrome Container for Zabbix Website Browser
Requires=docker.service
After=docker.service


[Service]
Type=simple

Restart=always
RestartSec=10

ExecStartPre=-/usr/bin/docker stop zabbix-browser
ExecStartPre=-/usr/bin/docker rm zabbix-browser

ExecStart=/usr/bin/docker run --rm \
--name zabbix-browser \
-e TZ=America/Santiago \
-p 4444:4444 \
-p 7900:7900 \
--shm-size=2g \
-v /etc/zabbix/docker-hosts/hosts:/etc/hosts:ro \
selenium/standalone-chrome:latest
ExecStop=/usr/bin/docker stop -t 30 zabbix-browser


[Install]
WantedBy=multi-user.target

Activar el servicio que acabamos de crear

Después de crear el archivo tenemos que ejecutar:

systemctl daemon-reload

Esto es como: “oe! systemd! actualiza tus archivos de servicios porque puede que haya algo nuevo”

Habilitamos inicio automático y arrancamos el servicio:

systemctl enable --now zabbix-browser.service

Verificar estado

Revisamos:

systemctl status zabbix-browser.service

Si está todo bien debería mostrar:

Active: active (running)

También podemos validar Docker:

docker ps | grep zabbix-browser

Monitorear el propio Selenium

Una buena práctica es monitorear también el componente encargado de monitorear.

SpiderMan

Sí, suena un poco absurdo, Pero es infraestructura.

Si Selenium está caído, Zabbix puede dejar de ejecutar pruebas web.

Podemos crear un chequeo simple:

net.tcp.service[tcp,,4444]

o monitorear:

curl http://localhost:4444/status

La idea es evitar tener un sistema de monitoreo que falla silenciosamente.

Tambien podemos usar la plantilla “Docker by Zabbix Agent 2” asignada al mismo servidor Zabbix donde corremos el contenedor de Selenium.

Van a necesitar esto para que el agente Zabbix pueda leer el status de Docker en el servidor Zabbix:

setfacl -m user:zabbix:rw /var/run/docker.sock

Configuración del servidor Zabbix

Ahora debemos indicarle a Zabbix como hablar con Selenium para que pueda “navegar” hacia los sitios web que vamos a monitorear.

El servidor Zabbix utiliza los Browser Pollers para ejecutar este tipo de monitoreo.

Editamos:

vim /etc/zabbix/zabbix_server.conf

Agregamos o modificamos:

WebDriverURL=http://localhost:4444
StartBrowserPollers=5

WebDriverURL

Esta variable indica la dirección donde Zabbix va a encontrar a Selenium. (el puerto que definimos al crear el Docker)

En este ejemplo:

http://localhost:4444

porque el container de Selenium está corriendo en el mismo servidor.

Si usamos un servidor separado para Selenium hay que apuntar hacia la IP de ese servidor:

WebDriverURL=http://IP_DEL_SERVIDOR_SELENIUM:4444

StartBrowserPollers

Define cuántos procesos de Zabbix estarán disponibles para ejecutar pruebas con navegador.

Ejemplo:

StartBrowserPollers=5

significa que tendremos cinco procesos preparados para ejecutar navegaciones simultáneas.

No existe un número mágico para todos.

Depende principalmente de:

  • Cantidad de sitios monitoreados.
  • Frecuencia de ejecución.
  • Complejidad de las páginas.
  • Recursos disponibles.

Para comenzar, cinco procesos es un valor razonable.

Después podemos ajustarlo mirando el rendimiento real.

Reiniciar Zabbix Server

Después de modificar la configuración:

systemctl restart zabbix-server

Comprobamos que los Browser Pollers iniciaron correctamente:

tail -50 /var/log/zabbix/zabbix_server.log | grep poller

Deberíamos decir algo como:

started [browser poller #1]
started [browser poller #2]

Si aparecen los browser pollers, saca la carne del refri para que quede a temperatura ambiente y esté lista para el asado, porque Zabbix ya tiene comunicación con Selenium.

Verificar consumo de recursos

Antes de empezar a monitorear muchos sitios, conviene revisar consumo.

Chrome no es precisamente conocido por ser liviano. (¿Alguien quiere pensar en el precio de la RAM?, por el amor de Dios!)

Revisar:

docker stats zabbix-browser

Ejemplo:

CONTAINER ID   NAME             CPU %     MEM USAGE / LIMIT     MEM %     NET I/O           BLOCK I/O       PIDS
68b67b88fc0f   zabbix-browser   1.73%     710.7MiB / 15.36GiB   4.52%     45.6MB / 27.4MB   919MB / 329MB   115

Podemos ver:

  • CPU utilizada.
  • Memoria.
  • Red.
  • Procesos activos.

Para pocos sitios no debería existir problema.

Pero si vamos a monitorear decenas o cientos de páginas, hay que planificar capacidad.

Un navegador por cada prueba puede consumir recursos rápidamente. (como la RAM de mi notebook llorando porque abrí una cuarta pestaña en Chrome)

Recomendación de producción

Para instalaciones pequeñas:

Zabbix Server
    |
    |_ Selenium Docker

Es suficiente.

Para ambientes más grandes:

Zabbix Server
|
|
Selenium Server dedicado
    |
    |_ Chrome Container1
    |_ Chrome Container2

Separar Selenium permite:

  • Escalar horizontalmente.
  • Evitar carga adicional en Zabbix.
  • Administrar recursos independientes.
  • Tener más capacidad de pruebas simultáneas.

Ahora… ¿cómo hacemos que nuestro chequeo sea lo más real posible?

Esta es probablemente una de las partes que da más dolores de cabeza cuando se se implementa un monitoreo sintético.

¿Por qué?

Bueno, porque el escenario típico es este:

Tenemos:

www.orangebox.cl

Publicado hacia Internet.

DNS público:

[www.orangebox.cl] ➜ [200.50.10.20]

Pero internamente tenemos:

Server IP
Firewall 172.16.200.1
Proxy reverso / balanceador 172.16.200.13
Server Web 172.16.200.14

Cuando un usuario externo entra al sitio web:

[Usuario] ➜ [IP pública] ➜ [Firewall] ➜ [Proxy reverso / Balanceador] ➜ [Servidor Web]

Todo funciona.

Pero nuestro Zabbix está dentro de la misma red interna que el servidor Web que estamos monitoreando.

Si Selenium resuelve usando DNS privado:

[www.orangebox.cl] ➜ [172.16.200.14]

La prueba irá directamente al servidor web

  • No va a pasar por el firewwall.
  • No va a pasar por el proxy reverso o balanceador (si es que existe).
  • Si está detras de un proxy reverso, lo más probable es que no tenga SSL, y ni siquiera escuche en el puerto 443.
  • No hará la ruta completa que hace el usuario al conectarse a nuestro web.
  • La medición no representa el acceso real.

Si Selenium resuelve usando DNS público:

[www.orangebox.cl] ➜ [200.50.10.20]

La prueba saldrá hacia Internet.

Pero eso puede generar algunos problemas:

  • El firewall bloquea la salida (hairpin).
  • El certificado no coincide.
  • El proxy interno no recibe la petición.
  • La ruta es diferente.
  • La medición no representa el acceso real.

Entonces vamos a tener los siguientes escenarios:

Caso 1

[IP pública] ➜ [Firewall] ➜ [Proxy reverso / Balanceador] ➜ [Servidor Web]
  • Ideal: Hhabilitar el hairpin en el firewall y monitorear directamente el sitio web usando la IP pública.
  • Pior es nah: Monitorear el web usando la IP del Proxy reverso / Balanceador
  • Me wa matarme: Monitorear directo al servidor Web.

Caso 2

[IP pública] ➜ [Firewall] ➜ [Servidor Web]
  • Ideal: Hhabilitar el hairpin en el firewall y monitorear directamente el sitio web usando la IP pública.
  • Pior es nah: Monitorear el web usando la IP del Servidor Web.

¿Cómo saber cuál de estos casos elegir?

Vamos a ejecutar desde el server zabbix lo siguiente:

  • Editen el archivo de hosts para poner la IP pública del sitio a monitorear:

    Vim /etc/hosts 200.2.202.148 www.orangebox.cl

  • Probamos si funciona (debe responder la IP que agregamos al archivo hosts).

#ping www.orangebox.cl
PING www.orangebox.cl (200.2.202.148) 56(84) bytes de datos.
64 bytes desde mail.appnexit.cl (200.2.202.148): icmp_seq=1 ttl=57 tiempo=12.9 ms
64 bytes desde mail.appnexit.cl (200.2.202.148): icmp_seq=2 ttl=57 tiempo=13.6 ms
  • Consultamos la web con curl.
   17:28 root@zabbix.orangebox.cl ~ # curl -v https://www.orangebox.cl
* Host www.orangebox.cl:443 was resolved.
* IPv6: (none)
* IPv4: 200.2.202.148
*   Trying 200.2.202.148:443...
* connect to 200.2.202.148 port 443 from 192.168.200.240 port 39584 failed: Connection refused
* Failed to connect to www.orangebox.cl port 443 after 1 ms: Could not connect to server
* closing connection #0
curl: (7) Failed to connect to www.orangebox.cl port 443 after 1 ms: Could not connect to server17:28 root@zabbix.orangebox.cl ~ # curl -v https://www.orangebox.cl
* Host www.orangebox.cl:443 was resolved.
* IPv6: (none)
* IPv4: 200.2.202.148
*   Trying 200.2.202.148:443...
* connect to 200.2.202.148 port 443 from 192.168.200.240 port 39584 failed: Connection refused
* Failed to connect to www.orangebox.cl port 443 after 1 ms: Could not connect to server
* closing connection #0
curl: (7) Failed to connect to www.orangebox.cl port 443 after 1 ms: Could not connect to server

Si responde Bien, genial!!!

Pero si les da un error como ese de Connection refused, pero el sitio web funciona correctamente cuando se conectan desde un navegador, entonces lo más probable es que NO esté habilitado el Hairpin. No les voy a mentir, esto va a estar duro, explicarle a la gente de red que necesitan habilitar esto puede ser complejo.

Ahora tenemos cuatro opciones:

  • Pelear hasta morir para habilitar el hairpin.
  • Poner el contenedor de Selenium fuera de nuestra red, para evitar estos problemas y que chequee desde la WAN, tal como lo haría un usuario.
  • Con la cola entre las piernas… Configurar el Website by browser para consultar el web directo en el proxy reverso o balanceador.
  • Aun más triste, Chequear directamente el web server.

¿Eligieron que IP van a monitorear? Pública?, Proxy reverso? Server web?…

Muy bien, con ese dato claro, vamos a ver como configuramos esto.

Verificar resolución desde Selenium

Ejecutamos en el server donde corre el contenedor Selenium:

docker exec zabbix-browser getent hosts www.orangebox.cl

La idea es confirmar qué el contenedor Selenium está viendo la misma IP que nosotros queremos usar parar el monitoreo.

Si el contenedor no resuelve la misma IP que queremos, lo vamos a forzar a usar un archivo de hosts

Creamos el directorio en el servidor Zabbix:

mkdir -p /etc/zabbix/docker-hosts

Creamos el archivo:

vim /etc/zabbix/docker-hosts/hosts

Ejemplo:

####################################################
# Hosts personalizados para Selenium Chrome
####################################################

200.50.10.20 www.orangebox.cl  		# IP pública
192.168.200.13 wazuh.orangebox.cl	# IP del proxy reverso
192.168.200.14 blog.orangebox.cl        # IP del Web Server

Con esto estamos diciendo:

“No importa lo que diga DNS, para Selenium estos dominios apuntan aquí”.

Montar el archivo hosts dentro del contenedor

Detener y eliminar el contenedor:

docker stop zabbix-browser; docker rm zabbix-browser

Y lo volvemos a crear:

docker run -d \
--name zabbix-browser \
-e TZ=America/Santiago \
--restart unless-stopped \
-p 4444:4444 \
-p 7900:7900 \
--shm-size=2g \
-v /etc/zabbix/docker-hosts/hosts:/etc/hosts:ro \
selenium/standalone-chrome:latest

El parámetro importante es:

-v /etc/zabbix/docker-hosts/hosts:/etc/hosts:ro

Esto reemplaza el archivo hosts interno del contenedor.

Comprobamos si está correcto:

docker exec zabbix-browser cat /etc/hosts

Debe mostrar el mismo contenido que agregaron al archivo.

El caso más triste, usar la IP del Servidor Web:

Basta con que el contenedor use el DNS privado, o también podemos usar el caso anterior, la única diferencia es que vas a poner la IP del servidor web en el archivo de hosts en vez de la del proxy reverso.

Importar y configurar la plantilla Website by Browser en la interface web de Zabbix.

Con Selenium funcionando y Zabbix comunicándose con el navegador, ahora viene la parte donde realmente comenzamos a monitorear sitios.

La plantilla oficial de Zabbix para Website by Browser viene instalada por defecto en Zabbix 7.4 y contiene:

  • Items.
  • Triggers.
  • Gráficos.
  • Descubrimientos.
  • Macros necesarias para ejecutar las pruebas.

Pero hay un detalle importante:

La recomendación es crear hosts dummy dedicados exclusivamente al monitoreo web.

¿Por qué crear hosts dummy?

Una práctica bastante común es crear un host por cada sitio monitoreado.

Por ejemplo:

Host:
www.orangebox.cl

Este host no representa un servidor físico o virtual.

Representa un servicio web.

Pero ya tengo monitoreado el servicio apache/nginx en el servidor donde corre el sitio web de ese dominio!!!

¿Por que no agregar este monitoreo al mismo host?

Porque:

  • Es común que ese servidor aloje muchos sitios web con distintos nombres.
  • Aun más común es que ese sitio web esté detrás de un proxy reverso / balanceador de carga que a su vez responden por muchos sitios web.

Y tenemos una limitación: Podemos agregar sólo una plantilla de website by browser por host.

En estricto rigor si se puede, pero hay que tocar macros y triggers, y no, no queremos caer en la pasta.

Entonces. La idea es que Zabbix tenga un lugar lógico donde almacenar por cada sitio web monitoreado:

  • Tiempos de carga.
  • Estado del sitio.
  • Capturas.
  • Alertas.
  • Tendencias.

Un ejemplo de estructura ordenada:

Grupo:
Servicios Web

    |
    +-- www.orangebox.cl
    |
    +-- portal.cliente1.cl
    |
    +-- api.empresa.cl

Además podemos agregar TAGs al host dummy para que sea claro y ordenado a que corresponde. Ejemplo:

TAG:
Cliente = Orangebox
Servicio = Website
Servidor = srvweb.orangebox.cl
Aplicacion = Web Corporativa
Entorno = Produccion

Otra buena idea es ponerle en el nombre del host dummy el nombre del servidor donde corre ese sitio web. Ejemplo:

WEB - srvweb.orangebox.cl - www.orangebox.cl

Esto permite administrar el monitoreo de manera ordenada sin mezclarlo con servidores reales, pero sabes claramente en que servidor corre cada sitio web monitoreado. Así, en caso de falla, en la misma alerta tenemos toda la data, no vamos a tener que ir a buscar el excel donde Juancho anotó en que servidor está corriendo la app web de contabilidad.

Crear host para monitoreo web (¿cuánto falta?!)

Vamos a crear un host dummy.

Ruta:

Recopilación de datos
    |
    +-- Equipos
         |
         +-- Crear equipo

Ejemplo:

Nombre del host:

WEB - srvweb.orangebox.cl - www.orangebox.cl

Grupo:

Servicios Web

Interfaz del host

Aunque este host no es un servidor real, Zabbix necesita una interfaz.

Configuramos:

Tipo:

Agente Zabbix

Dirección:

Idealmente usar la IP del servidor donde le va a pegar este monitoreo, si es directamente el servidor web, la IP del servidor web, si es el proxy reverso, le ponemos la IP del proxy reverso. Esto es sólo por un tema de orden, ya que este chequeo va a salir directamente desde el Docker Selenium, y no desde la IP del agente que le pongamos aquí

IP del servidor

Ejemplo:

192.168.200.13

Puerto:

10050

Asignar plantilla

En el equipo:

Plantillas vinculadas:

Website by Browser

Después guardamos.

Configuración mediante macros

La plantilla utiliza macros para saber qué sitio debe monitorear, si es HTTP o HTTPS o y que puerto usa.

Las principales son:

Dominio

{$WEBSITE.DOMAIN}

Ejemplo:

www.orangebox.cl

Esquema

{$WEBSITE.SCHEME}

Normalmente:

https

o:

http

Ruta

{$WEBSITE.PATH}

Ejemplo:

/

Pero también podría ser:

/login

/portal/clientes

La configuración final quedaría:

{$WEBSITE.DOMAIN}

www.orangebox.cl


{$WEBSITE.SCHEME}

https


{$WEBSITE.PORT}

443


{$WEBSITE.PATH}

/

Agregar tags al host

Los tags son extremadamente útiles cuando después queremos crear dashboards, filtros o acciones.

Ejemplo:

Tag Valor
Servicio Website
Entorno Produccion
Proxy ProxyReverso

Una estructura recomendada:

Tag Valor
Servicio Web
Aplicación PortalClientes
Entorno Produccion
Proxy ProxyReverso
Esquema WEB HTTPS

Esto permite después crear:

  • Dashboards dinámicos.
  • Alertas filtradas.
  • Reportes.
  • SLA.

Crear varios sitios

Si tenemos varios dominios:

Ejemplo:

www.orangebox.cl
clientes.orangebox.cl
api.orangebox.cl

La recomendación es:

Un host dummy por servicio.

No:

Un host gigante con 50 URLs

¿Por qué?

Porque cada sitio puede tener:

  • Diferentes responsables.
  • Diferentes criticidades.
  • Diferentes ventanas de mantenimiento.
  • Diferentes alertas.

Ejemplo:

Servicios Web

    www.orangebox.cl

    Criticidad:
    Alta


    blog.orangebox.cl

    Criticidad:
    Media


    api.orangebox.cl

    Criticidad:
    Alta

Asociar el monitoreo web con el servidor real a nivel de alarmas

Hasta ahora nuestro host de Website by Browser es solamente un “dummy” que representa el servicio web, pero todavía falta algo importante: decirle a Zabbix que ese sitio depende del servidor donde realmente está corriendo.

Porque si no hacemos esto y se muere el Apache que aloja estos sitios monitoreados, vamos a recibir una alerta por el servicio apache y una por cada sitio web monitoreado que corre ahí mismo… y pueden ser muchas, muchas alertas.

Para esto utilizamos las dependencias de triggers de Zabbix.

La idea es simple:

WEB - srvweb.orangebox.cl - www.orangebox.cl

depende de:

srvweb.orangebox.cl - Apache HTTP Server

La lógica queda así:

[Servidor Apache caído] ➜ [Servicio web no evaluado]

Primero debemos tener monitoreado el servicio Apache en el host real:

srvweb.orangebox.cl

    |
    +-- Apache/nginx HTTP Server
    +-- CPU
    +-- Memoria
    +-- Disco

Luego, en el trigger del sitio web:

Website HTTP status is not 200

Agregamos una dependencia hacia el trigger que valida Apache.

Ruta:

Recopilación de datos
    |
    +-- Hosts
         |
         +-- WEB - srvweb.orangebox.cl - www.orangebox.cl
              |
              +-- Iniciadores / Triggers
  • Editamos el Iniciador / trigger:
    Website HTTP status is not 200
  • Vamos a la pestaña:
    Dependencias
  • Seleccionan:
    agregar
  • En la barra superior dice “Equipo”:
    pinchan el boton "seleccionar"
  • Ahora la barra superior dice “Grupo del equipo”:
    pinchan el boton "seleccionar"
  • Seleccionen el grupo al que pertenece:

EJ:

    Linux Servers
  • Ahora va seleccional el equipo
    srvweb.orangebox.cl
  • Se va a desplegar en la ventana todos los Iniciadores / Triggers de ese equipo. Seleccionen:
Apache HTTP Server is down

Desde ahora Zabbix entiende la relación:

Si Apache está caído, el problema real es el servidor o el servicio web, no el navegador sintético.

Esto evita una avalancha de alertas y permite que la primera alerta que llegue sea la que realmente necesitamos atender.

La idea es que Zabbix no solamente nos diga “algo falló”, sino que también tenga contexto de dónde viene el problema.

No queremos un sistema que grite por todo. Queremos uno que levante la mano y diga:

“El problema está aquí”.

Primera validación (¿Ahora si ya está listo?!)

Después de guardar el host debemos esperar que Zabbix genere los items.

Vamos a:

Recopilación de datos

    Equipos

        WEB - srvweb.orangebox.cl - www.orangebox.cl

            Métricas

Buscamos:

website.get.data

Este es el item principal que ejecuta la navegación.

Forzar una prueba manual

Seleccionamos:

website.get.data

y usamos:

Actualizar ahora

Esperamos algunos segundos.

Si todo funciona correctamente comenzaremos a ver valores.

Revisar últimos datos

Ruta:

Monitorización

    Datos más recientes

Buscamos:

WEB - srvweb.orangebox.cl - www.orangebox.cl

Deberíamos encontrar información como:

  • Tiempo de navegación.
  • Código HTTP.
  • Datos obtenidos.
  • Métricas del navegador.

Revisar captura de pantalla

Una de las funciones más interesantes es la captura del navegador.

Vamos:

Monitorización

Equipos

	WEB - srvweb.orangebox.cl - www.orangebox.cl (click sobre el nombre)

		Tableros

Aquí vamos a la pestaña website overview y vamos a ver los gráficos de todas las métricas que está obteniendo, tiempo de carga, resolución de DNS, handshake del SSL, etc. etc. y además a la izquierda, un hermoso screenshot de como el monitoreo ve la página.

Esto permite ver exactamente qué estaba viendo Chrome.

Dashboard Zabbix Website by Browser - Monitoreo sintético web

Al fin!. Ahora solo tienen que repetir el proceso de agregar un host dummy y verificar la IP a usar por cada sitio web que quieren monitorear.

¿Necesitas ayuda implementando monitoreo profesional?

En Orangebox ayudamos a empresas a diseñar, implementar y administrar plataformas de infraestructura basadas en Linux, Zabbix y servicios críticos.

Trabajamos en:

  • Implementación de Zabbix.
  • Monitoreo avanzado.
  • Monitoreamos tu infraestructura con nuestros servidores de monitoreo.
  • Administración Linux.
  • Hardening de servidores.
  • Servicios administrados.
  • Plataformas de alta disponibilidad.

Más información:

https://www.orangebox.cl

Felipe Román Infraestructura Linux y servicios administrados.