浏览K8s/Istio上部署的Grafana时出现间歇性upstream connect errors如何排查

1. 优先核对端点健康度与负载均衡分发逻辑 #

50%左右的间歇性故障概率，首先要排查是否存在流量被分发到异常上游端点的情况：

• 先查询Grafana对应Service挂载的所有后端端点：执行kubectl get endpoints <grafana-service-name> -n <所在命名空间>，确认列表里的IP全部对应正常运行的Grafana Pod，没有残留处于Terminating状态的旧Pod IP。滚动更新后旧Pod终止、但Endpoint列表未及时剔除残留IP是非常常见的诱因——K8s的端点更新有延迟，Istio的xDS配置同步也有固定的缓存周期，就会出现约50%的流量被导到已经没有服务监听的IP上，触发连接终止；刷新时流量被导到正常运行的Pod上，就会临时恢复。
• 检查Istio针对该Grafana服务的离群检测（Outlier Detection）配置：如果没有开启离群自动剔除，哪怕某一个Grafana副本已经因为资源耗尽（CPU打满、内存触发OOM、端口监听异常）无法正常响应，Envoy也会持续把流量按比例导到故障副本上，形成固定比例的故障概率。
• 核对Istio对上游的连接超时配置：Istio默认对HTTP上游的空闲连接超时是10s，如果Grafana处理请求（比如对接PostgreSQL拉取长周期仪表盘数据）的耗时超过这个阈值，Envoy就会主动断开空闲连接，触发连接终止报错。

2. 排查协议识别与mTLS配置的不匹配问题 #

很多连接重置的错误发生在传输层，根本不会被应用日志捕获：

• 检查Grafana Service的端口命名是否符合Istio的要求：Istio需要端口名带明确的协议前缀（比如http-web）才能正确识别流量类型，如果只配置了web这类无协议前缀的端口名，Istio会默认按TCP流量透传，不会做HTTP层的连接复用处理，在新建连接的窗口期就可能触发连接重置，平时复用长连接时就运行正常，完全匹配“正常数分钟、突然交互报错、刷新又恢复”的特征。
• 检查对应命名空间的PeerAuthentication配置：如果mTLS被设置为STRICT模式，需要确认Grafana Pod的Sidecar证书是否正常挂载、没有出现证书过期的情况；如果证书校验在握手阶段失败，对端会直接发RST包断开连接，这个过程不会在Grafana的应用日志里留下任何痕迹。

3. 排查ArgoCD自动同步带来的隐式流量切换影响 #

因为Grafana是通过ArgoCD部署的，很容易忽略同步动作对流量的影响：

• 拉取ArgoCD的同步历史，核对故障出现的时间点是否和自动同步的时间重合：如果Git仓库里的Grafana配置有任何微小变更（哪怕是标签、注解的修改），ArgoCD就会触发Pod的滚动重建。在新老Pod切换的窗口期，如果Istio的xDS配置更新有延迟，就会短暂把流量导到还没完成启动的新Pod、或者已经终止的旧Pod上，触发连接错误；等配置同步完成、所有端点状态稳定后，故障又会临时消失。
• 核对Grafana Deployment的终止配置：如果没有配置preStop钩子让Sidecar先把Pod从负载均衡列表里摘除、再终止应用进程，或者terminationGracePeriodSeconds配置过短，滚动更新时就一定会出现几十秒的流量导向无效端点的问题。

4. 调整日志抓取策略定位真实根因 #

之前查应用日志和普通Istio日志没有有效线索，是因为默认日志级别不会记录传输层的连接断开细节：

• 临时把故障触发时，对应Grafana Pod的Envoy Sidecar的日志级别调整为debug，重点筛选上游连接终止类的日志，确认错误是发生在TCP握手阶段、TLS校验阶段，还是请求处理过程中，同时定位触发错误的具体上游端点IP。
• 在流量入口的网关节点和Grafana Pod所在节点同步抓包，查看故障出现时的RST包来源，定位是哪个环节主动断开了连接。

内容的提问来源于stack exchange，提问作者Mike K.