Service Mesh Probe

Service Mesh probes use the extendable mechanism provided in the Service Mesh implementor, like Istio.

What is Service Mesh?

The following explanation comes from Istio's documentation.

The term “service mesh” is often used to describe the networks of microservices that make up such applications and the interactions between them. As a service mesh grows in size and complexity, it can become harder to understand and manage. Its requirements can include discovery, load balancing, failure recovery, metrics, and monitoring, and often more complex operational requirements such as A/B testing, canary releases, rate limiting, access control, and end-to-end authentication.

Where does the probe collect data from?

Istio is a typical Service Mesh design and implementor. It defines Control Panel and Data Panel, which are widely used. Here is the Istio Architecture:

The Service Mesh probe can choose to collect data from Data Panel. In Istio, it means collecting telemetry data from Envoy sidecar (Data Panel). The probe collects two telemetry entities from the client end and the server end per request.

How does Service Mesh make backend work?

In this kind of probes, you can see that there is no trace related to them. So how does the SkyWalking platform manage to work?

The Service Mesh probe collects telemetry data from each request, so they know about information such as the source, destination, endpoint, latency and status. From these information, the backend can tell the whole topology map by combining these calls into lines, as well as the metrics of each node through their incoming requests. The backend requests for the same metrics data by parsing the trace data. In short: The Service Mesh metrics work exactly the same way as the metrics that are generated by trace parsers.