1、监控体系概述：为什么需要内存监控、监控体系的分层架构、告警体系的核心要素
大家好，我是你们的老朋友。今天咱们正式开篇，聊聊内存监控体系。
说实话，我做了十几年运维，见过太多因为内存问题导致的线上事故。有的服务挂了，有的数据库崩了，有的甚至整个集群都瘫痪了。你想想看，这些事故背后，有多少是因为「没有监控」或者「监控不到位」？
所以，第一节课，咱们先把地基打牢。搞清楚三个问题：为什么需要内存监控？监控体系怎么分层？告警体系的核心是什么？
1.1 为什么需要内存监控？
先问大家一个问题：你的服务器内存，真的够用吗？
我猜很多人会说：「我看了 free -m，还有 30% 空闲呢。」
嗯，这里要注意。内存空闲不代表安全。我在项目中遇到过好几次，内存看起来还有不少，但应用已经频繁 Full GC，响应时间飙升到几十秒。为什么？因为内存碎片、因为 JVM 堆外内存泄漏、因为 Page Cache 占用过高。
说白了，内存监控不是看「还剩多少」，而是看「怎么用的」。我们需要知道：
- 内存使用率：总内存、已用、可用、缓存/缓冲区
- 交换分区使用：swap 是否被大量使用（这是性能杀手）
- 进程级内存：哪个进程在吃内存？RSS、VSZ、共享内存
- 内存分配与回收：OOM Killer 是否被触发？内存分配失败次数
- 应用层内存：JVM 堆内存、堆外内存、Native Memory
我曾经遇到过一个案例：某核心服务每天凌晨 3 点准时 OOM。查了三天，最后发现是定时任务加载了一个巨大的配置文件，导致堆内存瞬间打满。如果没有进程级内存监控，这种问题根本无从下手。
核心观点：内存监控不是「可选项」，而是「必选项」。没有内存监控，你就像在黑夜中开车，不知道什么时候会撞上墙。
1.2 监控体系的分层架构
好，既然知道了为什么要监控，那接下来聊聊怎么搭这个体系。
我个人习惯把监控体系分成四层。你想想看，这就像盖房子，地基、框架、装修、家具，缺一不可。
| 层级 | 名称 | 核心职责 | 常用工具/技术 |
|---|---|---|---|
| L1 | 数据采集层 | 从操作系统、中间件、应用中采集内存指标 | /proc/meminfo, /proc/pid/status, JMX, eBPF |
| L2 | 数据存储层 | 时序化存储，支持高并发写入和快速查询 | Prometheus, VictoriaMetrics, InfluxDB |
| L3 | 分析与告警层 | 规则引擎、异常检测、告警收敛与通知 | Prometheus Alertmanager, Grafana, 自研引擎 |
| L4 | 可视化与自愈层 | 仪表盘展示、根因分析、自动化恢复 | Grafana Dashboard, 自动化脚本, K8s HPA |
我来展开说说每一层。
L1：数据采集层
这是最底层，也是最容易出问题的一层。我见过很多团队，采集器配置错了，导致数据不准，告警全乱套。
举个例子，采集「内存使用率」时，要不要算上 buffers/cache？在 Linux 中，这部分内存可以被回收，所以严格来说不算「已用」。但如果你用 free 命令的默认输出，它会把 buffers/cache 算进去，导致使用率虚高。
我个人建议：使用 /proc/meminfo 中的 MemAvailable 字段，这才是真正可用的内存。
L2：数据存储层
内存指标是典型的时序数据，每秒甚至毫秒级采集。存储层必须支持高写入吞吐和高效压缩。
Prometheus 是当前的主流选择。但要注意，Prometheus 是单机架构，如果指标量太大（比如超过千万时间序列），建议用 VictoriaMetrics 或 Thanos 做扩展。
L3：分析与告警层
这一层是核心。数据采集了、存了，但如果没有分析，就是一堆数字。告警规则怎么写？阈值怎么设？
我习惯把告警分成三类：
- 阈值告警：内存使用率 > 90%，持续 5 分钟
- 趋势告警：内存使用率在 30 分钟内持续上升，斜率超过某个值
- 预测告警：基于历史数据，预测未来 1 小时内会达到阈值
嗯，这里要注意。阈值告警最简单，但容易误报。趋势告警更智能，但需要调参。预测告警最先进，但计算开销大。我建议先从阈值告警入手，逐步叠加趋势告警。
L4：可视化与自愈层
最后是展示和自动化。Grafana 是标配，但仪表盘设计也有讲究。我见过有人把几十个图表堆在一个页面上，根本看不清。
我的经验是：一个仪表盘只关注一个维度。比如「主机内存概览」只放主机级指标，「应用内存详情」只放 JVM 指标。不要混在一起。
小技巧：在 Grafana 中，使用「变量」功能，可以动态切换主机或应用。这样你只需要一个仪表盘，就能覆盖所有实例。
1.3 告警体系的核心要素
告警体系，说白了就是「出了问题怎么通知你」。但这里坑很多。
我曾经犯过一个错误：给所有告警都设置了 P0 级别。结果半夜收到几十条告警，全是「内存使用率超过 80%」。最后我直接静音了所有告警——嗯，这显然不对。
告警体系的核心要素，我总结为四点：
- 告警分级：P0（致命）、P1（严重）、P2（警告）、P3（通知）。内存 OOM 是 P0，内存使用率超过 90% 是 P1，超过 80% 是 P2，超过 70% 是 P3。
- 告警收敛：同一个问题，不要重复告警。比如一台主机内存高，不要同时触发「主机内存高」和「进程内存高」两条告警。我习惯用「告警聚合」策略，把相关告警合并成一条。
- 告警抑制：如果已经触发了 P0 告警，那么相关的 P1/P2 告警应该自动抑制。避免告警风暴。
- 告警通知：不同级别走不同通道。P0 用电话+短信，P1 用即时消息+邮件，P2 只用邮件。别让 P3 告警半夜吵醒你。
避坑指南：我曾经把 P0 告警的阈值设得太低，结果每周都要处理几十次「假阳性」告警。后来我调整了策略：P0 告警必须满足「持续超过阈值 5 分钟」且「趋势持续上升」。这样误报率降低了 80%。
最后，我想强调一点：告警不是目的，解决问题才是。一个好的告警体系，应该让你在收到告警时，就知道大概是什么问题、应该怎么处理。而不是让你一脸懵逼地登录服务器，然后开始查日志。
好了，第一节课就到这里。下一节，咱们会深入讲解「内存指标采集的底层原理」，包括 /proc/meminfo 的每个字段含义、如何用 eBPF 采集更细粒度的内存事件。敬请期待。