在AOM控制台的“指标浏览”页面，输入以 istio_ 开头的 promQL 查询语句，就能直接查看应用服务网格里 grpc 服务的请求量、延迟和错误分布，不需要额外搭建 Prometheus。 如果你正在为 grpc 接口超时、调用失败这类问题挠头,这篇内容会带你走一遍从指标查看到链路定位的完整实操路径。
AOM查询应用服务网格详细指标，先分清这些数据从哪来
很多人在 AOM 页面上翻半天找不到 istio 指标，原因不是数据没上报，而是没搞懂指标的“归属”，istio 的指标不是业务容器自己吐出来的，而是旁边的 sidecar 代理（Envoy）统计的。
grpc 服务的指标为什么要看 istio_proxy
你部署的 grpc 服务只要注入了 istio sidecar，所有进出流量都会先经过 Envoy，Envoy 在 15020 和 15090 端口暴露 Prometheus 格式的指标，AOM 通过 ServiceMonitor 自动抓取，所以你在 AOM 里搜指标时，看到的 istio_requests_total、istio_request_duration_milliseconds 这些名字，本质上是 sidecar 的“目击报告”,不是业务代码自己埋的点。
AOM 控制台上，哪些菜单和网格指标相关
- 指标浏览：最灵活的入口，支持 promQL 实时计算,适合排查问题时临时查询。
- 服务网格视图：如果集群里装了应用服务网格插件,这里会展示服务间的拓扑关系。
- 仪表盘：把常用的查询保存成面板,日常巡检直接看。
- 告警规则：针对指标设置阈值，触发后通过短信、邮件通知你。
实际操作路径是：登录 AOM 控制台 → 左侧“监控中心” → “指标浏览” → 选择对应集群和命名空间 → 输入查询语句，这套路径你在不同区域（比如华北、华东）操作时入口一致,只是控制台域名不同。
实战：istio grpc服务监控指标在AOM上这么查
搞清楚数据来源之后，我们进入正题，grpc 的指标查询和 http 有个明显的差异：grpc 的请求状态码不是 200、404 这一套，而是 0、1、2 这样的 grpc 专用状态码。0 表示成功,这个细节直接决定你的查询条件怎么写。
先看 grpc 服务整体请求量和错误率
在指标浏览的输入框里，粘贴这段 promQL：
sum(rate(istio_requests_total{reporter="destination", request_protocol="grpc"}[5m])) by (destination_service_name)
这段查询把 5 分钟内的 grpc 请求速率按目标服务聚合。reporter="destination" 表示看服务端视角的数据，而不是调用方视角，这样能准确反映你的 grpc 服务实际承受的压力。
想看错误率的话,把状态码条件加进去：
sum(rate(istio_requests_total{reporter="destination", request_protocol="grpc", grpc_response_status!="0"}[5m]))
by (destination_service_name)
注意 grpc_response_status!="0" 这个写法，它把成功请求排除掉，剩下的就是异常调用，如果你照着 http 的习惯写 response_code="200"，grpc 的成功请求反而全被过滤掉了。
拆解 grpc 服务响应延迟，找性能瓶颈
请求量只是表面现象，延迟才是 grpc 服务性能的核心，AOM 里查延迟,用的是直方图指标：
histogram_quantile(0.99,
sum(rate(istio_request_duration_milliseconds_bucket{reporter="destination", request_protocol="grpc"}[5m]))
by (le, destination_service_name))
这条语句算的是 grpc 请求的 P99 延迟，也就是最慢的那 1% 请求耗时，你可以把 0.99 改成 0.5、0.9 分别观察中位数和尾延迟，行业共识认为，grpc 接口的 P99 比平均值更能反映真实体验,因为平均值容易被大量快速请求拉低。
grpc 和 http 的查询条件差异对比
| 维度 | grpc 查询写法 | http 查询写法 |
|---|---|---|
| 请求量 | request_protocol="grpc" |
request_protocol="http" |
| 成功状态 | grpc_response_status="0" |
response_code="200" |
| 延迟分布 | istio_request_duration_milliseconds_bucket |
同样的指标名 |
| 连接数 | istio_tcp_sent_bytes_total |
一般用不上 |
还要提一个 grpc 特有的坑：流式调用，grpc 支持 streaming 长连接，一个连接里能传几百条消息，但 istio 的 istio_requests_total 统计的是连接级别的请求数，所以你在页面上看到 grpc 请求量不高，不代表业务量小,建议同时看字节指标来评估真实吞吐。
grpc服务超时排查实操：从AOM指标到调用链定位
grpc 调用超时是微服务里最常见的故障之一，你可能会收到“deadline exceeded”或者“timeout”的报错，这时候 AOM 页面上有一套固定的排查顺序。
第一步，先确认超时发生在入口还是出口
在指标浏览里，分别用 reporter="source" 和 reporter="destination" 各查一次错误率，source 视角有错误而 destination 视角正常，说明问题出在调用方的连接上，比如网络不通、负载均衡策略不对，如果两边都有错误,那就接着往下查。
第二步，锁定具体是哪个接口的延迟超标
用这段查询找到延迟最高的目标服务：
topk(10,
histogram_quantile(0.99,
sum(rate(istio_request_duration_milliseconds_bucket{reporter="destination", request_protocol="grpc"}[5m]))
by (le, destination_service_name)))
topk 会把延迟最高的前 10 个服务列出来，你一眼就能看出哪个 grpc 服务拖慢了整条链路。
第三步，跳到调用链里看单次调用细节
指标确认了时间范围和目标服务后，在 AOM 左侧菜单打开“调用链追踪”，按服务名和时间范围搜索 grpc 的 span，调用链会展示这次 grpc 请求经过了哪些服务、每一步花了多少时间，比如一个服务调了另外两个 grpc 接口，你能直接看到是下游哪个服务消耗了大部分耗时，业内专家指出，指标负责回答“哪里有异常”，调用链负责回答“为什么异常”,两者结合才是完整的排查路径。
把AOM查询istio指标养成习惯，记住这三个细节
除了故障排查，日常巡检同样可以依赖 AOM，但很多用户用了一段时间后发现，每次都要重新输查询语句，效率很低,这里分享三个提升使用效率的方法。
把常用查询存成仪表盘
在指标浏览页面执行过查询后，点击“保存”按钮，把这条 promQL 命名保存到仪表盘,建议按监控维度组织面板：
- 流量面板：grpc 请求 QPS、字节速率
- 错误面板：grpc 错误率、4xx/5xx 情况
- 性能面板
：P50、P95、P99 延迟
这样每次登录 AOM，直接打开仪表盘就能看全局,不用再敲命令。
告警条件用简单阈值起步
搭建告警时，没必要一上来就写复杂的 promQL，你可以先设置“过去 5 分钟 grpc 错误请求数大于 10 次”这种直白的条件，等稳定运行一段时间后再根据实际数据调整，告警的核心是别漏报，其次才是减少误报,这个顺序不要搞反。
指标为空时的排查顺序
AOM 页面查不到 istio 指标,按下面顺序检查：
- pod 是否注入了 sidecar，查看 pod 里有没有 istio-proxy 容器
- 命名空间是否设置了
istio-injection=enabled- ServiceMonitor 的 selector 是否匹配目标 pod
- 指标浏览的“指标名称”搜索框里直接搜
istio_requests_total，确认数据是否已采集
绝大多数查询不到的问题，都出在 sidecar 注入或 ServiceMonitor 配置这两步,仔细检查一遍就能解决。
istio grpc_AOM查询应用服务网格常见问题解析
问：AOM页面查istio grpc指标，用哪个指标名最准确？
首推 istio_requests_total，配合 request_protocol="grpc" 过滤，grpc 的 OK 状态码是 0，网上很多教程写 response_code="200" 只适用于 http，用到 grpc 上会出现漏统计。istio_request_duration_milliseconds_bucket 做时延分布，istio_request_attempt_count 看重试情况,都是常用指标。
问：AOM 上 istio 指标一直为空，可能是什么原因？
通常有三个原因，第一，pod 没有注入 sidecar，检查 deployment 里是否配置了 istio-injection，第二，ServiceMonitor 的 selector 没有匹配到目标 pod，在 AOM 的采集配置里确认，第三，指标名输入错误，在指标浏览器的“搜索指标”下拉框里先确认 istio 指标是否存在，再写 promQL，这三个检查一遍,基本都能定位问题。
问：grpc streaming 请求在 AOM 里是不是看不到流量？
能看到，streaming 的每条消息不会被单独计数，istio_requests_total 统计的是连接级别的请求，若要观察消息吞吐量，需要看 istio_tcp_sent_bytes_total 这类字节指标，长期运行的 streaming 连接会让 P99 直方图看起来“很低”，此时建议关注 bytes 指标和连接持续时间,而不是请求数。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/576927.html
