Introducción

Durante años el monitoreo de servicios web se basado en preguntas bastante simples:

  • ¿El servidor responde?
  • ¿El puerto está abierto?
  • ¿El servicio está levantado?
  • ¿El certificado todavía no expiró?

Y ojo, esas métricas siguen siendo importantes.

El problema es que muchas veces la respuesta es:

“Sí, todo está arriba”.

Mientras el usuario está mirando una pantalla en blanco esperando que algo cargue.

Porque un servidor web respondiendo HTTP 200 no significa necesariamente que la aplicación esté funcionando correctamente.

Puedes tener:

  • Apache o Nginx respondiendo perfectamente.
  • El certificado SSL válido.
  • El puerto 443 abierto.
  • El balanceador funcionando.

Y aun así tener una página prácticamente inutilizable.

¿Por qué?

Porque los problemas reales muchas veces aparecen en capas superiores:

  • Una consulta lenta a base de datos.
  • Una API externa que no responde.
  • Un archivo JavaScript que demora demasiado.
  • Un recurso bloqueado.
  • Un problema de DNS.
  • Un problema en un balanceador de carga o un proxy reverso.
  • Un error de aplicación que solamente aparece al navegar.

Aquí entra en juego el monitoreo sintético.

La idea es simple:

“No sólo revisar si el servicio web existe haciendo pruebas desde el mismo servidor, sino comprobar si realmente funciona el web, tal como si navegara un usuario”.

La plantilla Website by Browser de Zabbix permite hacer justamente eso.

Utilizando un navegador Chrome real en modo headless (sólo texto), Zabbix puede simular la navegación de un usuario y obtener información mucho más cercana a la experiencia real.

Con esto podemos medir:

  • Tiempo total de carga.
  • Resolución DNS.
  • Tiempo de conexión.
  • Negociación TLS.
  • Tamaño de contenido descargado.
  • Código HTTP.
  • Capturas de pantalla.
  • Disponibilidad desde la perspectiva del usuario.

Así pasamos por todas las capas que finalmente hacen que el servicio funcione.

Porque seamos honestos:

Al usuario no le importa los SLA ni metricas de tu servidor, sólo le importa si “El sitio funciona o no funciona”.

Y normalmente nos enteramos de eso cuando llega el clásico mensaje:

“oe! Está caída la página”.

En ese momento comienza la hermosa aventura de revisar logs, certificados, DNS, firewalls, proxies reversos y servidores intentando descubrir qué pasó.

La idea de esta guía es dejar implementado Website by Browser en Zabbix 7.4 utilizando:

  • Zabbix Server.
  • Browser Pollers.
  • Selenium Chrome.
  • Docker.
  • Hosts dedicados para monitoreo web.

No solamente dejarlo instalado, sino entender cómo funciona y cómo mantenerlo correctamente.

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

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

Arquitectura de Website by Browser

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

Una confusión bastante común es pensar que Zabbix ejecuta Chrome directamente dentro del servidor.

No funciona así.

El flujo es:

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

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.

¿Por qué no usar solamente Web Monitoring?

Zabbix ya tiene monitoreo web tradicional.

“¿Entonces para qué necesito Selenium?”

Porque una prueba HTTP tradicional solamente revisa una parte del problema.

Ejemplo:

curl https://www.orangebox.cl

Puede responder:

HTTP/2 200 OK

Pero eso no significa que la experiencia sea buena.

El navegador puede encontrarse con:

  • JavaScript lento.
  • Imágenes que no cargan.
  • APIs externas caídas.
  • Problemas de autenticación.
  • Content Security Policy (CSP), bloqueando contenido.
  • Errores frontend.
  • Recursos bloqueados.

Un navegador real ejecutando una navegación real entrega una métrica mucho más cercana a la experiencia del usuario.

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.

Instalación de Docker

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

Selenium necesita un navegador real para ejecutar las pruebas. En lugar de instalar Chrome directamente sobre el servidor Zabbix, vamos a usar un contenedor Docker.

La ventaja de esto, es que mantenemos separado el componente del navegador del sistema principal.

Si mañana Chrome necesita una actualización, no tenemos que empezar una cirugía mayor sobre el servidor Zabbix.

Simplemente actualizamos el contenedor.

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 -d \
--name zabbix-browser \
--restart unless-stopped \
-p 4444:4444 \
-p 7900:7900 \
--shm-size=2g \
selenium/standalone-chrome:latest

Explicación de parámetros

–name zabbix-browser

Define el nombre del contenedor.

Esto facilita la administración posterior:

docker logs zabbix-browser

o:

docker restart zabbix-browser

–restart unless-stopped

Indica a Docker que debe reiniciar automáticamente el contenedor si falla.

La idea es que Selenium sea un servicio permanente.

Si el contenedor falla, nos van a llegar alertas de los sitios web monitoreados, pero no porque están malos, porque el chequeó falló!.

-p 4444:4444

Expone el puerto donde Selenium recibe las conexiones del Browser Poller de Zabbix.

Este puerto es el canal de comunicación entre Zabbix y Chrome.

-p 7900:7900

Expone el acceso VNC.

Esto es extremadamente útil para depuración.

Permite conectarse visualmente al navegador y observar qué está haciendo Selenium.

Cuando una prueba falla y nadie entiende por qué, poder ver el navegador trabajando ahorra bastante tiempo.

–shm-size=2g

Este parámetro es importante.

Chrome utiliza memoria compartida para muchas operaciones internas.

Sin suficiente memoria compartida pueden aparecer errores extraños:

  • Navegador cerrado inesperadamente.
  • Sesiones Selenium que fallan.
  • Páginas que cargan parcialmente.
  • Errores difíciles de diagnosticar.

Muchos problemas con Chrome en Docker vienen simplemente por olvidar este parámetro.

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:

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.

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

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 browser

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.

DNS, proxy reverso y resolución dentro del contenedor Selenium

Esta es probablemente una de las partes que más dolores de cabeza genera cuando se implementa Website by Browser.

El escenario típico es este:

Desde el servidor Zabbix hacemos:

curl https://www.orangebox.cl

y funciona perfectamente.

Entonces pensamos:

“Perfecto, Zabbix puede llegar al sitio”.

Pero después configuramos Website by Browser y aparece flor de error de navegación.

¿Por qué?

Porque el navegador Chrome no necesariamente está viendo lo mismo que ve el sistema operativo del servidor Zabbix.

Recordemos la arquitectura:

[Servidor Zabbix] ➜ [Contenedor Selenium] ➜ [Chrome]

El navegador vive dentro del contenedor.

Tiene:

  • Su propia red.
  • Su propia resolución DNS.
  • Su propio archivo hosts.
  • Sus propias reglas de salida.

Por eso hay que validar siempre desde el punto donde realmente ocurre la prueba.

Un ejemplo real

Supongamos este escenario:

Tenemos:

www.orangebox.cl

Publicado hacia Internet.

DNS público:

[www.orangebox.cl] ➜ [200.50.10.20]

Pero internamente tenemos:

Server IP
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] ➜ [Proxy reverso] ➜ [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 proxy reverso.
  • 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.

Si Selenium resuelve usando DNS público:

[www.orangebox.cl] ➜ [200.50.10.20]

La prueba saldrá hacia Internet.

Eso puede generar 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.

Verificar resolución desde Selenium

Primero entramos al contenedor:

docker exec -it zabbix-browser bash

Dentro podemos revisar:

cat /etc/resolv.conf

También podemos probar resolución:

nslookup www.orangebox.cl

o:

ping www.orangebox.cl

La idea es confirmar qué IP está viendo realmente Chrome.

Forzar resolución mediante archivo hosts

Lo ideal es habilitar el hairpin para las conexiones que vienen desde la IP del servidor Zabbix/Selenium, así al Docker le decimos que use un DNS público, como el 8.8.8.8 de Google y va a resolver siempre con las IPs públicas. De esta manera el monitoreo va a hacer exactamente el mismo recorrido que un usuario al entrar a la web.

Agregar DNS publico al container:

Detener y eliminar el contenedor:

docker stop zabbix-browser; docker rm zabbix-browser

Y lo volvemos a crear:

docker run -d \
--name zabbix-browser \
--restart unless-stopped \
--dns 8.8.8.8 \
-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:

--dns 8.8.8.8

Esto le dice al container que use el DNS público de Google.

Si no podemos habilitar el hairpin, una solución bastante útil en ambientes con proxy reverso es montar un archivo hosts personalizado dentro del contenedor.

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

192.168.200.13 www.orangebox.cl  	# IP del proxy reverso
192.168.200.13 wazuh.orangebox.cl	# IP del proxy reverso
192.168.200.13 blog.orangebox.cl        # IP del proxy reverso

Con esto estamos diciendo:

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

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

Verificar que Selenium está usando el archivo correcto

Ejecutamos:

docker exec zabbix-browser cat /etc/hosts

Tienen que aparecer los datos del archivo de host que creamos:

192.168.200.13 www.orangebox.cl

Si aparecen, Chrome va a usar esa IP y no va a consultar al DNS.

Ambientes con DNS dividido

Conocido como multi vista ó split DNS

Ejemplo:

Desde Internet:

[app.empresa.cl] ➜ [IP pública]

Desde la red interna:

[app.empresa.cl] ➜ [IP privada]

Esto es bastante común en infraestructuras corporativas.

Aplicaciones internas

Muchas empresas tienen portales que no existen públicamente, el famoso “Intranet”, al que muchas veces igual se puede conectar desde la WAN, Narf!, lo que lo convierte en un web común y corriente. (Lo veo siempre, pero en fin. Sigamos).

Ejemplo:

intranet.orangebox.cl

En estos casos Selenium necesita conocer cómo resolver ese dominio, aquí usamos el DNS privado, así Zabbix/Selenium van a monitorear directamente los sitios de Intranet con su IP privada.

NOTA: Esto va a depender bastante de cómo tengas armado el zoológico de servidores detrás. No existe una receta mágica que funcione igual para todos los ambientes (ojalá fuera tan fácil).

Mi recomendación es usar DNS privado y, cuando sea necesario, complementar con un archivo de hosts personalizado para Selenium. Es la opción más flexible y te evita terminar peleando con resoluciones raras, proxies reversos y el clásico “pero desde mi servidor sí funciona”.

Problemas con certificados TLS internos

Otro caso clásico.

El sitio responde:

https://portal.interno.local

pero Chrome muestra:

NET::ERR_CERT_AUTHORITY_INVALID

¿Por qué?

Porque el certificado fue firmado por una CA interna que Chrome no conoce.

La solución correcta no es desactivar validación SSL.

Eso solamente oculta el problema.

La solución correcta es:

  • Instalar la CA interna en el contenedor.
  • Utilizar certificados confiables.
  • Mantener una cadena válida.

En ambientes corporativos, la confianza del certificado debe ser igual de importante para monitoreo como para usuarios.

Buenas prácticas DNS

Antes de culpar a Zabbix, validar siempre:

  1. ¿Qué IP resuelve el servidor Zabbix?
    dig www.orangebox.cl
  1. ¿Qué IP resuelve el contenedor?
    docker exec zabbix-browser nslookup www.orangebox.cl
  1. ¿La IP corresponde al servicio correcto?

Muchas horas de troubleshooting se pierden buscando problemas en Zabbix cuando en realidad el navegador simplemente está pegándole al web equivocado.

Resumen de esta etapa

Hasta ahora tenemos:

  • Docker funcionando.
  • Selenium ejecutándose.
  • Zabbix conectado al Browser Poller.
  • Chrome listo para navegar.
  • Resolución DNS controlada.

Vamos que se puede! sólo hay que ser ordenado y entender el proceso, porque si no entienden el proceso va a estar difícil hacer esto de manera eficiente y correcta.

El siguiente paso será hacer que esta implementación sobreviva un reinicio del servidor y administrarla correctamente con systemd.

Porque si después de un reboot Selenium queda muerto, nadie quiere descubrirlo cuando ya existen alertas acumuladas.

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

Si cambiaste el archivo de hosts o de DNS en el contenedor, acuérdate de ponerlo también en este archivo. La idea es que la linea: “ExecStart=” sea igual a como arrancaste el contenedor que ya probaste y estás seguro que funciona.

Explicación del servicio

Dependencia Docker

Requires=docker.service

Le dice al sistema que tiene que esperar que el servicio Docker esté activo antes de iniciar el contenedor Selenium.

No tiene sentido intentar levantar un contenedor si Docker todavía no arrancó.

Orden de inicio

After=docker.service

Fuerza que Selenium arranque después del servicio Docker.

Esto evita problemas durante el boot.

Reinicio automático

Restart=always

Si el contenedor termina por cualquier motivo, systemd lo levantará nuevamente.

Ejemplos:

  • Chrome falla.
  • Selenium se cae.
  • Error interno del contenedor.
  • Problema temporal.

Tiempo entre reinicios

RestartSec=10

Evita que systemd entre en un ciclo agresivo de:

inicia
falla
inicia
falla
inicia
falla

Dándole unos segundos para estabilizar.

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

Revisar logs

Una ventaja de usar systemd es que los logs quedan integrados.

Ver últimos eventos:

journalctl -u zabbix-browser.service -n 50 --no-pager

Ver logs en vivo y en directo:

journalctl -u zabbix-browser.service -f

Esto es especialmente útil cuando Selenium tiene problemas iniciando Chrome.

Probar después de reinicio

Siempre que se instale un servicio nuevo hay que hacer la prueba de la blancura… “¿aguanta un reinicio?”:

reboot

Después del reinicio:

systemctl status zabbix-browser.service

Y validar Selenium:

curl http://localhost:4444/status

Debe responder:

"ready": true

Si después de un reinicio todo vuelve automáticamente, ya tenemos un servicio correctamente integrado.

Consideraciones sobre SELinux

En sistemas RHEL, Rocky Linux o AlmaLinux podemos encontrarnos con SELinux habilitado.

La mayoría de instalaciones Docker funcionan correctamente, pero cuando agregamos montajes como:

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

pueden aparecer restricciones.

Si existe un bloqueo, revisar:

ausearch -m AVC -ts recent

o:

journalctl -xe

No es recomendable desactivar SELinux como primera solución.

La práctica correcta es revisar qué está bloqueando y aplicar la política adecuada.

Seguridad del servicio Selenium

Un punto importante:

El puerto 4444 de Selenium no debería quedar expuesto públicamente.

Este puerto permite controlar un navegador.

No es un servicio pensado para Internet.

Recomendaciones:

  • Escuchar solamente en la red necesaria.
  • Filtrar con firewall.
  • No publicar 4444 hacia Internet. (Intra Intranet, no lo hagamos que tenga problemas de identidad como “Intra-Extra net”)
  • Permitir acceso solamente desde Zabbix.

Ejemplo usando firewall:

firewall-cmd --add-rich-rule='rule family="ipv4" source address="IP_ZABBIX" port port="4444" protocol="tcp" accept'

o:

iptables -A INPUT -p tcp -s IP_ZABBIX --dport 4444 -j ACCEPT

Monitorear el propio Selenium

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

Sí, suena un poco absurdo. (insertar el meme de los 3 SpiderMan apuntandose entre ellos)

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.

Estado actual de la implementación (¿ya llegamos?)

En este punto tenemos:

  • Docker instalado.
  • Selenium Chrome funcionando.
  • Zabbix Browser Pollers configurados.
  • Resolución DNS controlada.
  • Servicio persistente mediante systemd.
  • Reinicio automático.
  • Consideraciones básicas de seguridad.

Ahora falta la parte donde Zabbix empieza realmente a trabajar:

Crear los hosts, importar la plantilla Website by Browser y configurar las macros necesarias.

Porque Selenium puede estar perfecto…

pero si Zabbix no sabe qué sitio revisar ni cómo, solamente tendremos un Chrome muy engorroso de instalar y más encima, haciendo nada.

Importar y configurar la plantilla Website by Browser

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 contiene:

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

Pero hay un detalle importante:

Esta plantilla no está pensada para aplicarla sobre cualquier servidor existente.

La recomendación es crear hosts 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.

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.

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

Configuración
    |
    +-- Hosts
         |
         +-- WEB - srvweb.orangebox.cl - www.orangebox.cl
              |
              +-- Triggers

Editamos el trigger:

Website HTTP status is not 200

Vamos a la pestaña:

Dependencias

Agregamos:

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

Descargar plantilla oficial

La plantilla puede obtenerse desde el repositorio oficial de Zabbix.

Ejemplo:

curl -O https://git.zabbix.com/projects/ZBX/repos/zabbix/raw/templates/app/website_browser/template_website_browser.yaml?at=release/7.4

El archivo descargado será:

template_website_browser.yaml

Importar plantilla en Zabbix

Desde la interfaz web:

Configuración
    |
    +-- Plantillas
         |
         +-- Importar

Seleccionamos:

template_website_browser.yaml

y ejecutamos:

Importar

Si todo está correcto veremos la plantilla disponible.

Crear host para monitoreo web

Vamos a crear un host dedicado.

Ruta:

Configuración
    |
    +-- Hosts
         |
         +-- Crear host

Ejemplo:

Nombre del host:

www.orangebox.cl

Nombre visible:

www.orangebox.cl - Proxy reverso

Grupo:

Servicios Web

Interfaz del host

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

Configuramos:

Tipo:

Agente Zabbix

Dirección:

IP del servidor donde está disponible el agente

Ejemplo:

192.168.200.13

Puerto:

10050

¿Por qué?

Porque Zabbix necesita asociar el host a una entidad.

En este caso la interfaz es solamente una referencia.

El monitoreo real lo hará Selenium mediante Browser Pollers.

Asignar plantilla

En el host:

Plantillas vinculadas:

Website by Browser

Después guardamos.

Configuración mediante macros

La plantilla utiliza macros para saber qué sitio debe abrir.

Las principales son:

Dominio

{$WEBSITE.DOMAIN}

Ejemplo:

www.orangebox.cl

Esquema

{$WEBSITE.SCHEME}

Normalmente:

https

o:

http

Puerto

{$WEBSITE.PORT}

Ejemplo:

443

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:
Servicio


Valor:
Website

Otro:

Tag:
Entorno


Valor:
Produccion

Otro:

Tag:
Proxy


Valor:
ProxyReverso

Una estructura recomendada:

Servicio = Web
Aplicacion = PortalClientes
Entorno = Produccion
Tecnologia = 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 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

Primera validación

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

Vamos a:

Configuración

    Hosts

        www.orangebox.cl

            Items

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:

Monitoreo

    Últimos datos

Buscamos:

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.

Buscar:

website.screenshot

Si el item devuelve información binaria, Zabbix puede mostrar la captura.

Esto permite ver exactamente qué estaba viendo Chrome.

Una herramienta muy útil cuando alguien dice:

“El sitio funciona para mí”.

Bueno.

Veamos qué estaba viendo realmente el navegador.

Errores frecuentes en esta etapa

Los items aparecen sin datos

Revisar:

tail -100 /var/log/zabbix/zabbix_server.log

Buscar:

browser poller

Si no aparecen, revisar:

StartBrowserPollers

Error de conexión con Selenium

Probar:

curl http://localhost:4444/status

Si falla:

systemctl status zabbix-browser.service

La página abre pero falla la prueba

En este caso normalmente revisar:

  • DNS.
  • Certificado.
  • Red.
  • Tiempo de carga.
  • Recursos externos.

Estado actual

Hasta este punto tenemos:

  • Selenium funcionando.
  • Zabbix conectado.
  • Plantilla importada.
  • Hosts organizados.
  • Macros configuradas.
  • Primer monitoreo ejecutándose.

Ahora viene una de las partes más importantes para una implementación profesional:

Cómo automatizar alertas útiles y cómo interpretar correctamente los tiempos de carga.

Porque una alerta tipo:

“Página lenta”

sin contexto sirve bastante poco.

La idea es que Zabbix nos avise cuando existe un problema real, no cada vez que un sitio tarda medio segundo más.

Triggers, alertas inteligentes y visualización de Website by Browser

Tener métricas es bueno.

Tener demasiadas alertas inútiles es malo.

Una implementación profesional de Website by Browser no consiste solamente en saber que una página falló.

La idea es detectar degradación antes de llegar a una caída completa.

Porque normalmente una aplicación no pasa de:

“Perfecta”

a

“Completamente caída”

en un segundo.

Generalmente existe una historia antes:

  • Empieza a responder más lento.
  • Algunos recursos fallan.
  • Aumenta el tiempo de carga.
  • Aparecen errores intermitentes.
  • Finalmente alguien reporta el problema.

El objetivo es capturar esa historia.

¿Qué debemos monitorear?

Los principales indicadores de Website by Browser son:

Disponibilidad HTTP

Pregunta:

¿El sitio responde correctamente?

Ejemplos de estados problemáticos:

HTTP 500

HTTP 502

HTTP 503

Timeout

Este debería ser uno de los triggers principales.

Tiempo total de carga

Este es probablemente uno de los valores más interesantes.

Un sitio puede estar disponible pero lento.

Ejemplo:

HTTP 200

Tiempo carga:
18 segundos

Para Zabbix:

Todo está “verde”.

Para un usuario:

La página está rota.

Crear trigger de sitio caído

Un trigger básico podría ser:

Último valor HTTP diferente de 200

Ejemplo conceptual:

last(/www.orangebox.cl/website.status.code)<>200

Pero en ambientes reales conviene ser un poco más inteligente.

No todos los errores son iguales.

Diferenciar errores temporales

Internet tiene ruido.

Puede existir:

  • Una pérdida puntual.
  • Un timeout aislado.
  • Un reinicio de aplicación.
  • Un despliegue.

No queremos una alerta por cada pequeño problema.

Una regla más sana:

Alertar cuando ocurre durante varias comprobaciones.

Ejemplo:

Últimos 3 chequeos fallidos

Conceptualmente:

max(/host/item,3)=0

La idea:

Un fallo aislado no genera alarma.

Un patrón repetido sí.

Trigger de tiempo de carga elevado

Este es uno de los más útiles.

Ejemplo:

Supongamos:

Tiempo normal:

1.5 segundos

Problema:

10 segundos

Podemos crear:

Tiempo de carga mayor a 8 segundos durante 5 minutos

Ejemplo conceptual:

avg(/www.orangebox.cl/website.response.time,5m)>8

Esto permite detectar degradación.

No todos los sitios tienen el mismo umbral

Un error bastante común:

Crear el mismo trigger para todos.

Ejemplo:

Todo mayor a 5 segundos es problema

Pero no es igual:

Un blog:

5 segundos puede ser aceptable

Un sistema de pagos:

5 segundos puede ser crítico

Por eso es recomendable usar macros.

Usar macros para umbrales

Ejemplo:

Crear:

{$WEB.RESPONSE.TIME.MAX}

Valor:

5

Trigger:

avg(/host/website.response.time,5m)>{$WEB.RESPONSE.TIME.MAX}

Ventajas:

Cada host puede tener su propio valor.

Ejemplo:

Portal clientes:

{$WEB.RESPONSE.TIME.MAX}=3

Blog:

{$WEB.RESPONSE.TIME.MAX}=10

API:

{$WEB.RESPONSE.TIME.MAX}=1

Severidades recomendadas

Una estructura práctica:

Disaster

Sitio completamente caído.

Ejemplo:

No responde durante 5 minutos

High

Sitio responde pero con error.

Ejemplo:

HTTP 500

Warning

Degradación.

Ejemplo:

Tiempo carga superior al esperado

Information

Eventos menores.

Ejemplo:

Cambio de comportamiento

Tags en triggers

Los tags permiten automatizar acciones.

Ejemplo:

Trigger:

Website unavailable

Tags:

Servicio = Web

Tipo = Disponibilidad

Aplicacion = PortalClientes

Luego podemos crear acciones:

Si:

Servicio = Web

Severidad >= High

Entonces:

Enviar alerta al equipo web.

Crear dashboard de monitoreo web

Una de las ventajas de Website by Browser es que los datos son muy visuales.

Un dashboard recomendado:

Widget de estado

Mostrar:

  • Sitios OK.
  • Sitios con problemas.
  • Sitios lentos.

Tiempo de respuesta

Gráfico:

Response time

Permite ver tendencias.

Ejemplo:

Semana normal:

1-2 segundos

Después de un cambio:

8-10 segundos

Algo cambió.

Disponibilidad histórica

Mostrar:

SLA mensual

Ejemplo:

Últimos 30 días

Esto es muy útil para:

  • Clientes.
  • Reportes internos.
  • Gestión.

Últimos problemas

Widget:

Problems

Filtrado por:

Tag:
Servicio=Web

Así evitamos mezclar problemas de servidores con problemas de aplicaciones web.

Capturas de pantalla como evidencia

Una función muy potente es utilizar screenshots.

Ejemplo:

Trigger:

Sitio no carga

Zabbix genera:

Captura del navegador

Cuando llega la alerta podemos ver:

  • Página en blanco.
  • Error de aplicación.
  • Certificado inválido.
  • Login fallando.

Esto reduce muchísimo el tiempo de diagnóstico.

Ejemplo de alerta profesional

Una alerta útil debería entregar contexto.

Ejemplo:

Problema:
Sitio web no disponible


Host:
www.orangebox.cl


Estado:
HTTP 503


Tiempo respuesta:
12.4 segundos


Última captura:
disponible

Mucho mejor que:

Web down

Evitar falsos positivos

Algunas recomendaciones:

No alertar por un solo fallo

Internet falla.

Un paquete perdido no significa caída.

Considerar mantenimientos

Si existe una ventana:

Domingo 02:00 - 04:00

Configurar mantenimiento en Zabbix.

Separar disponibilidad y rendimiento

No mezclar:

Página caída

con:

Página lenta

Son problemas diferentes.

Uno requiere recuperación inmediata.

El otro requiere análisis.

Estado actual

Ahora tenemos:

  • Sitios monitoreados.
  • Métricas reales.
  • Triggers definidos.
  • Alertas útiles.
  • Dashboards preparados.

Pero todavía falta una pieza importante:

¿Qué ocurre cuando esto crece?

¿Qué pasa si tenemos 50, 100 o 500 sitios monitoreados?

Ahí aparecen problemas de capacidad, cantidad de navegadores simultáneos y consumo de recursos.

La siguiente parte será:

Escalabilidad y ajustes para ambientes grandes con Website by Browser

Escalabilidad y ajustes para ambientes grandes con Website by Browser

Hasta ahora tenemos una implementación funcional:

  • Zabbix Server.
  • Selenium Chrome.
  • Browser Pollers.
  • Sitios monitoreados.
  • Alertas configuradas.

Para pocos sitios esto funciona perfectamente.

Pero cuando la cantidad de pruebas aumenta, aparecen nuevas preguntas:

¿Cuántos sitios puedo monitorear con un solo Selenium?

¿Cuántos Browser Pollers necesito?

¿Cuánta memoria consume Chrome?

¿Conviene separar Selenium del servidor Zabbix?

La respuesta depende del tamaño de la plataforma.

El costo real de un navegador

Una prueba con Website by Browser no es solamente una consulta HTTP.

Cada ejecución implica:

  1. Crear una sesión Selenium.
  2. Iniciar o reutilizar Chrome.
  3. Resolver DNS.
  4. Abrir conexiones.
  5. Descargar recursos.
  6. Ejecutar JavaScript.
  7. Procesar la página.
  8. Entregar resultados a Zabbix.

Es decir:

No estamos haciendo un simple ping.

Estamos levantando un navegador.

Y los navegadores consumen recursos.

Consumo aproximado

Los valores pueden variar bastante dependiendo del sitio, pero como referencia:

Sitios simples:

CPU:
Bajo

RAM:
200-500 MB por sesión

Aplicaciones modernas:

CPU:
Medio/alto

RAM:
500 MB - 1 GB o más

Una página con:

  • Framework frontend.
  • Muchos scripts.
  • Videos.
  • Mapas.
  • Publicidad.
  • Integraciones externas.

Puede aumentar bastante el consumo.

Ajustar cantidad de Browser Pollers

El parámetro principal es:

StartBrowserPollers

Ejemplo:

StartBrowserPollers=5

significa:

Cinco procesos disponibles para ejecutar pruebas simultáneas.

Pero aumentar este valor sin pensar puede empeorar las cosas.

Más pollers significa:

  • Más navegadores.
  • Más CPU.
  • Más memoria.
  • Más conexiones.

No siempre más es mejor.

Cómo calcular una primera aproximación

Supongamos:

Tenemos:

50 sitios

Cada sitio ejecuta:

cada 60 segundos

Y cada prueba tarda:

5 segundos

En un minuto tenemos:

50 pruebas

Tiempo total:

50 x 5 segundos

=

250 segundos de trabajo por minuto

Un solo proceso no alcanza.

Necesitamos concurrencia.

Una aproximación inicial:

Browser Pollers:
5-10

Luego ajustamos mirando:

  • Cola de Zabbix.
  • Uso CPU.
  • Memoria.
  • Tiempo de ejecución.

Revisar cola de Zabbix

Zabbix tiene una herramienta fundamental:

La cola.

Ruta:

Administración

    Cola

Si aparecen muchos elementos atrasados:

browser poller

significa que las pruebas están esperando ejecución.

Eso indica:

  • Falta de Browser Pollers.
  • Selenium lento.
  • Sitios demasiado pesados.
  • Frecuencia demasiado agresiva.

Separar Selenium del servidor Zabbix

Cuando la cantidad de sitios aumenta, una buena práctica es separar componentes.

Arquitectura pequeña:

Zabbix Server

      |

      |

Selenium Docker

Arquitectura más grande:

Zabbix Server

      |

      |

Selenium Server 1

      |

Selenium Server 2

      |

Selenium Server 3

Ventajas:

  • Distribuir carga.
  • Evitar saturar Zabbix.
  • Escalar horizontalmente.
  • Administrar recursos independientes.

Selenium dedicado

Un servidor dedicado para Selenium debería tener:

  • CPU suficiente.
  • Memoria RAM disponible.
  • Red estable.
  • Docker actualizado.

Ejemplo:

Servidor Selenium:

CPU:
8 cores


RAM:
16 GB


Docker:
Varios contenedores Chrome

Ejecutar múltiples instancias Selenium

Para ambientes grandes podemos ejecutar varias instancias.

Ejemplo:

selenium-node-01

selenium-node-02

selenium-node-03

Cada uno atiende una parte de las pruebas.

La distribución dependerá de la arquitectura Zabbix utilizada.

Frecuencia de monitoreo

No todos los sitios necesitan revisarse cada minuto.

Un error común es configurar todo agresivamente.

Ejemplo:

Todos los sitios:
cada 10 segundos

Resultado:

Una montaña de pruebas innecesarias.

Una estrategia más lógica:

Servicios críticos

Ejemplo:

Banco.
Ecommerce.
Portal clientes.

Frecuencia:

1 minuto

Servicios importantes

Ejemplo:

Sitios corporativos.

Frecuencia:

5 minutos

Servicios informativos

Ejemplo:

Blogs.
Sitios secundarios.

Frecuencia:

10-15 minutos

Cuidado con pruebas demasiado frecuentes

Un navegador automatizado genera tráfico real.

Si configuramos demasiadas pruebas podemos:

  • Generar carga artificial.
  • Activar sistemas antifraude.
  • Saturar aplicaciones.
  • Generar falsos positivos.

El monitoreo debe observar el servicio.

No convertirse en otro problema.

Optimización de sitios monitoreados

Algunas recomendaciones:

Evitar páginas innecesariamente pesadas

Una página principal con:

  • Videos automáticos.
  • Muchas imágenes.
  • Scripts externos.

Será más costosa de monitorear.

Usar URLs específicas

No siempre necesitamos la portada.

Ejemplo:

En un ecommerce:

/

puede ser menos útil que:

/login

o:

/checkout

Depende del servicio crítico.

Monitorear desde diferentes ubicaciones

Una mejora avanzada es tener Selenium en distintas redes.

Ejemplo:

Chile

Estados Unidos

Europa

¿Por qué?

Porque un servicio puede funcionar perfecto desde una ubicación y fallar desde otra.

Esto ayuda a detectar:

  • Problemas CDN.
  • Problemas DNS regionales.
  • Problemas de proveedores.

Mantener actualizado Selenium

Chrome cambia constantemente.

Conviene mantener:

  • Imagen Docker actualizada.
  • Chrome actualizado.
  • Zabbix actualizado.

Pero siempre probando primero.

Actualizar producción directamente un viernes a las 18:00 es una tradición que conviene evitar.

Indicadores que debemos vigilar

No solamente monitoreamos sitios.

También debemos monitorear la plataforma de monitoreo.

Revisar:

Zabbix

  • Queue.
  • Procesos internos.
  • Browser Pollers.

Docker

docker stats

Sistema operativo

  • CPU.
  • RAM.
  • Disco.
  • Red.

Selenium

curl http://localhost:4444/status

Arquitectura recomendada para producción

Una implementación profesional podría quedar así:

Usuarios

    |

    |

Aplicaciones Web


    |

    |

Selenium Nodes


    |

    |

Zabbix Server

Separando:

  • Recolección.
  • Ejecución.
  • Almacenamiento.
  • Visualización.

Estado actual

A esta altura tenemos una plataforma bastante completa:

  • Monitoreo sintético real.
  • Navegación con Chrome.
  • Métricas de experiencia.
  • Alertas inteligentes.
  • Escalabilidad considerada.

Pero todavía falta revisar una parte crítica:

Cuando algo falla, ¿cómo investigamos?

Porque una buena plataforma no solamente debe detectar problemas.

También debe ayudarnos a resolverlos rápido.

La siguiente sección será:

Troubleshooting avanzado de Website by Browser con Zabbix y Selenium

Troubleshooting avanzado de Website by Browser con Zabbix y Selenium

Una plataforma de monitoreo solamente es útil cuando podemos confiar en ella.

Si Website by Browser falla, el objetivo no es solamente arreglar la alerta.

El objetivo es entender dónde está ocurriendo el problema.

La cadena completa tiene varios componentes:

Zabbix
   |
   |
   v
Browser Poller
   |
   |
   v
Selenium
   |
   |
   v
Chrome
   |
   |
   v
Sitio Web

Un problema en cualquiera de estos puntos puede terminar mostrando síntomas similares.

Por eso vamos a revisar los casos más comunes.

Problema: Selenium no responde

Síntoma:

Los items de Website by Browser quedan sin datos.

Los Browser Pollers existen, pero las pruebas nunca terminan.

Primera validación:

curl http://localhost:4444/status

Respuesta esperada:

"ready": true

Si no responde:

Revisar contenedor:

docker ps | grep zabbix-browser

Si no aparece:

docker start zabbix-browser

Revisar logs de Selenium

Los logs del navegador entregan mucha información.

Ejecutar:

docker logs zabbix-browser

Buscar errores como:

session not created

Chrome failed to start

out of memory

disconnected

Problema: Chrome se cierra inmediatamente

Este es uno de los clásicos.

El contenedor está arriba, Selenium responde, pero las pruebas fallan.

Muchas veces el problema es memoria compartida.

Chrome utiliza:

/dev/shm

Si el contenedor fue creado sin:

--shm-size

pueden aparecer errores difíciles de entender.

Revisar:

docker inspect zabbix-browser | grep ShmSize

La recomendación:

--shm-size=2g

Para páginas pesadas incluso puede necesitar más.

Problema: Browser Pollers no aparecen

Síntoma:

Zabbix muestra errores relacionados con browser monitoring.

Revisar configuración:

vim /etc/zabbix/zabbix_server.conf

Confirmar:

StartBrowserPollers=5

Después:

systemctl restart zabbix-server

Validar logs:

grep browser /var/log/zabbix/zabbix_server.log

Debemos ver procesos similares a:

started [browser poller #1]

Problema: Zabbix no puede conectarse a Selenium

Síntoma:

Error:

Cannot connect to WebDriver

Primero validar desde el mismo servidor Zabbix:

curl http://localhost:4444/status

Si funciona:

El problema probablemente está en la configuración Zabbix.

Revisar:

WebDriverURL=http://localhost:4444

Errores típicos:

Incorrecto:

WebDriverURL=https://localhost:4444

Correcto:

WebDriverURL=http://localhost:4444

Problema: DNS diferente dentro del contenedor

Uno de los más comunes.

Desde Zabbix:

dig www.ejemplo.cl

Entrega:

192.168.1.20

Pero desde Selenium:

docker exec zabbix-browser nslookup www.ejemplo.cl

Entrega:

200.50.10.20

Tenemos una diferencia.

El navegador está llegando a otro lugar.

Solución:

  • Revisar DNS.
  • Usar DNS interno.
  • Configurar hosts personalizado.
  • Revisar split DNS.

Problema: certificado SSL inválido

Síntoma:

Chrome muestra:

NET::ERR_CERT_AUTHORITY_INVALID

Causas comunes:

  • Certificado firmado por CA interna.
  • Cadena incompleta.
  • Certificado vencido.
  • Dominio incorrecto.

No es recomendable desactivar validación SSL.

La solución correcta:

  • Instalar CA interna.
  • Corregir cadena.
  • Renovar certificado.

Validar desde Selenium:

docker exec zabbix-browser curl -Iv https://sitio.cl

Problema: la página carga manualmente pero falla Selenium

Este caso es muy común.

Usuario:

“Desde Chrome funciona”.

Selenium:

“Falla”.

¿Por qué?

Porque Selenium navega de forma automatizada.

Puede encontrarse con:

  • Redirecciones.
  • Cookies.
  • WAF.
  • Captchas.
  • Protección antibots.

Revisar:

  • Logs de aplicación.
  • Logs del firewall.
  • Logs del proxy reverso.

Problema: timeout cargando página

Síntoma:

La prueba inicia pero nunca termina.

Causas:

  • Página demasiado pesada.
  • Recursos externos lentos.
  • API bloqueada.
  • JavaScript esperando respuesta.

Revisar:

Chrome manualmente.

Si la página demora 30 segundos para un humano, Selenium no tiene magia.

La aplicación tiene un problema.

Problema: captura de pantalla vacía

Síntoma:

Zabbix genera screenshot pero aparece blanco.

Posibles causas:

Página todavía cargando

Aumentar tiempos.

JavaScript bloqueado

Revisar consola del navegador.

Error de sesión

Reiniciar Selenium:

systemctl restart zabbix-browser.service

Problema: demasiados procesos Chrome

Síntoma:

El servidor empieza a quedarse sin memoria.

Revisar:

docker stats zabbix-browser

También:

ps aux | grep chrome

Si aparecen demasiados procesos:

Revisar:

  • Cantidad de Browser Pollers.
  • Frecuencia de pruebas.
  • Sitios demasiado pesados.

Problema: Docker está funcionando pero Selenium no

A veces Docker dice:

Up

pero la aplicación interna está mal.

Reiniciar:

docker restart zabbix-browser

Esperar:

sleep 10

Validar:

curl http://localhost:4444/status

Método de diagnóstico recomendado

Cuando una prueba falla, seguir siempre este orden:

Paso 1

¿Zabbix está ejecutando Browser Pollers?

grep browser /var/log/zabbix/zabbix_server.log

Paso 2

¿Selenium responde?

curl http://localhost:4444/status

Paso 3

¿El contenedor resuelve DNS?

docker exec zabbix-browser nslookup dominio.cl

Paso 4

¿Chrome puede navegar?

Usar acceso VNC:

http://IP_SERVIDOR:7900

Paso 5

¿El problema está en la aplicación?

Revisar:

  • Logs web.
  • Logs aplicación.
  • Proxy reverso.
  • Firewall.

Regla de oro del troubleshooting

No asumir.

Medir.

Una gran cantidad de problemas con Website by Browser terminan siendo:

  • DNS incorrecto.
  • Certificado.
  • Proxy.
  • Firewall.
  • Aplicación lenta.

No necesariamente Zabbix.

Estado actual

Ya tenemos:

  • Instalación completa.
  • Arquitectura explicada.
  • Selenium funcionando.
  • Monitoreo configurado.
  • Alertas.
  • Escalabilidad.
  • Diagnóstico.

Nos queda cerrar la guía con una última parte:

Buenas prácticas finales, resumen de arquitectura, comandos útiles y CTA Orangebox

Buenas prácticas finales para Website by Browser en producción

Después de implementar Website by Browser con Zabbix y Selenium, tenemos una plataforma capaz de validar algo mucho más importante que un simple “ping”:

La experiencia real de un usuario.

Pero como cualquier componente de infraestructura, necesita mantenimiento.

Un monitoreo confiable depende de que la propia plataforma de monitoreo sea confiable.

Checklist de implementación

Antes de pasar a producción, validar:

Zabbix

Confirmar:

Browser Pollers activos

WebDriverURL configurado correctamente

Sin errores en zabbix_server.log

Validar:

grep browser /var/log/zabbix/zabbix_server.log

Selenium

Confirmar:

Contenedor activo

Comando:

docker ps

Validar:

curl http://localhost:4444/status

Debe responder:

ready: true

Docker

Revisar consumo:

docker stats zabbix-browser

Controlar:

  • CPU.
  • Memoria.
  • Reinicios.
  • Consumo creciente.

DNS

Validar siempre desde Selenium:

docker exec zabbix-browser nslookup dominio.cl

No asumir que porque funciona en el servidor Zabbix funcionará igual dentro del navegador.

Certificados

Revisar:

  • Vigencia.
  • Cadena completa.
  • Autoridad certificadora.
  • Nombre del dominio.

Un certificado válido para un navegador humano también debe ser válido para el navegador automatizado.

Comandos útiles de administración

Estado del contenedor

docker ps

Reiniciar Selenium

docker restart zabbix-browser

Ver logs

docker logs zabbix-browser

En tiempo real:

docker logs -f zabbix-browser

Estado del servicio systemd

systemctl status zabbix-browser.service

Reiniciar servicio completo

systemctl restart zabbix-browser.service

Ver eventos del servicio

journalctl -u zabbix-browser.service -f

Probar Selenium manualmente

curl http://localhost:4444/status

Recomendaciones operacionales

Documentar los sitios monitoreados

Mantener información como:

Nombre:
Portal clientes


URL:
https://clientes.empresa.cl


Responsable:
Equipo aplicaciones


Criticidad:
Alta

Esto parece algo básico, pero evita perder tiempo cuando llega un incidente.

No monitorear solamente la portada

Muchas veces la portada funciona perfectamente mientras la parte importante está caída.

Ejemplos:

En un ecommerce:

/

puede estar funcionando.

Pero:

/checkout

puede estar roto.

En un portal:

/

puede cargar.

Pero:

/login

puede fallar.

El monitoreo debe apuntar al negocio, no solamente a una página bonita.

Revisar tendencias, no solamente alarmas

Una de las mayores ventajas de Zabbix es la información histórica.

No esperar solamente una caída.

Revisar:

  • Aumento progresivo de tiempos.
  • Cambios después de despliegues.
  • Degradaciones periódicas.
  • Diferencias entre horarios.

Un sistema lento normalmente avisa antes de morir.

El problema es que muchas veces nadie estaba mirando.

Mantener separado monitoreo y operación

Una buena arquitectura evita mezclar:

Servidores productivos:

web01
db01
app01

Con servicios monitoreados:

website-clientes
website-api
website-publico

Esto permite:

  • Alertas más limpias.
  • Dashboards más claros.
  • Administración más sencilla.

Arquitectura final recomendada

Una implementación ordenada queda así:

Usuarios

    |

    |

Aplicaciones Web


    |

    |

Selenium Chrome

    |

    |

Zabbix Browser Pollers

    |

    |

Zabbix Server

    |

    |

Dashboards + Alertas + Reportes

Cada componente tiene una función clara.

Eso facilita mantener la plataforma y solucionar problemas rápidamente.

Conclusión

El monitoreo tradicional responde una pregunta básica:

“¿El servidor está vivo?”

Website by Browser responde una pregunta mucho más importante:

“¿El servicio realmente funciona para quien lo necesita?”

Esa diferencia parece pequeña, pero cambia completamente la forma de administrar servicios críticos.

Un sitio puede tener todos sus servidores funcionando y aun así estar entregando una mala experiencia.

Con Zabbix 7.4, Selenium y Docker podemos construir una plataforma de monitoreo sintético capaz de detectar problemas antes de que lleguen como un reclamo de usuario.

Porque el mejor incidente es el que se detecta antes de que alguien tenga que reportarlo.

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