Monitoreo de confiabilidad Kubernetes con SQL
Kubernetes crea muchos objetos de corta duración, por lo que agrupar observaciones sin procesar por grupo a menudo produce un informe ruidoso. Comience en el límite de la carga de trabajo: clúster, espacio de nombres, propietario de la implementación o del trabajo, lanzamiento de la aplicación, transición controlada, resultado de preparación y el trabajo de cara al cliente que realiza esa carga de trabajo.
Transiciones separadas de los indicadores.
Emite un evento container_restarted cuando aumenta el contador de reinicio observado. Mantenga el contador acumulativo como contexto, pero no lo sume entre muestras. Registre la preparación como una observación booleana separada. Una implementación planificada puede reemplazar módulos en buen estado, mientras que un ciclo de fallas produce repetidas transiciones de reinicio y, a menudo, una pérdida sostenida de preparación.
Utilice nombres de cargas de trabajo, espacios de nombres y clústeres delimitados. No copie secretos de Kubernetes, valores de variables de entorno, manifiestos completos, argumentos de contenedor, mensajes de registro sin procesar ni cargas útiles de clientes en el evento.
Clasificar cargas de trabajo inestables
El Kubernetes reiniciar receta SQL agrupa las observaciones por carga de trabajo, cuenta las transiciones de reinicio, conserva el contador máximo observado y calcula la tasa de no listo. Su accesorio demuestra la diferencia entre el recuento de transiciones y el estado de reinicio acumulativo.
Investigue el resultado en este orden:
- Confirme que el reinicio se repita y no solo un reemplazo de implementación.
- Compruebe si se produjo una pérdida de preparación durante la misma ventana.
- Compare las categorías de versión, grupo de nodos, clúster y motivos controlados.
- Únase al tiempo con fallas del API, trabajos retrasados u otros resultados del producto.
El colección de recetas de infraestructura agrega saturación de recursos, latidos y sincronización de incidentes. Esas señales ayudan a distinguir el fallo de la aplicación de la presión de capacidad o un problema más amplio del clúster.
Comience con Guía de integración Kubernetes al crear el límite de recopilador a evento y la normalización del propietario de la carga de trabajo.
Alerta en caso de impacto, no de abandono
Un panel de carga de trabajo debe mantener juntas las transiciones de reinicio, la preparación, los marcadores de implementación y la tasa de error de la aplicación. Página sólo después de una condición sostenida revisada; Un pod reprogramado o un reemplazo de implementación esperado generalmente no son procesables.
El Caso de uso de confiabilidad Kubernetes proporciona un mensaje de agente de codificación para el contrato de evento. Valide los casos de reinicio sintético, implementación, recuperación y eventos retrasados antes de utilizar la consulta para respuesta de producción.