Saltar a contenido

Observabilidad y verificación

La operación necesita distinguir lo que el pipeline pidió hacer, lo que Kubernetes aceptó y lo que la aplicación realmente está sirviendo. Cloud Delivery Lab aporta evidencia de cada parte con distinto alcance: historial CI, manifiestos, recursos del clúster, logs y ejemplos de ingestión de telemetría en la memoria.

Evidencia disponible

Señal Evidencia encontrada Qué permite concluir Qué no demuestra
Pipelines de aplicación Historial público de frontend y backend con 11 jobs success en sus HEAD revisados Esas ejecuciones terminaron correctamente según sus jobs Salud actual, ausencia de vulnerabilidades o prueba funcional completa
Despliegue Kubernetes kubectl apply seguido de kubectl get all El job solicita aplicar manifiestos y consulta recursos Espera de disponibilidad, smoke test o validación de transacción de usuario
Readiness/liveness Probes TCP en 8080 para web y rest Se comprueba apertura del puerto Funcionamiento de la API, credenciales MySQL o integridad de datos
Logs de aplicaciones Configuración de logging en ambos servicios; captura histórica de acceso desde GitLab Hay puntos para investigar errores del proceso Retención centralizada, alertas o exportación OTLP continua
Red GCP Flow logs de subred y logs ERRORS_ONLY en Cloud NAT La configuración solicita señales de red en el proveedor Exportación de esas señales a GitLab
Trazas/métricas GitLab Ejemplos en la memoria, incluyendo test-service/test-span Se probó una capacidad de ingestión en el momento documentado Instrumentación completa del frontend, backend o consultas a MySQL

El último pipeline público de infraestructura examinado es de retirada y corresponde a un commit anterior al HEAD revisado. Un historial success no implica que hoy exista infraestructura en ejecución. Consulta fuentes y revisión para la fecha y las identidades exactas.

Verificar una entrega

Desde un entorno autorizado, selecciona el contexto del destino y consulta los componentes:

kubectl --context "$KUBE_CONTEXT" -n app get deployment rest web
kubectl --context "$KUBE_CONTEXT" -n app get pods -o wide
kubectl --context "$KUBE_CONTEXT" -n app rollout status deployment/rest --timeout=180s
kubectl --context "$KUBE_CONTEXT" -n app rollout status deployment/web --timeout=180s
kubectl --context "$KUBE_CONTEXT" -n app get services,ingress

Compara la imagen solicitada con el commit de manifiestos y con los pods existentes. Las probes TCP ayudan a detectar un proceso que no escucha, pero una comprobación funcional debe recorrer el endpoint HTTP y la operación de datos esperada. El dominio histórico no se ha probado como parte de esta revisión.

Si un pipeline aparece verde pero la aplicación no responde, revisa la clase de Ingress, la dirección del balanceador, la resolución DNS y TLS, y después la cadena Service–pod–base de datos. En GKE, la incompatibilidad del Ingress AWS requiere resolverse antes de atribuir el problema al frontend.

Logs y eventos para diagnóstico

kubectl --context "$KUBE_CONTEXT" -n app logs deployment/rest --tail=100
kubectl --context "$KUBE_CONTEXT" -n app logs deployment/web --tail=100
kubectl --context "$KUBE_CONTEXT" -n app get events --sort-by=.lastTimestamp
kubectl --context "$KUBE_CONTEXT" -n app describe deployment rest
kubectl --context "$KUBE_CONTEXT" -n app describe deployment web

En la interfaz de GitLab, las vistas de Kubernetes y Environments ofrecen información según la conexión y permisos del agente. Su configuración está en el modelo de acceso. El uso de la consola o de CI para diagnóstico debe respetar ese mismo alcance de permisos.

Relaciona fallos como ImagePullBackOff, errores de autenticación MySQL, reinicios o falta de endpoints con la etapa responsable. Conserva el identificador del pipeline, la imagen, el contexto y una ventana temporal del problema. Los logs pueden contener datos de usuarios o detalles sensibles: comparte extractos pertinentes y redacta esos valores al adjuntarlos a una incidencia.

Telemetría cloud observada en el código

La red GCP configura flow logs con agregación de cinco segundos y muestreo 0,5 en las dos subredes creadas; Cloud NAT registra errores. La identidad de nodos incluye roles de escritura de logs y métricas. Son capacidades de observación en GCP, no un collector OTLP ni una integración automática con GitLab Monitor.

En los seis repositorios examinados no se encontró configuración de collector, exporter o agente Java de OpenTelemetry, ni reglas versionadas de alertas, dashboards o SLO. Esta afirmación se limita a los archivos revisados; no descarta configuración manual o externa. La memoria utiliza trazas y métricas de ejemplo y no describe su instalación completa.

Mejoras propuestas

Las siguientes acciones son propuestas para una siguiente iteración:

Mejora Resultado verificable
Espera de rollout y smoke test en el pipeline La entrega falla cuando el despliegue no converge o el recorrido mínimo no funciona
Probes HTTP con semántica de salud adecuada Readiness representa capacidad de servicio y no sólo un socket abierto
Instrumentación OTLP y collector versionados Endpoint, autenticación, recursos y ruta de exportación reproducibles
Política de retención y acceso a logs Ventana de investigación conocida y datos tratados de forma consistente
Alertas y objetivos de servicio Umbrales, destinatarios y criterios de recuperación explícitos

Estas mejoras no se presentan como implantadas. Antes de añadir telemetría, decide qué servicios y operaciones se medirán, qué datos se excluirán y dónde se conservarán. La guía de runbooks conecta diagnóstico, rollback y recuperación.

Fuentes