In a service mesh, the gateway between every service is the front proxy. For this reason, the front proxy is, unsurprisingly, a rich information source for things running inside the mesh. However, if our tech stack already has similar components, such as load balancers or reverse proxies for internal services, then what's the difference between collecting traffic data from them and the service mesh proxy? Let's consider the classical setup:

SVC-A and SVC-B make requests to SVC-C. The data gathered from the load balancer for SVC-C represents the quality of SVC-C. However, as we don't have any visibility over the path from the clients to SVC-C, the only way to measure the quality between SVC-A or SVC-B and SVC-C is either by relying on a mechanism built on the client side, or by putting probes in the network that the clients are in. For a service mesh, take a look at the following diagram:

Here, we want to know the quality of SVC-C. In this setup, SVC-A and SVC-B communicate with SVC-C via their sidecar proxies, so if we collect metrics about requests that go to SVC-C from all client-side proxies, we can also get the same data from the server-side load balancer, plus the missing measurement between SVC-C and its clients. In other words, we can have a consolidated way to measure not only how SVC-C performs, but also the quality between SVC-C and its clients. This augmented information also helps us to locate failures when triaging a problem.