- Se descapó
- 16 de agosto de 2026 a las 1:43 UTC
- Autor
- Kamo
- Compromit
- 4fd9a2a
Nada estaba mirando la memoria. MediaService fue OOMKilled cada pocas horas durante la mayoría de un día y EmailService seis veces, y la forma en que alguien se enteró fue una charla ventana que había dejado silenciosamente de cargar mensajes - un contenedor muriendo y Reenzarte dentro de un segundo se lee como una característica rota, no como un apagón. Tres reglas. ContainerOOMKilled los incendios en el evento; ContainerOOMKillLoop separa una sola vez de una vaina siendo asesinada repetidamente, lo que se reinicia rápidamente lo suficiente para mostrar aún 1/1 Corriendo. ContenedorMemoryNearLimit es el que ha atrapado estos días antes: el 85% del límite se mantuvo durante 30 minutos. Para una JVM en MaxRAMPercentage que no es una vaina ocupada, es una vaina sentada en su techo de montón con no-apilado en la parte superior, que es el estado estacionario inmediatamente antes de la kernel interviene. Un cuarto, información, flagelación contenedores sin límite en No pueden ser OOMKilled por su propio grupo, pero pueden bajar un nodo. Verificados contra datos reales en lugar de asumido: las expresiones fueron evaluadas en este cúmulo, y la consulta de las últimas 12 horas muestra la razón="OOMKilled" serie para exactamente kamowsemail (18:33-01:28 UTC) y kamowsmedia (21:28-01:03 UTC) las dos vainas que estaban fallando. Las reglas habrían disparado crítico en ambas. Una alerta que no coincide en silencio nada es el mismo fracaso que no hay alerta, por lo que El chequeo importó más que el YAML. Aplicado a mano; el monitoreo/ no es un objetivo de aplicación de CI.