实例监控

本指南的目的

ZEC 的产品定位建立在三大支柱之上：

1. 全球覆盖。 ZEC 的覆盖范围超越主流超大规模云服务商，但我们从不会将服务延伸到无法保障生产级网络和计算质量的地区。我们提供的每一个节点位置，都是我们能够全力支撑的位置。

2. 面向生产而构建。 每一行代码、每一个指标、每一个运营决策，都是为了让运行在 ZEC 上的工作负载拥有稳定、可预期的环境——并为您提供信任它所需的依据。ZEC 不是 VPS，它是面向生产应用的基础设施。

3. 无中间层。 产品界面有意保持精简、概念清晰。当某个问题无法通过配置项暴露时，支持团队会直接将其转交给工程团队处理。我们不会在您与真正能解决问题的人之间设置任何翻译层。

本指南是第二大支柱的实践体现。

为什么指标目录是"面向生产而构建"的组成部分

ZEC 实例监控 Dashboard 上的每个面板，都源于一次真实的生产故障——由我们、由客户，或由双方共同经历过。这些面板没有任何装饰性的存在。

但仅仅列出面板是不够的。在故障期间，真正需要做出判断的人——应用负责人、值班工程师、支持团队——没有时间去学习 30 个指标的含义。他们需要知道：

• 我现在要回答的问题是什么？

• 哪个面板能回答这个问题？

• 面板出现异动时，我该怎么做？

如果缺少这样的框架，即便是最好的指标也只是一张没人看的图表。有了它，同样的指标就能成为区分五分钟快速定位与两天漫长排查的关键。

要访问监控 Dashboard，请前往 ZEC 实例页面，选择一个实例，然后打开监控标签页。

本指南围绕生产故障排查中反复出现的问题来组织内容。每个问题对应一个简短的页面，列出相关面板、说明其含义，并告诉您面板出现异动时应采取什么行动。如果您清楚自己要问的是哪个问题，就可以直接找到答案。

汇总

#	问题	可能原因	处理方式	关键 Console 面板
Q1	我的实例是否受宿主机过度分配的影响？	基础设施	联系支持	Hypervisor CPU Queue Time、CPU / Memory / I/O Pressure
Q2	问题是否出在我自己的工作负载上？	应用	分析工作负载，优化工作集	Memory Utilization (Real Utilization)、Swap In / Out、KSWAPD Steal、KSWAPD LHWM、System Load Average
Q3	网络层是否丢弃了我的数据包？	通常是速率限制，偶尔是基础设施问题	提升 IP 带宽或平滑突发流量；如果 vNIC 丢包不为零，联系支持	IP Bandwidth、IP Packet Transmission、vNIC Bandwidth、vNIC Packet Transmission
Q4	我的 CPU 实际消耗在哪里？	应用	分析工作负载	CPU Utilization / User / System / IOWait / SoftIRQ / Idle / Other、Hypervisor CPU Time / User / System
Q5	我的磁盘表现如何？	通常是饱和，偶尔是后端问题	降低请求速率或联系支持	Throughput、Operations (IOPS)、Disk Utilization
Q6	实例是否存活，其操作系统运行状态如何？	应用	重启排查；排查连接泄漏	Uptime — Running for、TCP Connections
Q7	我的 GPU 是否健康？	VRAM 由您负责；散热 / 重置属于基础设施问题	针对内存溢出进行调优；散热和重置事件会自动上报	GPU 面板

"可能原因"一列让您一眼就能知道当面板出现异动时，应从哪里开始排查。大多数面板能清晰地指向您的应用或底层基础设施——这种区分正是本 Dashboard 最重要的价值所在。

您可以从本 Dashboard 获得什么

• 没有虚荣指标。 如果一个指标无法驱动决策——开工单、修改配置、扩展工作负载——它就不会出现在 Dashboard 上。

• 关键处相互验证。 CPU 抢占时间从 Hypervisor 侧和 Guest 侧两个维度报告。内存既报告含缓存的数值，也报告真实占用数值。您永远不需要只凭单一数字下判断。

• 在数据真正发生的地方进行测量。 网络丢包和 CPU 争用在 Hypervisor 侧进行测量，因为等到 Guest 侧能观察到时，证据早已消失。应用层信号（负载均值、Swap 活动、TCP 套接字）在 Guest 内部进行测量，因为那里才是工作负载真正运行的地方。

当本 Dashboard 上的某个面板出现异动时，下一步行动应当是显而易见的。这正是它存在的全部意义。