โครงข่ายบริการและการสังเกตได้

A service mesh is an infrastructure layer that manages service-to-service communication. It handles routing, security, and observability without changing application code.

The mesh injects a sidecar proxy next to each service. All traffic flows through the proxy, which can measure and report on it.

Because every request passes through proxies, the mesh emits metrics, traces, and access logs for all services without instrumentation.

The mesh exposes request rate, error rate, and latency for each service and connection, the RED signals, automatically.

The proxy can start and propagate trace context, producing spans for every hop between services even if the app is not instrumented.

The mesh sees network hops but not what happens inside a service. To connect mesh spans, apps must still propagate the incoming trace headers.

Because the mesh sees all traffic, it can build a live service dependency map showing who calls whom and where errors flow.

Popular meshes include Istio and Linkerd. They differ in proxy choice and overhead but share the sidecar observability model.

• Istio: Envoy proxies, rich features
• Linkerd: lightweight micro-proxy

Mesh telemetry typically flows to Prometheus for metrics and to a tracing backend like Jaeger through the OpenTelemetry Collector.

The mesh buys observability cheaply but adds latency and resource cost per proxy, and its spans lack in-process detail.

• Pro: zero-code coverage
• Con: proxy overhead, shallow spans

Best practice combines mesh-level network telemetry with in-app instrumentation for internal logic, giving both breadth and depth.

You learned that a service mesh uses sidecar proxies to produce automatic metrics, traces, and topology for service-to-service traffic without code changes. Mesh spans cover network hops but not internal logic, and apps must still propagate trace headers, so combining mesh and app telemetry gives full coverage.