Istio具有多个默认指标，例如istio_requests_total，istio_request_bytes和istio_tcp_connections_opened_total。 Istio envoy代理计算并公开这些指标。在Istio website上，它显示istio_requests_total是针对Istio代理处理的每个请求递增的COUNTER。
我们进行了一些实验，让很多请求通过Istio特使到达Istio特使背后的微服务，同时我们监视了Istio特使的指标。但是，我们发现istio_requests_total不包括通过Istio特使到达后端微服务的请求，但它们的响应尚未从后端微服务到达Istio特使。换句话说，istio_requests_total仅包含已服务请求的数量，不包括飞行中的请求。
我的问题是:我们的观察正确吗？为什么istio_requests_total不包含进行中的请求？
最佳答案
就像here
The default metrics are standard information about HTTP, gRPC and TCP requests and responses. Every request is reported by the source proxy and the destination proxy as well and these can provide a different view on the traffic. Some requests may not be reported by the destination (if the request didn't reach the destination at all), but some labels (like connection_security_policy) are only available on the destination side. Here are some of the most important HTTP metrics:
istio_requests_total is a COUNTER that aggregates request totals between Kubernetes workloads, and groups them by response codes, response flags and security policy.
就像here
When Mixer collects metrics from Envoy, it assigns dimensions that downstream backends can use for grouping and filtering. In Istio’s default configuration, dimensions include attributes that indicate where in your cluster a request is traveling, such as the name of the origin and destination service. This gives you visibility into traffic anywhere in your cluster.
Metric to watch: requests_total
The request count metric indicates the overall throughput of requests between services in your mesh, and increments whenever an Envoy sidecar receives an HTTP or gRPC request. You can track this metric by both origin and destination service. If the count of requests between one service and another has plummeted, either the origin has stopped sending requests or the destination has failed to handle them. In this case, you should check for a misconfiguration in Pilot, the Istio component that routes traffic between services. If there’s a rise in demand, you can correlate this metric with increases in resource metrics like CPU utilization, and ensure that your system resources are scaled correctly.
也许值得检查特使文档，因为here是写什么的
The queries above use the istio_requests_total metric, which is a standard Istio metric. You can observe other metrics, in particular, the ones of Envoy (Envoy is the sidecar proxy of Istio). You can see the collected metrics in the insert metric at cursor drop-down menu.
基于以上文档，我同意@Joel在评论中提到的内容
I think you're correct, and I imagine the "why" is because of response flags that are expected to be found on the metric labels. This can be written only when a response is received. If they wanted to do differently, I guess it would mean having 2 different counters, one for request sent and one for response received.
关于kubernetes - Istio指标 “istio_requests_total”是服务的请求数吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/61686730/