Un incidente que nunca cierra por silencio

Todo sistema de monitorización acaba enfrentándose a la misma pregunta con un disfraz ligeramente distinto: ¿qué se hace cuando dejan de llegar las mediciones?

La respuesta tentadora es tratarlo como una recuperación. Ya no falla nada, la fila roja desaparece, el panel está tranquilo. Es también la mentira más cara que puede contar el sistema, porque el momento en que se deja de poder mirar algo es exactamente el momento en que no se puede afirmar que está bien.

Este es el diseño al que llegamos para los incidentes, y casi todo él consiste en mantener «hemos medido que está roto», «hemos medido que está arreglado» y «ahora mismo no lo vemos» como tres afirmaciones separadas que nunca se convierten sin ruido la una en la otra.

Por qué el incidente es un objeto

Antes de esto, una caída era una serie de filas en una tabla de transiciones de estado. Eso basta para dibujar un gráfico y no basta para decir nada. Hay tres cosas que solo existen cuando hay un objeto.

Una duración. El mensaje de recuperación no llevaba antes ninguna duración, porque no había nada con lo que rellenar el parámetro. Un incidente tiene un principio, así que la duración es una medición y no una estimación.

Una capa humana. Reconocer, asignar y cerrar a mano son cosas que hacen las personas, y no deben tocar el estado medido. Una columna acknowledged_at sobre una medición emborronaría justo la línea sobre la que está construida toda esta funcionalidad.

Deduplicación a lo largo del tiempo. Una notificación al abrirse, recordatorios con su propio reloj, como mucho un escalado. Sin objeto no hay de qué colgar el «ya te lo hemos dicho», y entonces cada tick es otra oportunidad de decirlo otra vez.

La deduplicación es un índice

La unicidad que impide que existan dos incidentes para una regla es un índice único parcial sobre la regla, donde la marca de tiempo de resolución es nula. Dos pasarelas que procesan la misma transición producen un incidente por construcción; la segunda recibe una violación de unicidad y sigue adelante.

Un código que comprueba si ya existe uno y después inserta son dos sentencias, que son dos oportunidades para que algo se cuele en medio. Esta es la misma forma que el índice de franjas del planificador y el índice de ocupación de racks en otras partes de este producto, y por la misma razón.

Aquí hubo además un fallo genuinamente vergonzoso, que merece la pena anotar porque es invisible en una revisión. La clave de deduplicación de la notificación se construía a partir de la regla, el estado nuevo y la marca de tiempo actual. Una clave que contiene la hora actual no deduplica nada, por construcción, y en pantalla parece del todo razonable. Ahora es el identificador del incidente. Medido después: tres fallos consecutivos producen un incidente y una notificación, y tres más no cambian nada.

Tres formas de terminar un incidente, y solo una es una medición

La del medio es el motivo de la lista. Una regla que queda sustituida por una revisión de plantilla tiene que cerrar sus incidentes abiertos, y tiene que hacerlo sin una medición falsa de recuperación. Si la única resolución disponible fuese recovered, sustituir una plantilla escribiría sin ruido «esto volvió a funcionar» en el historial de todos los servicios que estuviesen caídos en ese momento.

Deliberadamente no existe una resolución stale. Que las mediciones dejen de llegar no dice nada sobre el objetivo.

Qué transiciones tocan siquiera un incidente

Un incidente cuelga de una afirmación sobre el objetivo. Así que una transición a «origen no disponible», es decir, que nuestro propio agente se ha ido, no abre nada y, más importante todavía, no cierra nada. Si un agente que se marcha pudiese cerrar un incidente, una caída en curso desaparecería de la vista justo en el momento en que perdimos la capacidad de mirarla.

Una transición a «error de configuración» se comporta igual: la regla ya no describe nada medible, que es una afirmación sobre nosotros y no sobre el servicio.

«Degradado» sí cierra un incidente. El servicio responde, la condición cuenta como sana, solo la latencia es alta. Dejarlo abierto convertiría un servicio lento en una caída permanentemente abierta, recordatorios incluidos.

Debajo de esto, de una ronda anterior, hay una distinción dura entre un origen inalcanzable y un objetivo caído. Una comprobación cuyo agente no está conectado produce «origen no disponible» y nunca «caído». Todo lo anterior es esa misma regla, una capa más arriba.

El mantenimiento silencia notificaciones y sigue midiendo

Una ventana de mantenimiento suprime notificaciones. No suprime la medición. El incidente se abre igual, la línea temporal sigue corriendo, y solo el mensaje se queda en el cajón.

Eso no es un detalle. La pregunta que hace la gente después de una ventana de mantenimiento es «¿volvió a tiempo?», y esa pregunta no tiene respuesta si se dejó de medir mientras importaba. Hay una casilla aparte y explícita que sí pausa las comprobaciones, y está desactivada por defecto; con ella, el planificador se salta la reclamación de la franja, así que nada vence y nada se pierde. Lo que queda después es una única marca de hueco, igual que para cualquier otro hueco. No hay recuperación de lo pendiente.

La ventana en sí se guarda como un intervalo absoluto con una zona horaria IANA al lado. El cliente introduce la hora de reloj y quiere volver a leerla como la misma hora de reloj, aunque el panel represente todo en una zona fija. Guardar en su lugar la hora de pared más la zona obligaría a cada lector, planificador, ingesta y pantalla por igual, a rehacer la conversión, y entonces un cambio de horario de verano es una hora de desacuerdo entre dos de ellos.

Cuando dos ventanas se solapan, gana la que pausa las comprobaciones. Cuando un cliente ha tomado explícitamente en algún sitio una decisión más estricta, esa es la decisión que hay que respetar.

Recordatorios, escalado y el orden de dos sentencias

Tanto el intervalo de recordatorio como el retardo de escalado viven en la revisión de la regla y no en el incidente, porque son configuración y la configuración pertenece a la revisión que la registró. Cambiar la política durante una caída deja el incidente en curso bajo la política con la que se abrió.

Los dos están desactivados por defecto. Un valor por defecto que despierta a alguien de noche es una decisión que el cliente no tomó.

Reconocer silencia los recordatorios, y esa es toda la función de reconocer. A quien dice «lo estoy mirando» no se le debe interrumpir cada pocos minutos. La notificación de recuperación llega igual, porque esa es la respuesta a la pregunta que estaba mirando. El reloj de recordatorios corre además desde el último recordatorio y no desde el principio, así que un trabajador que se pone al día después de una hora no entrega doce recordatorios de golpe.

El trabajador escribe primero la marca de tiempo y envía el mensaje después, y la actualización exige que el estado siga siendo el que leyó. Si pierde esa carrera, aquí no pasa nada. En el orden contrario, una carrera perdida produce un mensaje del que no queda registro, y entonces el mensaje vuelve a llegar en la ronda siguiente.

El escalado ocurre como mucho una vez por incidente, y esa comprobación vive en la regla compartida y no en el trabajador. Sin ella, cada pasada escribiría otro evento de escalado durante todo lo que durase la caída: treinta a la hora con un sondeo de dos minutos.

El flapping es la excepción, y se decide cuando el incidente se abre: tres incidentes sobre la misma regla en una hora. Una comprobación con flapping, por definición, nunca tiene un incidente que se quede abierto mucho tiempo, así que cualquier escalado basado en tiempo se lo pierde para siempre. Tres y no dos, porque dos veces es mala suerte y un umbral de dos llamaría flapping a cualquier reinicio normal de un servicio. Una hora y no un día, porque tres caídas repartidas por una jornada de trabajo son tres caídas.

La duración es un número y una unidad

El mensaje de recuperación lleva cuánto duró, como valor y unidad, nunca como frase. Si el trabajador compusiese él mismo «1 hour 12 minutes», ese fragmento en inglés se quedaría en mitad de una frase traducida a otros ocho idiomas. Lo que viaja en su lugar es una unidad sobre la que selecciona la traducción, con un plural dentro de cada rama.

Una unidad, sin compuestos: un compuesto necesita un separador y un orden, y eso difiere de un idioma a otro. Segundos por debajo de un minuto, minutos hasta dos horas, horas hasta dos días, días a partir de ahí. Noventa minutos se lee con más nitidez que dos horas, y redondear hacia arriba haría que una caída de 89 minutos durase dos.

Dos consecuencias honestas que no arreglamos

Caído, recuperado y recordatorio comparten clave de grupo de notificación, porque un recordatorio es literalmente el mismo asunto otra vez y debe actualizar la fila existente en lugar de añadir una cada vez que salta el reloj. El coste es que un recordatorio actualiza una fila que alguien ya ha leído, y por tanto le resulta invisible. El escalado tiene su propio grupo exactamente por esta razón: el mensaje que más tiene que impactar no puede ser el primero en quedar sobrescrito. Las notificaciones de monitorización hoy no salen por correo.

Lo que dejaríamos por escrito

1. 01No dejar nunca que la ausencia de datos cierre nada. Darle a «no lo vemos» un estado propio y asegurarse de que ni abre ni cierra un incidente.
2. 02Darle al incidente un objeto en cuanto se quiera una duración, un reconocimiento o un segundo mensaje sobre lo mismo.
3. 03Poner la deduplicación en un índice único, y comprobar que la clave de notificación no contenga la hora actual.
4. 04Enumerar cómo puede terminar un incidente, y exigir evidencia solo donde se afirma evidencia.
5. 05Suprimir notificaciones durante el mantenimiento, no mediciones, y hacer que pausar las comprobaciones sea una opción aparte, explícita y desactivada por defecto.
6. 06Actualizar el estado y después enviar el mensaje. El orden contrario pierde mensajes en silencio.

Este trabajo está detrás de una bandera de despliegue desactivada por defecto, así que nada de esto es algo que se pueda comprar hoy. Está escrito como método y no como anuncio. La capa de medición que hay debajo, incluido por qué un agente inalcanzable no es un servicio que falla, es otra historia, y la cuestión estrechamente relacionada de cuándo puede una plataforma enunciar un tiempo está en una barra de progreso que se niega a adivinar.

Del trabajo de plataforma en Provibr.