企业官网建设流程全解析

Coroot 网络巡检（Network Inspection）深度解析：自动检测应用与依赖服务间的网络问题

【免费下载链接】corootCoroot is an open-source observability and APM tool with AI-powered Root Cause Analysis. It combines metrics, logs, traces, continuous profiling, and SLO-based alerting with predefined dashboards and inspections.项目地址: https://gitcode.com/GitHub_Trending/co/coroot

Coroot 的网络巡检（Network Inspection）是一套内置于审计报告体系中的自动化网络诊断能力：它基于分布式系统模型，自动识别每个应用所依赖的上游服务，持续监测 RTT、TCP 连接成功率、活跃连接数、重传与流量等指标，并对照可覆盖的阈值给出巡检结论。读完本文，你将理解网络巡检的五大检查项、上游依赖的分类规则、底层连接数据模型的判定逻辑，以及如何在应用界面和总览页中定位"高延迟、连接失败、断连"三类典型网络问题。

网络巡检是什么

Coroot 官方文档对网络巡检给出了一个精炼的定义：

This inspection detects network issues between the application and the services on which it depends.（该巡检用于检测应用与其所依赖服务之间的网络问题。）

正如 Inspections 总览 所述，Coroot 将传统的"指标分析"方式做了反转：它使用分布式系统模型，在每个应用的上下文中评估各项巡检，而不是让运维人员面对海量告警自行筛选。网络巡检正是这一理念的典型体现——它不需要你手动挑选"哪条链路"，而是自动遍历当前应用的每一个上游依赖，逐一评估网络质量。

从 UI/UX 层面看，每个应用级仪表盘的状态就是由对应检查项计算而来的（见 docs/docs/inspections/overview.md），网络巡检的状态最终也会汇总到应用总览页面的 Network 状态栏中。

网络巡检报告：按上游依赖逐一展示 RTT、TCP 连接与流量指标，并对超阈值项给出巡检结论。

网络巡检的五大检查项

网络巡检的实现集中在 auditor/network.go，其检查项定义在 model/check.go 中。当应用存在上游依赖（Upstreams非空）时，审计器会创建一份名为Net的网络审计报告（见 model/audit_report.go），并注册以下五个检查：

五个检查项覆盖了网络排障的两个核心维度：

• 延迟（RTT）：NetworkRTT、NetworkRTTExternal、NetworkRTTOtherClusters分别针对集群内、外部服务、其他集群三类链路，默认阈值从 0.01s（集群内）到 0.2s（外部服务）差异明显——这正是因为不同链路的物理距离与网络拓扑决定了其合理的延迟基线不同。
• 连通性与连接：NetworkConnectivity关注"连不上"（连通性中断），NetworkTCPConnections关注"连接失败"（连接尝试失败），两者都是 ItemBased 类型检查：只要存在一个受影响的上游服务，检查即被标记。

以NetworkRTT为例，检查配置中还带有消息模板，用于在巡检报告中生成可读的结论文本（model/check.go）：

high in-cluster network latency: {{.Items "service"}} affected, max RTT: {{.ValueDuration}}

当某个上游的 RTT 超过阈值时，审计器会调用AddItem把该上游服务加入"受影响列表"，Calc()随后渲染出类似"high in-cluster network latency: 2 services affected, max RTT: 15ms"的结论（渲染逻辑见 model/check.go）。

上游依赖如何分类：集群内 / 外部 / 跨集群

网络巡检最巧妙的地方在于对上游依赖的自动分类。在 auditor/network.go 中，每一个上游连接（u.RemoteApplication）都会按以下优先级被归入三类之一：

switch { case u.RemoteApplication.Id.Kind == model.ApplicationKindExternalService: rttCheck = rttCheckExternal // 外部服务 → 使用 0.2s 阈值 case a.app.Id.ClusterId != u.RemoteApplication.Id.ClusterId: rttCheck = rttCheckOtherClusters // 其他集群 → 使用 0.1s 阈值 default: rttCheck = rttCheckInCluster // 集群内 → 使用 0.01s 阈值 }

这一分类逻辑直接决定了哪个检查项会被触发、采用哪个阈值，也意味着：同一个应用如果同时依赖集群内的数据库、云上的外部 API 和另一个集群的 Kafka，Coroot 会分别用各自合理的基线去评估，而不会用集群内 10ms 的标准去误报公网链路。

RTT 检查的取值逻辑是"取最大值"：if last > rttCheck.Value() { rttCheck.SetValue(last) }，即检查的最终值等于所有受影响上游中最大的 RTT；任何一条链路超阈值都会通过AddItem被记录（auditor/network.go）。

底层数据模型：AppToAppConnection 的判定逻辑

网络巡检的指标来自应用间连接数据模型AppToAppConnection，定义在 model/connection.go。每个连接维护以下时间序列（TimeSeries）：

• Rtt：往返时延（Round-trip time）
• SuccessfulConnections/FailedConnections：成功 / 失败的连接次数
• Active：活跃连接数
• ConnectionTime：连接建立累计耗时（用于计算平均连接延迟）
• BytesSent/BytesReceived：出站 / 入站流量
• Retransmissions：TCP 重传段数

两个关键的判定方法直接服务于上述检查项：

• HasConnectivityIssues()（model/connection.go）：连接是"真实存在的"（IsActual，即存在成功连接、活跃连接或失败连接），且 RTT 时间序列尾部为空（Rtt.TailIsEmpty()）——即"曾经有流量，现在突然没有了"，这是断连（packet loss / connectivity lost）的典型特征。
• HasFailedConnectionAttempts()（model/connection.go）：连接真实存在，且最新的FailedConnections大于 0。

Status()方法（model/connection.go）将上述判定汇总为最终状态：未激活返回UNKNOWN，连通性问题或连接失败返回CRITICAL，否则为OK。审计器正是基于这两个方法为NetworkConnectivity和NetworkTCPConnections检查添加受影响的上游列表（auditor/network.go）。

值得一提的是，AppToAppConnection还通过Endpoints记录连接外部服务所用的IP:PORT对（model/connection.go），这使 Coroot 在多集群模式下也能把外部连接正确归属到实际服务——这也是跨集群 RTT 检查能独立成类的原因之一。

界面呈现：九类网络图表与总览状态

在详细模式下，网络巡检会渲染以下图表（auditor/network.go）：

每条曲线的图例均以→或←前缀标明方向与上游服务名（如→auth-service、←postgres），便于快速定位是哪条链路出了问题。

在应用总览页，网络状态还会被汇总成一行（api/views/overview/applications.go）：

• 来自NetworkRTT检查：状态非UNKNOWN时沿用其状态（若 SLO 未被违反则强制为 OK），数值展示为格式化后的延迟（如15ms）；
• 来自NetworkConnectivity：状态达到WARNING及以上时展示为packet loss；
• 来自NetworkTCPConnections：状态达到WARNING及以上时展示为failed conns。

也就是说，你无需点进应用详情，就能在总览页一眼看出"延迟高"还是"断连/连接失败"，从而决定排障方向。

阈值配置与覆盖机制

网络巡检的五个检查项均支持按应用或按整个项目覆盖默认阈值。阈值查找逻辑位于CheckConfigs的getRaw方法（model/check.go）：先精确匹配应用 ID，再按 glob 模式匹配，最后回退到项目级默认（ApplicationId{}）。前端表单 api/forms/forms.go 中的CheckConfigForm接收[]*model.CheckConfigSimple，即每个检查只需一个threshold字段即可完成覆盖：

{ "configs": [ { "threshold": 0.05 } ] }

在 Inspections 界面中，你可以对特定应用或整个项目逐项覆盖阈值（对应 Inspections 总览 中描述的 inspection config 能力）。实际生效的阈值由CreateCheck在创建检查时通过checkConfigs.GetSimple(cfg.Id, app.Id)解析得到（model/audit_report.go），未配置时自动回退到 model/check.go 中定义的内置默认值。此外，检查配置还预留了CheckConfigSourceKubernetesAnnotations来源（model/check.go），表明阈值同样可以从 Kubernetes 注解体系注入，具体键名以部署版本的实际文档为准。

结合源码的排障工作流

综合上述实现，用网络巡检排障可以遵循这样的思路：

1. 看总览：在应用总览页观察 Network 状态列——packet loss表示连通性中断（对应NetworkConnectivity），failed conns表示 TCP 连接失败（对应NetworkTCPConnections），具体延迟数值来自 RTT 检查。
2. 看分类：进入应用的Net审计报告，按"集群内 / 外部 / 跨集群"三组 RTT 图区分问题范围。若只有 external 曲线超标，优先检查出站防火墙、DNS、公网链路；若 in-cluster 超标，则重点排查节点网络与负载。
3. 看连接细节：结合Active TCP connections与TCP connection attempts判断是连接数被打满还是新建连接失败；TCP retransmissions升高通常意味着链路丢包；流量图则帮助确认是否突然出现流量中断。
4. 确认断连：HasConnectivityIssues的"RTT 尾部为空"语义意味着断连是"曾经有流量、现在归零"的事件型问题，配合时间轴可准确判断中断发生时刻。
5. 调整阈值：如果某个外部依赖的基线天然偏高（如跨地域 API），可在 Inspections 配置中为该项目或该应用覆盖NetworkRTTExternal阈值，避免误报。

小结

Coroot 网络巡检把"应用与依赖服务之间的网络质量"变成了一套自动化的、可配置的、带上下文结论的检查体系：五个检查项覆盖延迟与连通性两个维度，上游依赖按集群内/外部/跨集群自动分类并采用不同基线，底层AppToAppConnection模型提供了 RTT、连接、流量、重传等完整指标，最终通过审计报告与总览页状态呈现。相关核心实现可继续查阅 auditor/network.go、model/check.go、model/connection.go 以及 api/views/overview/applications.go，官方文档入口为 docs/docs/inspections/network.md 与 Inspections 总览。

【免费下载链接】corootCoroot is an open-source observability and APM tool with AI-powered Root Cause Analysis. It combines metrics, logs, traces, continuous profiling, and SLO-based alerting with predefined dashboards and inspections.项目地址: https://gitcode.com/GitHub_Trending/co/coroot