Falsas alarmas HighErrorRate por el 501 deliberado de SpinetiX WebDAV

Cuándo

Ráfagas horarias detectadas la noche del 21 al 22 de agosto de 2026. Corregido el 22-08-2026 en el commit ccca1cf6 (PR #417), parte de la versión v1.81.2.

Síntomas visibles

La alerta HighErrorRate (definida en observability/victoriametrics/alerts.yml) saltaba en PROD en horas concretas — a la hora en punto —, con poco tráfico real detrás. Ruido recurrente sin incidente de negocio real.

Causa raíz

El reproductor SpinetiX sondea por WebDAV el endpoint público de publish de signage (/publish/<token>/) con peticiones OPTIONS/PROPFIND. CreaRack responde a propósito con 501 Not Implemented para forzar al player a caer al fallback spx-listing.xml (ver signage/views_publish.publish_root) — el 501 es la respuesta correcta del protocolo, no un fallo.

Un player con un token viejo repetía este sondeo en ráfaga a la hora en punto. Con poco tráfico real en ese momento, el ratio de 5xx superaba el 5% que dispara HighErrorRate. Dos causas encadenadas:

1. La expresión PromQL de HighErrorRate contaba el 501 como cualquier otro 5xx, sin excepción.
2. El filtro de logs SpinetiXWebDAVProbeFilter (core/logging_filters.py) solo reconocía la ruta /signage/publish/, pero el tráfico real de los players llega por el alias corto /publish/<token>/ — así que ni siquiera se limpiaba el ruido en los logs.

Fix aplicado

Commit ccca1cf6b4a06d0df0c5e5b6a6f1d459c40a916e (PR #417, v1.81.2):

• observability/victoriametrics/alerts.yml: la expresión de HighErrorRate excluye explícitamente status!="501" del numerador.
• core/logging_filters.py: el regex y el prefijo de ruta del filtro cubren ahora las DOS rutas (/publish/ y /signage/publish/).
• tests/test_logging_filters.py: +2 tests que cubren el alias corto.

Lecciones

• Un 501 “a propósito” (parte del protocolo, no un fallo) puede disparar alarmas genéricas de error-rate si la regla no lo excluye explícitamente.
• Cuando un endpoint tiene un alias de ruta (aquí /publish/ como atajo de /signage/publish/), cualquier filtro o regla que dependa del path debe cubrir TODOS los alias, no solo la ruta “canónica” — el bug estaba latente porque el filtro se escribió mirando solo la ruta larga.

Preventivos futuros

Si se añaden más respuestas HTTP “deliberadas pero no-2xx” (otros protocolos de sondeo de players, por ejemplo), replicar el patrón: excluir el status code específico tanto en la regla PromQL como en el filtro de logs, y cubrir todos los alias de ruta del endpoint.

Véase también

• [[crearack-tech—observability—alarmas-prod]]
• [[entity—observability—service—vmalert]]
• [[feature—observability—alerting-prod-s95]]
• [[crearack-tech—backend—spinetix-integration]]
• [[concept—signage—deployment]]
• [[entity—observability—service—alertmanager]]