Skip to content

Observability and verification

Operations must distinguish what the pipeline requested, what Kubernetes accepted and what the application actually serves. Cloud Delivery Lab provides different kinds of evidence: CI history, manifests, cluster resources, logs and examples of telemetry ingestion in the thesis.

Available evidence

Signal Evidence found Supported conclusion What it does not establish
Application pipelines Public frontend and backend history with 11 success jobs at the reviewed HEADs Those executions completed according to their job definitions Current health, absence of vulnerabilities or a complete functional test
Kubernetes deployment kubectl apply followed by kubectl get all The job requests manifest application and queries resources Readiness waiting, a smoke test or a user-transaction check
Readiness/liveness TCP probes on 8080 for web and rest The listening port is checked API behaviour, MySQL credentials or data integrity
Application logs Logging configuration in both services; historical GitLab access screenshot There are entry points for investigating process errors Central retention, alerting or continuous OTLP export
GCP networking Subnet flow logs and Cloud NAT ERRORS_ONLY logging Provider-side network signals are requested Export of those signals to GitLab
GitLab traces/metrics Thesis examples, including test-service/test-span An ingestion capability was tried at the documented time Complete frontend, backend or MySQL-query instrumentation

The latest public infrastructure pipeline examined performs teardown and belongs to an earlier commit than the reviewed HEAD. A success history does not imply that infrastructure is running today. See sources and review for dates and exact identities.

Verify a delivery

From an authorised environment, select the destination context and inspect the components:

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

Compare the requested image with the manifest commit and existing pods. TCP probes help detect a process that is not listening, but a functional check must exercise the HTTP endpoint and intended data operation. The historical domain was not tested as part of this review.

If a pipeline is green but the application does not respond, review the Ingress class, load-balancer address, DNS and TLS, then the Service–pod–database chain. On GKE, the AWS Ingress incompatibility must be resolved before attributing the problem to the frontend.

Diagnostic logs and events

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

GitLab's Kubernetes and Environments views expose information according to the agent connection and permissions. The access model documents the configuration. Console or CI-based diagnosis should respect the same permission scope.

Relate failures such as ImagePullBackOff, MySQL authentication errors, restarts or missing endpoints to the responsible stage. Preserve the pipeline ID, image, context and incident time window. Logs may contain user data or sensitive details: share relevant excerpts and redact those values when attaching them to an issue.

Cloud telemetry observed in code

GCP networking configures flow logs with five-second aggregation and 0.5 sampling on both created subnets; Cloud NAT records errors. The node identity includes roles for writing logs and metrics. These are GCP observability capabilities, not an OTLP collector or an automatic GitLab Monitor integration.

The six reviewed repositories contain no collector, exporter or OpenTelemetry Java-agent configuration, nor versioned alerts, dashboards or SLOs. This finding is limited to the examined files; it does not exclude manual or external configuration. The thesis uses example traces and metrics without documenting their complete installation.

Proposed improvements

The following actions are proposals for a subsequent iteration:

Improvement Verifiable outcome
Pipeline rollout waiting and smoke test Delivery fails when deployment does not converge or the minimum functional path fails
HTTP probes with suitable health semantics Readiness represents ability to serve, not merely an open socket
Versioned OTLP instrumentation and collector Reproducible endpoint, authentication, resources and export path
Log-retention and access policy A known investigation window and consistent handling of data
Alerts and service objectives Explicit thresholds, recipients and recovery criteria

These improvements are not presented as implemented. Before adding telemetry, decide which services and operations to measure, which data to exclude and where it will be retained. Runbooks connect diagnosis, rollback and recovery.

Sources