Monitoreo y alertas de Q-SYS core
Actualizado el 11 de agosto de 2026.
Propósito
La VM del portal de producción monitorea continuamente los Q-SYS cores del Auditorio y del Cuarto Oscuro. El listener detecta interrupciones reales, recuperaciones, reinicios, implementaciones de nuevos diseños y reimplementaciones del mismo diseño sin depender de una consulta cada minuto que puede omitir cambios de estado breves.
El monitor es una red de seguridad operativa. No cambia un diseño de Q-SYS, controla un core ni reinicia automáticamente el equipo AV.
Arquitectura de producción
- Unidad Systemd:
qsys-core-watch.service - Proceso:
scripts/qsys-core-listen.phpen la versión del portal de producción - Protocolo: conexiones QRC persistentes con el tiempo de actividad SNMP como evidencia independiente de reinicio
- Tabla de estado:
logs.qsys_core_state - Tabla de eventos de solo anexión:
logs.qsys_core_events - Transporte de alertas: la configuración de correo protegida del portal
- Ruta de alerta predeterminada: personal de tecnología de River Oaks;
QSYS_ALERT_TOpuede proporcionar una anulación protegida explícita
El listener rastrea cada core de forma independiente. Una falla en un core no hace que el otro core no esté en buen estado.
Reglas de eventos
| Evento | Regla | Correo electrónico |
|---|---|---|
| Implementación de diseño | La identidad del diseño cambia después de la ventana de asentamiento | Sí |
| Reimplementación del mismo diseño | El mismo diseño se detiene y se inicia sin una nueva identidad | Sí |
| Desconectado | La inalcanzabilidad continua excede el umbral de desconexión configurado | Sí |
| En línea | Un core previamente desconectado se reconecta | Solo registro de auditoría |
| Reinicio | El tiempo de actividad SNMP se reinicia, o la recuperación proporciona evidencia equivalente de reinicio | Sí |
La ventana de asentamiento predeterminada es de 30 segundos y el umbral de desconexión predeterminado es de 120 segundos. Esto evita que una implementación de diseño ordinaria genere una secuencia falsa de desconexión/reinicio. No reduzca el umbral de desconexión por debajo de la ventana de asentamiento.
Registro y pista de auditoría
qsys_core_state almacena una fila actual por core: etiqueta amigable, alcanzabilidad, recuento de fallas consecutivas, identidad de diseño actual, tiempo de actividad SNMP, último contacto exitoso y hora de actualización.
qsys_core_events es de solo anexión. Registra el core, el tipo de evento, la identidad de diseño antigua/nueva cuando sea relevante, metadatos de plataforma/estado, evidencia limitada y hora de detección. Utilice consultas agregadas para verificaciones de estado de rutina; no pegue detalles de diseño ni credenciales de correo en los tickets.
El journal de systemd contiene diagnósticos de conexión, keepalive, transición de estado, reintento, base de datos y entrega de correo. Se esperan keepalives exitosos en estado estable. Las fallas de conexión repetidas para un core deben corresponder a su recuento de fallas y, después del umbral, a un evento de desconexión en lugar de correos de alerta repetidos.
Verificación de estado de rutina
En la VM del portal:
systemctl status qsys-core-watch.service --no-pager
journalctl -u qsys-core-watch.service --since "30 minutes ago" --no-pager
En buen estado significa:
- la unidad está habilitada y activa;
- el listener de PHP tiene un proceso de larga duración;
- cada core esperado tiene actividad reciente de keepalive o reconexión;
qsys_core_state.reachablees1y su recuento de fallas es0;- no aparecen errores de base de datos o entrega de correo en el journal.
La fuente rastreada incluye un modo de simulación que se conecta a los cores e imprime las acciones previstas sin escrituras en la base de datos ni correos electrónicos:
sudo -u www-data env APP_ENV=production \
php /usr/share/nginx/portal/scripts/qsys-core-listen.php --dry-run
No ejecute la simulación durante un período prolongado junto a la producción. Crea conexiones QRC adicionales y está destinada solo a un diagnóstico limitado.
Guía de respuesta
Unidad detenida o fallida
- Lea las últimas entradas del journal antes de reiniciar.
- Verifique que la versión de producción y el entorno protegido estén presentes.
- Confirme que los nombres de las variables de base de datos y de correo existen sin imprimir sus valores.
- Inicie la unidad una vez y confirme que las conexiones de ambos cores se estabilizan.
- Si falla nuevamente, deje la evidencia intacta y escale en lugar de usar un bucle de reinicio.
Un core está desconectado
- Confirme que el otro core permanece en buen estado.
- Verifique el conmutador, VLAN, alimentación y el propio core antes de cambiar el monitor.
- Compare la transición del journal con la marca de tiempo del evento de solo anexión.
- Después de la recuperación, verifique un registro de auditoría en línea y la fila de estado actual.
Ambos cores están desconectados
Trate esto primero como una falla compartida de red, puerta de enlace, alimentación o ruta del host del portal. Verifique las dependencias compartidas antes de tocar el diseño de Q-SYS.
Evento registrado pero falta el correo electrónico
- Confirme que existe la fila del evento.
- Verifique el journal en la misma marca de tiempo para ver un error HTTP o de red de MailerSend limitado.
- Verifique solo la presencia y los metadatos del archivo de las variables de correo protegidas.
- Utilice la ruta de prueba de humo de correo del portal aprobada; nunca imprima ni copie la credencial de la API en un comando de shell o ticket.
Seguridad de cambios
- Mantenga el listener persistente y el sondeo de minutos heredado mutuamente excluyentes; ejecutarlos ambos duplicaría las transiciones de estado.
- Conserve la relación asentamiento/desconexión al ajustar los umbrales.
- Aplique los cambios de esquema de forma aditiva y conserve el historial de eventos de solo anexión.
- Pruebe los cambios de la máquina de estados con simulación y pruebas automatizadas antes de la producción.
- Nunca simule una interrupción durante un servicio ni reinicie un core únicamente para probar una alerta.