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
默认指标是有关HTTP，gRPC和TCP请求和响应的标准信息。源代理和目标代理也报告每个请求，它们可以提供有关流量的不同视图。某些请求可能未由目标报告（如果请求根本没有到达目标），但是某些标签（如connection_security_policy）仅在目标端可用。以下是一些最重要的HTTP指标：
istio_requests_total是一个计数器，用于汇总Kubernetes工作负载之间的请求总数，并按响应代码，响应标志和安全策略对其进行分组。
如上所述here
当Mixer从Envoy收集指标时，它会分配维度，下游后端可将其用于分组和过滤。在Istio的默认配置中，维度包括指示请求在集群中移动的位置的属性，例如原始服务和目标服务的名称。这使您可以查看群集中任何位置的流量。
观看指标：requests_total
“请求计数”指标表示网格中服务之间请求的总体吞吐量，每当Envoy边车收到HTTP或gRPC请求时，该请求的吞吐量就会增加。您可以通过原始服务和目标服务来跟踪此指标。如果一项服务与另一项服务之间的请求计数骤降，则说明源已停止发送请求，或者目的地未能处理这些请求。在这种情况下，您应该检查Pilot（在服务之间路由流量的Istio组件）中是否配置错误。如果需求增加，则可以将此指标与诸如CPU利用率之类的资源指标的增加相关联，并确保正确地缩放系统资源。
由于here的写法，也许值得查问特使文档有关的内容>
上面的查询使用istio_requests_total指标，它是标准的Istio指标。您可以观察其他指标，尤其是Envoy的指标（Envoy是Istio的辅助代理）。您可以在光标下拉菜单的插入指标中看到收集的指标。
基于以上文档，我同意@Joel在评论中提到的内容
我认为您是正确的，并且我想“为什么”是由于期望在度量标准标签上找到响应标志。 仅在收到响应时才可以写
。如果他们想做不同的事情，我想这意味着要有2个不同的计数器，一个用于发送请求，一个用于接收响应。