A DevOps engineer deploys a new version of a microservice to a Google Kubernetes Engine (GKE) cluster integrated with Cloud Service Mesh and Google Cloud Observability. After deployment, automated canary verification fails due to missing service performance telemetry and elevated upstream errors. The engineer observes the following symptoms: The Cloud Service Mesh dashboard and Cloud Monitoring fail to display HTTP request rate and latency metrics for the newly deployed service. Kubernetes Pod inspection shows all pods running with two containers (app and istio-proxy). In Cloud Trace, distributed traces reveal that upstream calls to the service span are completing with generic network errors rather than structured HTTP responses. In Logs Explorer, correlating the traceId with proxy logs shows traffic being handled as opaque TCP streams rather than HTTP/gRPC protocol traffic. Which root cause and diagnostic action explain this deployment failure?

A service configuration mismatch occurred where the Kubernetes Service port is not named with an `http` or `http-` prefix; inspect the Kubernetes Service definition and rename the port to restore HTTP layer telemetry and protocol handling.: ### What the Solution Is In **Cloud Service Mesh** and **GKE**, the service mesh relies on Kubernetes Service port definitions to determine the application protocol (e.g., HTTP, HTTP/2, gRPC). When port names do not begin with an accepted protocol prefix such as `http`, `http2`, or `grpc` (or use the standard `appProtocol` field), the Envoy proxy defaults to treating traffic as raw, unparsed **TCP streams**. ### How It Meets the Requirements - **Identifies the Root Cause**: The symptoms directly reflect a **configuration mismatch** in the Kubernetes Service resource. Because the port lacks an `http` or `http-` naming convention, Cloud Service Mesh treats incoming connections as generic TCP. - **Explains Missing Metrics**: The Cloud Service Mesh dashboard and Cloud Monitoring HTTP server metrics strictly require recognized HTTP/gRPC traffic protocols; without them, layer 7 request metrics and latency statistics are not generated. - **Resolves Trace and Routing Anomalies**: Renaming the port to start with `http` or `http-` enables Envoy to parse Layer 7 HTTP request headers, inject distributed tracing context headers, and generate appropriate HTTP-level telemetry and metrics. ### Key Advantages and Capabilities - **Native Observability Alignment**: Adhering to port naming conventions enables automatic protocol detection, unlocking Golden Signals metrics in Cloud Monitoring. - **Seamless Trace Context Propagation**: Allows Envoy sidecars to parse HTTP headers (e.g., `traceparent`, `x-cloud-trace-context`) and attach trace spans automatically. - **Zero Application Code Changes**: Resolving the issue only requires modifying the Kubernetes `Service` manifest without altering application binaries. - **Prevents Protocol Degradation**: Ensures advanced routing, load balancing, and mTLS features operate at the application layer rather than falling back to opaque transport-layer proxies. ### Why This Is Optimal Other possibilities (such as proxy injection failure or API quota exhaustion) are ruled out by the telemetry evidence: pods already possess running `istio-proxy` containers, and raw TCP logs are successfully ingested. Modifying the Service port name directly fixes the root protocol mismatch.

Cloud Service Mesh Port Naming Telemetry Failure | Professional Cloud DevOps Engineer

Cloud Service Mesh Port Naming Telemetry Failure

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

A DevOps engineer deploys a new version of a microservice to a Google Kubernetes Engine (GKE) cluster integrated with Cloud Service Mesh and Google Cloud Observability. After deployment, automated canary verification fails due to missing service performance telemetry and elevated upstream errors.

The engineer observes the following symptoms:

The Cloud Service Mesh dashboard and Cloud Monitoring fail to display HTTP request rate and latency metrics for the newly deployed service.
Kubernetes Pod inspection shows all pods running with two containers (app and istio-proxy).
In Cloud Trace, distributed traces reveal that upstream calls to the service span are completing with generic network errors rather than structured HTTP responses.
In Logs Explorer, correlating the traceId with proxy logs shows traffic being handled as opaque TCP streams rather than HTTP/gRPC protocol traffic.

Which root cause and diagnostic action explain this deployment failure?

An application runtime error occurred where the application crashed during bootstrap; review Cloud Logging application stdout and increase memory limits to avoid OOMKilled states.

The project exceeded its Cloud Monitoring API write quota, causing metric drops; navigate to IAM & Admin Quotas to request a quota increase for monitoring.googleapis.com.

A service configuration mismatch occurred where the Kubernetes Service port is not named with an http or http- prefix; inspect the Kubernetes Service definition and rename the port to restore HTTP layer telemetry and protocol handling.

An infrastructure provisioning failure occurred because the istio-proxy sidecars were not injected into the application pods; update the namespace labels to enable automatic sidecar injection.

Professional Cloud DevOps Engineer

Cloud Service Mesh Port Naming Telemetry Failure

Related questions