NETMON consulta cada treinta segundos los routers y el controlador de WiFi de un despliegue de evento, guarda lo que mide, avisa cuando algo cambia y deja un informe al cerrar. Esta página describe qué mide, qué detecta y cómo está armado.
Qué mide
Todo por consulta: nada se interpone en el camino del tráfico ni escribe en la configuración de los equipos.
Sondas periódicas hacia afuera, independientes de lo que informe el router. Si el enlace se degrada, se sabe que es el enlace y no la WiFi — que es la discusión que siempre aparece y que con los contadores del router solo no se cierra.
Receptor propio: los equipos mandan sus logs y quedan guardados y consultables. Lo grave se convierte en aviso; lo que no se pudo atribuir a un equipo del inventario nunca alerta, porque syslog es UDP sin autenticar y cualquiera en la red podría mandar una línea.
Qué detecta
Cada problema avisa una vez y vuelve a avisar sólo si cambia de estado: cambia la severidad, cambia el alcance, o se resolvió y volvió. El valor medido no cuenta como estado nuevo — la ocupación de un canal va de 87% a 89% y a 86% entre ciclos, y tomarla como cambio sería repetir el mismo aviso toda la noche.
11 APs desconectados del controller Los caídos a la vez se agrupan en un solo mensaje: un corte de energía por sector tira toda una zona junta, y once mensajes iguales informan peor que uno.
Canal 5 GHz saturado al 91% (ch 132) Sólo si la radio informa en qué canal está. Un AP que informa canal 0 no está midiendo, y alertar sobre eso sería afirmar algo que nadie midió.
El enlace perdió 50% de las sondas hacia internet Medido por las sondas propias, no por lo que diga el router sobre su interfaz.
Pool dhcpTrunk al 92% — 101 de 110 direcciones El pool agotado es la falla más visible para el público y la que más tarde se nota a ojo.
El puerto 11 negoció 100 Mbps y debería ir a 1 Gbps — PowerBeam E16 Dice qué hay enchufado, cuando el controlador lo identifica: un puerto a 100 Mbps con una cámara colgando está bien así.
Router a 61 °C Con la temperatura de placa real, en los modelos que la exponen. Los que no tienen sensor no informan cero: no informan.
Volvieron 4 APs Sin este aviso, la última alerta de un equipo que se levantó solo queda como si siguiera caído.
El evento
Al cerrar
Se generan solos. El informe sale por correo al cerrar el evento, con enlace a la página del informe y un documento editable adjunto.
Qué pasó cada noche de show, con los incidentes y cómo se resolvieron. El montaje se informa aparte y en general: mezclarlos daría un promedio de la semana que no describe ninguna de las dos cosas.
Lo que no se midió va en guión y no en cero. Un cero es una medición y afirma algo —"no había nadie conectado"—; un guión dice que no hay dato. De los pools de DHCP se listan los que estuvieron en uso, no los setenta y siete configurados.
Se arma solo durante el montaje: cada equipo que aparece queda anotado con su modelo y la primera y última vez que se lo vio. No se deduce de las mediciones, que se podan a las 48 horas — un AP instalado el primer día y apagado después sigue constando. Exportable a Excel.
Arquitectura
Corre en el predio y mide contra los equipos por la red local. Sigue midiendo y alertando con el enlace a internet caído, que es justo cuando más falta hace. Su base es SQLite y poda lo ya sincronizado a las 48 horas: el colector se desarma con el evento.
Recibe de cada colector y guarda todo sin podar: es el único lugar donde el historial sobrevive entre eventos, y comparar una edición con la anterior necesita más de un año de historia. Sobre PostgreSQL. El informe se arma y se manda desde acá, y sólo después de que el cierre del evento terminó de sincronizar.
Consulta las API de administración de los equipos y la del controlador de WiFi. No está en el camino del tráfico, no cambia configuración de red y no puede dejar sin servicio lo que está mirando.
El tablero funciona en el teléfono porque es desde donde se mira cuando estás caminando el predio. Y tiene un modo de pantalla completa para dejarlo en un monitor del NOC.
Preguntas frecuentes
Routers, switches y puntos de acceso de la red del evento, por las API de administración de los equipos y del controlador de WiFi. Lee y registra: no se interpone en el camino del tráfico ni cambia la configuración de la red.
El colector corre dentro del predio y mide contra los equipos por la red local, así que sigue midiendo y alertando con el enlace caído. Cuando el enlace vuelve, sincroniza contra el núcleo lo que registró mientras tanto.
Puntos de acceso desconectados del controlador, canales saturados, pools de DHCP por agotarse, routers con temperatura o memoria comprometidas, puertos que negociaron por debajo de su velocidad esperada y caídas del enlace a internet. Los avisos salen por Telegram y por correo.
Cada problema avisa una vez y vuelve a avisar sólo si cambia de estado: cambia la severidad, cambia el alcance, o el problema se resolvió y volvió. El valor medido no cuenta como cambio de estado, porque la ocupación de un canal fluctúa de un ciclo al otro. Durante el montaje las alertas de punto de acceso caído quedan silenciadas y se encienden solas dos horas antes de cada jornada de show.
El calendario del evento se carga con la fecha de montaje y una jornada por cada día de show. Durante el montaje se cortan sectores de energía a propósito, así que un punto de acceso apagado no es un incidente; durante el show, sí. Tanto las alertas como el informe entienden esa diferencia.
El comportamiento de la red separado por jornada, los incidentes con su resolución, el uso del enlace a internet, la ocupación de los pools de DHCP realmente en uso y el listado de equipos desplegados. Se genera y se envía solo al cerrar el evento, con enlace al informe y documento editable.
Solo, mientras se despliega. Cada ciclo de medición anota los equipos que ve, con su modelo y la primera y la última vez que aparecieron. No se deduce de las mediciones, que se podan a las 48 horas, sino que se acumula en su propia tabla: un punto de acceso instalado el primer día del montaje y apagado después sigue constando en el listado.
Sobre la ocupación total del canal y la parte de esa ocupación que genera el propio punto de acceso, separadas. Un canal al 80% del que somos el 70% es saturación propia y se corrige con más equipos o más espectro; uno al 80% del que somos el 20% es interferencia ajena, y agregar equipos lo empeora. Con un solo número los dos casos se ven iguales.
Contacto
Escribinos y te contamos cómo se monta el monitoreo sobre un despliegue concreto. Contestamos a la dirección que dejes.