监控KVM虚拟机，先把宿主机、libvirt和虚机内部三层指标串起来，再用Prometheus+Grafana或Zabbix落地，别只盯着虚机里的CPU数字。
监控KVM虚拟机的核心思路：宿主机、libvirt、虚机三层一起看
KVM监控像查水管，先看总阀，再看分支，宿主机是总阀，libvirt是阀门状态，虚机内部是末端水压，只盯虚机里的top,很容易漏掉宿主机资源争抢。
据行业公开资料，KVM环境里相当一部分性能问题来自宿主机资源超分和磁盘IO争抢，行业共识认为，虚机卡顿先查宿主机负载、内存回收和存储延迟,比直接进虚机翻日志更快。
三层指标各管什么：
- 宿主机层：CPU使用率、load、内存可用量、swap、磁盘await、网络丢包、KSM共享页。
- libvirt层：domain状态、vCPU时间、block统计、interface统计、balloon内存。
- 虚机层：vCPU steal time、内存使用、磁盘延迟、业务进程状态。
据统计，多数KVM故障先表现在宿主机资源争抢上,所以监控顺序别倒过来。
KVM虚拟机监控用什么工具好：开源组合与商业方案的选择
这个问题没有唯一答案，关键看团队规模和运维习惯，业内专家指出，中小企业优先用开源组合，能把指标、告警和看板跑通,比堆商业授权更实际。
常见工具分三类：
- Prometheus + Grafana + libvirt_exporter + node_exporter：指标采集灵活，告警规则可版本化,适合有一定Linux基础的团队。
- Zabbix：模板成熟，适合已有Zabbix体系的环境,宿主机和虚机可统一纳管。
- Netdata、Checkmk、Nagios：轻量或传统监控,适合小规模快速上线。
- 商业平台：按节点或虚机收费，开箱即用，授权费用通常较高,适合合规和托底要求强的场景。
选型别只看功能，先确认三件事：能不能采到libvirt指标、告警能不能落到人、历史数据存多久，这三件事定下来,工具基本就定了。
必盯的六类指标与采集路径
宿主机层
宿主机先看资源水位和争抢,常用命令：
top -1 pidstat -p $(pgrep qemu) 1 5 iostat -x 1 5 sar -n DEV 1 5
重点看load、MemAvailable、磁盘await、网络错误，磁盘await持续偏高,虚机里再调参数也有限。
虚机层
libvirt自带命令就能拿到不少指标：
virsh list --all virsh domstats vm01 --state --cpu-total --balloon --block --interface virsh domblkstat vm01 vda virsh domifstat vm01 vnet0 virsh cpu-stats vm01 --total
虚机内部再装qemu-guest-agent，能补上文件系统、IP和内部资源信息，注意，agent不是万能,宿主机层指标它看不到。
libvirt层
libvirt层重点看domain是否running、vCPU时间是否异常、block读写延迟是否升高，据libvirt官方文档，virsh domstats适合做周期性采集,输出可被脚本解析后送进监控系统。
KVM和VMware监控方案对比：成本、指标与落地难度
KVM和VMware的监控入口不同，KVM更依赖libvirt和宿主机操作系统，VMware有vCenter统一入口,对比看表更直观。
| 维度 | KVM监控 | VMware监控 |
|---|---|---|
| 监控入口 | libvirt、宿主机OS、虚机agent | vCenter、ESXi、虚机agent |
| 指标粒度 | 依赖exporter和命令采集，灵活但需自建 | 平台内置较完整，开箱即用 |
| 成本结构 | 软件授权低，人力与自建成本较高 | 授权费用较高，运维体系成熟 |
| 落地难度 | 需要Linux和Prometheus基础 | 图形化配置多，学习曲线较平 |
| 适合场景 | 成本敏感、技术团队有自建能力 | 追求统一平台和厂商支持 |
选型建议很直接：已有KVM集群和Linux团队，Prometheus组合更顺手；强依赖统一平台和商业支持，VMware体系更省心，别为了“看起来高级”上重平台,最后告警没人看。
中小企业KVM虚拟机监控最佳实践：从零搭一套轻量监控
部署Prometheus与libvirt_exporter
以常见Linux发行版为例,路径如下：
- 在监控机安装Prometheus和Grafana,用官方二进制或包管理器均可。
- 每台KVM宿主机部署
node_exporter，默认端口9100。 - 宿主机部署
libvirt_exporter，确保运行用户属于libvirt组，默认端口常见为9177。 - 在Prometheus的
scrape_configs里加job：
scrape_configs:
- job_name: 'kvm-host'
static_configs:
- targets: ['kvm-host01:9100']
- job_name: 'libvirt'
static_configs:
- targets: ['kvm-host01:9177']
在Grafana导入Node Exporter看板,再按libvirt_exporter实际指标名补KVM看板。
Grafana看板与告警规则
看板先放四块：宿主机资源水位、虚机状态、磁盘延迟、网络流量,告警规则从简单开始：
- alert: HostLoadHigh expr: node_load1 > 8 for: 10m - alert: HostMemLow expr: node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes < 0.15 for: 10m
虚机vCPU steal、balloon和block延迟的PromQL，要按exporter实际指标名调整，别直接复制网上规则，指标名对不上,告警就是空的。
日常巡检命令清单
virsh list --all：看虚机是否running。virsh domstats vm01：看domain资源统计。virsh domblkstat vm01 vda：看块设备读写。virsh domifstat vm01 vnet0：看网络收发和错误。iostat -x 1 5：看宿主机磁盘压力。sar -n DEV 1 5：看网卡流量和丢包。
北京KVM虚拟机监控运维的常见交付方式与成本构成
自建、托管与外包
北京地区KVM虚拟机监控运维,常见三种交付方式：
- 自建：团队自己搭Prometheus、Grafana和告警，控制力强,人力投入也高。
- 托管：把监控平台放到云上或IDC，由服务商维护采集和存储,适合没有专职监控团队的公司。
- 外包：按年或按节点委托运维，包含巡检、告警响应和月度报告,适合虚机规模不大但要求有人兜底的场景。
据工信部数据，近年来企业IT基础设施虚拟化比例持续提升，监控和运维的边界越来越细，北京人力成本较高，自建团队的综合成本通常高于多数二线城市,外包和托管因此更常见。
价格区间怎么判断
价格别只问“一年多少钱”,拆开看：
- 商业监控授权：按宿主机节点或虚机数量计费,规模越大单价越有谈判空间。
- 开源自建：软件授权低，主要成本是人力、服务器和存储。
- 外包服务：按节点、按年或按响应级别报价,驻场通常高于远程。
- 地域差异：北京、上海、深圳的运维人力报价通常高于其他地区。
判断价格是否合理，看三件事：采集覆盖多少宿主机和虚机、告警响应时限、是否含月度巡检报告，只比总价，容易买到“只装看板不处理告警”的服务。
KVM虚拟机监控常见问题Q&A
监控KVM虚拟机需要装agent吗？
宿主机层不需要。node_exporter和libvirt_exporter跑在宿主机上，就能采到宿主机和domain指标，要在虚机内部看进程、文件系统和业务端口，再装qemu-guest-agent或虚机内node_exporter，agent补的是内部视角,不替代宿主机监控。
KVM虚拟机监控和容器监控有什么区别？
KVM是硬件虚拟化，监控对象是宿主机、libvirt domain和虚机内部，容器共享内核，监控重点在cgroup、namespace和容器运行时，KVM看vCPU steal和balloon，容器看CPU throttling和内存limit,两套指标体系别混用。
KVM虚拟机监控数据多久采集一次合适？
采集间隔通常设成15秒到60秒，关键业务可缩短，长期存储再做降采样，间隔太短会增加宿主机和存储压力，太长会漏掉短时IO毛刺，先按30秒跑一周,看告警量和存储增长再调整。