> For the complete documentation index, see [llms.txt](https://docs.console.zenlayer.com/welcome/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.console.zenlayer.com/welcome/cn/elastic-compute/instance-monitoring.md).

# 实例监控

## 本指南的目的

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

1. **全球覆盖。** ZEC 的覆盖范围超越主流超大规模云服务商，但我们从不会将服务延伸到无法保障生产级网络和计算质量的地区。我们提供的每一个节点位置，都是我们能够全力支撑的位置。
2. **面向生产而构建。** 每一行代码、每一个指标、每一个运营决策，都是为了让运行在 ZEC 上的工作负载拥有稳定、可预期的环境——并为您提供信任它所需的依据。ZEC 不是 VPS，它是面向生产应用的基础设施。
3. **无中间层。** 产品界面有意保持精简、概念清晰。当某个问题无法通过配置项暴露时，支持团队会直接将其转交给工程团队处理。我们不会在您与真正能解决问题的人之间设置任何翻译层。

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

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

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

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

* **我现在要回答的问题是什么？**
* **哪个面板能回答这个问题？**
* **面板出现异动时，我该怎么做？**

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

要访问监控 Dashboard，请前往 [ZEC 实例](https://console.zenlayer.com/zec/virtualMachine)页面，选择一个实例，然后打开**监控**标签页。

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

## 汇总

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

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

## 您可以从本 Dashboard 获得什么

* **没有虚荣指标。** 如果一个指标无法驱动决策——开工单、修改配置、扩展工作负载——它就不会出现在 Dashboard 上。
* **关键处相互验证。** CPU 抢占时间从 Hypervisor 侧和 Guest 侧两个维度报告。内存既报告含缓存的数值，也报告真实占用数值。您永远不需要只凭单一数字下判断。
* **在数据真正发生的地方进行测量。** 网络丢包和 CPU 争用在 Hypervisor 侧进行测量，因为等到 Guest 侧能观察到时，证据早已消失。应用层信号（负载均值、Swap 活动、TCP 套接字）在 Guest 内部进行测量，因为那里才是工作负载真正运行的地方。

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