Prometheus 与 Grafana 监控入门：个人服务应该监控哪些指标、如何设置告警 未开始

题记与说明

报告元信息
- 时间截面：2026-10-31（写作日）
- 研究方法：横纵双轴综合。纵轴梳理 Prometheus/Grafana 这条技术线从 2012 年诞生到 2026 年的完整发展脉络；横轴在当下时间截面上，把"Prometheus + Grafana 自托管标准栈"与四类替代路线做系统对比，并聚焦课题的两个核心子问题——"个人服务应该监控哪些指标"与"告警如何设置"。
- 数据来源：全部关键事实来自撰写当日实际执行的网络检索与网页读取（两份分章报告各自声明的检索均在当日完成），来源 URL 附于正文与文末。凡未能直接验证的细节均在文中明示，未给出编造数字。
- 本文由同日完成的两份分章报告（纵轴篇、横轴篇）综合修订而成，已消除两篇之间的重复表述，并对个别口径差异做了统一处理（见文末"综合说明"）。

final 修订说明（2026-10-31，按独立审读意见逐条处理，正文未被质疑的内容原样保留）：
① 统一资源口径：TL;DR、1.3、2.2、3.7、E1 全文改为同一口径——标准栈小规模实测约 0.5–1GB 内存（单一社区样本，ref 25），1GB VPS 能跑但无余量、2GB 左右从容；VictoriaMetrics 的 RSS 16.8GB vs 69GB 明确标注为大规模基准、不外推家用，VM 定位从"跑不动就换"降为"更省内存但非必需"；1.3 补记 Prometheus 3.0 的 TSDB 效率改进（当日直读官方公告确认，此前该句无出处）。
② 新增 3.8"最小告警配置示例"：证书过期、磁盘水位、心跳（Watchdog + Healthchecks 死开关）三条规则的 PromQL 与 Alertmanager YAML（阈值均为示例值），并给 absent() 兜底写法——修复全文零代码块、核心子问题 B 只有概念没有做法的问题，呼应标题承诺。
③ E 类口径统一：2.4/2.5 两表 E 列表头统一为"换件/托管（VM / Grafana Cloud / Datadog）"并逐行补齐三成员（原分别为"Grafana Cloud"与"Grafana Cloud/VM"）；InfluxDB 3 降格为"补充观察（非路线）"，2.1 加注说明其不入对比表。
④ 去重：3.4 删去与 2.4 逐字重复的"开箱覆盖与表达深度呈反比"展开（改为回指 2.4）；心跳论点主表述收口到 2.5，3.4 与 3.7 改为回指；"知识资产可迁移"主表述收口到 3.5，TL;DR 与 E1 处的重复展开删除。
⑤ 来源修复："官方称 5 分钟部署"三处（2.2 上手成本行、3.1、3.7 推荐表）改为社区实测"约 10 分钟"（Uptime Kuma GitHub README 无 5 分钟表述，经当日直读核实）；"10 分钟 vs 半天"改为 ref 25 实测"10 分钟 vs 2–4 小时"；"2026 年对比文章结论很直白"改为本报告自 2.2 推出的判断；Zabbix 8.0 特性来源由路线图改为官方 What's New（OTLP/APM/CEP/ClickHouse/移动端经当日直读确认）；Grafana 3.0 插件仓库补引文并在 1.4 时间线补 2016 行；2.2 中 B 路线资源占用一处与 ref 25 实际内容不符的转述一并改正。
⑥ "社区主流终态"降格为"有社区文章总结的一种常见组合"（ref 25 为单一来源，其原话是二者"在测不同的东西、不同的时间尺度"）。
⑦ 术语修复："双 Watchdog"改为"自建 Watchdog/absent() 规则"并在 3.8 给出解释；Datadog 的 Watchdog 加"同名不同物"注释；"磁盘 I/O 降低约 100 倍"统一为"降至约 1/100"；TL;DR 的"四个黄金信号/RED"补一句层级关系。
⑧ 新增 3.9"下一步动手清单"，正面回答读者最可能追问的四问：第一条告警规则怎么写、最小部署骨架与 Grafana Cloud 接入步骤、1GB 内存 VPS 能否跑标准栈、Uptime Kuma 与 Prometheus 告警如何去重。

TL;DR

这条线十四年的历史就是"企业级监控平民化"：Borgmon 思想经 SoundCloud 变成开源 Prometheus（2012），Grafana 把画图做到人人可上手，CNCF 与 Kubernetes 浪潮把两者焊成事实标准，Grafana 8 统一告警（2021）与 Prometheus 3.0 转正 OTLP（2024）先后拆掉配置与协议两道墙。到 2026 年，"监控什么、怎么告警"已从开放题变成选择题：指标看三层口径——服务层盯 RED（四个黄金信号在请求驱动服务上的具体化，抽象与具体是层级关系而非两种方法论，见 2.4）、资源层 USE、家用特供项（证书、磁盘、备份、心跳）；告警学 Alertmanager 分组/静默/抑制/路由四概念，这是全行业通用心智模型。2026 年 OTLP 协议层已收敛，选型差异转移到告警工作流深度、运维负担与商业模式。务实建议：只想知道"挂没挂"用 Uptime Kuma 兜底；想学业界标准就上 Prometheus + Grafana 栈或 Grafana Cloud 免费层起步；标准栈小规模实测内存约 0.5–1GB，1GB VPS 能跑但无余量、2GB 左右从容（见 2.2）；机器实在捉襟见肘时，VictoriaMetrics 是更省内存的替换项而非必需品，规则与看板原样保留。

一、纵轴：发展脉络

1.1 引子：一个曾经不存在的问题

"个人服务应该监控哪些指标、如何设置告警"——这个今天有标准答案的问题，在 2012 年之前几乎不存在。彼时个人服务器监控的默认选项是装一个 Nagios 或 Zabbix，配几条阈值检查（进程在不在、磁盘满没满），出了事发封邮件。个人用户与企业用户共享同一套"检查式监控"范式：它为静态、长寿命的服务器设计（本会话检索中多篇 Zabbix vs Prometheus 对比文对这一范式转换的叙述一致）。这十多年真正发生的故事，是一条"企业级监控工具平民化"的曲线——纵轴的每个阶段，都是这道门槛下降的一级台阶。

1.2 六个阶段

阶段一：史前史（约 2000 年代–2012）——Borgmon 的思想与检查式监控的黄昏

Google 内部构建了 Borgmon——基于时序数据生成告警的监控系统。《SRE：Google 运维解密》（O'Reilly，2016）写道："尽管 Borgmon 仍是 Google 内部工具，但把时序数据作为告警数据源的思想，如今已经通过 Prometheus 这类开源工具惠及所有人"（经 Wikipedia: Prometheus (software)) 引注确认）。同期的主流世界仍是检查式监控：Nagios、Zabbix、MRTG 围绕"计划任务探测 + 阈值判定 + 正常/警告/严重三态"构建，适合静态机房；指标侧的中间形态是 StatsD + Graphite——能把数值推到时序库画图，但缺乏多维数据模型和查询语言。驱动变化的是云计算与容器化："服务器"从常驻实体变成秒级生灭的容器，检查式监控的静态假设开始失效。这个矛盾在一家名叫 SoundCloud 的流媒体公司率先爆发。

阶段二：双星诞生（2012–2014）——SoundCloud 的工作项目与瑞典人的副业

2012 年，Matt T. Proud 与 Julius Volz（后者刚从 Google 离职加入 SoundCloud）在 SoundCloud 发起 Prometheus：容器化的基础设施让既有 StatsD + Graphite 栈无法应付，两人怀念 Google 式多维监控，决定自建开源方案，一开始就以"通用监控系统"而非公司内部工具定位（Wikipedia: Prometheus (software))；PromCon 2017 上 Volz 原话："I joined SoundCloud back in 2012 coming from Google...we were very inspired by that and finally decided to build our own open-source solution"）。Wikipedia 信息框记录首发日期为 2012 年 11 月 24 日；2013 年已在 SoundCloud 内部生产使用。

2013 年 12 月 5 日，瑞典开发者 Torkel Ödegaard 提交 Grafana 首个 commit（Flagsmith 播客《The Grafana Labs Origin Story》），名字即 Graphite + Kibana 的合成词。2014 年 1 月 Grafana 1.0 公开发布（Wikipedia: Grafana），本质是 Kibana 3 的 fork：Ödegaard 喜欢 Kibana 拖拽建面板的体验但嫌它视觉噪音太大，于是做出两个早期设计决定——删掉所有面板按钮、为"挂在电视墙上常年展示"优化。这两条后来被公司做成海报："Don't get in the way of the data" 和 "Democratize metrics"（民主化指标：让可观测性工具对组织里每个人可用，而不只是那一个运维）。这两个原则直接决定了 Grafana 后来对个人用户的亲和力（一手来源：Ödegaard，《The (Mostly) Complete History of Grafana UX》，本会话全文直读）。2014 年公司前身 Raintank 成立，2016 年更名为 Grafana Labs。Grafana 1.x 仍是纯前端应用——没有后端、没有登录、面板存在 JSON 文件或 Elasticsearch 里。

阶段三：开源引爆与标准化（2015–2017）——官宣、1.0/2.0 与 CNCF

2015 年 1 月 26 日，SoundCloud 开发者博客发表《Prometheus: Monitoring at SoundCloud》，项目正式公开（该文直读两次超时，存在性、日期与要点经 Wikipedia 引注与多路搜索交叉确认，developers.soundcloud.com）。2015 年 8 月 13 日 Grafana 2.0 发布：引入 Go 编写的后端、内置 SQLite、登录系统、UI 内管理数据源——从此不用 Elasticsearch 也能存面板，部署门槛骤降为"解压一个二进制"。2016 年 5 月 9 日 CNCF 宣布接受 Prometheus 为其第二个托管项目，仅次于 Kubernetes（Wikipedia，引 CNCF 官宣）；同年 7 月 Prometheus 1.0 发布。2017 年 11 月 Prometheus 2.0 发布，这是存储引擎的彻底重写：官方博客给出的数字是磁盘 I/O 降至约 1/100、CPU 效率提升约 3 倍、内存占用降为约 1/5（官方博客《Changes in Prometheus 2.0》），新 TSDB（WAL + 倒排索引 + 分块压缩）从此成为 Prometheus 的技术招牌。2016 年 Grafana 4.0 把告警直接做进 Grafana——第一次触碰告警域，为 2021 年的"统一告警"埋下伏笔（Ödegaard UX 史长文："Version 4...the big thing was of course alerting"）。

阶段四：CNCF 毕业与可观测性生态成形（2018–2019）

2018 年 3 月 Grafana 5.0 发布，官方称之为"史上最大的 Grafana 版本"：新网格布局引擎（干掉了令人费解的 rows 概念）、仪表盘文件夹与权限、版本管理。2018 年 8 月 9 日 Prometheus 从 CNCF 孵化器毕业，成为继 Kubernetes 之后第二个毕业项目（GeekWire 报道），"云原生监控事实标准"地位坐实。同年 11 月 Grafana Loki 首次亮相——"为日志做 Prometheus 那样的事"；2019 年 11 月 Loki 1.0 GA。2019 年 Grafana 6.0 发布（面板可视化类型可随时切换）。也是在这一时期，监控方法论定型为可背诵的口诀：RED（Rate/Errors/Duration，Weave 的 Tom Wilkie 等人推广，面向请求驱动的服务）与 USE（Utilization/Saturation/Errors，Brendan Gregg 提出，面向 CPU/内存/磁盘等资源）（Weave: RED Method for Prometheus、Last9: RED vs USE）。"该监控哪些指标"从此有了标准答案的雏形。

阶段五：告警统一、AGPL 与商业化狂奔（2020–2022）

2021 年 4 月 20 日，Grafana Labs 宣布 Grafana/Loki/Tempo 从 Apache 2.0 改用 AGPLv3（仅对 8.0+ 生效），官方理由直指云厂商：不允许托管服务"白嫖"开源而不回馈（官方公告）；同年 8 月完成 2.2 亿美元 C 轮融资、估值 30 亿美元。2021 年 6 月 Grafana 8.0 发布，统一告警（Unified Alerting）登场——把 Grafana 自带告警与 Prometheus/Alertmanager 风格的告警合并为一套系统，告警规则可跨数据源，通知点支持 Slack/PagerDuty 等（官方 what's new v8.0）。这次迁移争议不小（老告警自动转换后行为异常，老版告警引擎最终在 Grafana 10 中移除），但对个人用户的意义重大：只有 Grafana 也能配告警了，不必再单独运维一个 Alertmanager。2022 年 8 月 Mimir 1.0 发布（Cortex 分叉为自家长期存储）；2022 年 11 月 Volz 发表《Prometheus Turns 10》纪念首个公开 commit 十周年（prometheus.io（URL 为按官方博客格式重建，两次直读失败））。

阶段六：与 OpenTelemetry 合流、AI 加持（2023–2026）

2024 年 4 月 GrafanaCON 同时发布 Grafana 11、Loki 3.0 与新采集器 Grafana Alloy——OpenTelemetry Collector 的供应商中立发行版，统一了 metrics/logs/traces 采集管线（老采集器 Grafana Agent 于 2025 年 11 月 EOL）。2024 年 8 月 Grafana Labs 融资 2.7 亿美元、估值超 60 亿美元（TechCrunch，经 Wikipedia 引注）。2024 年 11 月 14 日 Prometheus 3.0 发布——七年来首个大版本：全新 UI、OTLP 原生接收端点转正（OpenTelemetry SDK 可直接把指标灌进 Prometheus）、Remote Write 2.0、原生直方图（官方公告）。这一步标志着 Prometheus 与 OpenTelemetry 两大标准正式合流。2025 年 5 月 8 日 Grafana 12 发布，主打 observability as code（仪表盘/告警/配置的 Terraform/CLI 声明式管理）、动态仪表盘（官方发布文）；2025 年 11 月 Beyla 被捐入 OpenTelemetry。2026 年 4 月 21 日 Grafana 13 发布，主打 Suggested Dashboards——按数据源自动推荐现成面板（官方发布文）。截至写作日，Grafana 稳定版 13.3.0（2026-10-27），Prometheus 稳定版 v3.11.2（2026-04-13）（均见 Wikipedia 信息框，本会话直读）。

1.3 贯穿线：个人服务"监控哪些指标、怎么告警"的答案演化

把镜头从企业拉回到本课题真正关心的尺度——一两台个人服务器，答案的演化大致如下：

三个值得展开的点：

1. exporter 组合成为个人服务器的"标准三件套"：node_exporter（系统资源，默认端口 9100；Windows 对应 windows_exporter，端口 9182，见 官方 exporter 列表与 windows_exporter）、blackbox_exporter（黑盒探测 URL 可用性、延迟、证书过期）、应用自身的 /metrics 端点。本会话检索的多篇 node_exporter/blackbox 教程与 RED/USE 方法学文章印证了这一组合的主导地位。
2. 告警体验的两次平民化：第一次是 Alertmanager 把"分组/去重/抑制/静默"这套通知治理做成开箱即用的配置（Alertmanager 官方文档）；第二次是 2021 年 Grafana 8 统一告警之后，个人用户不必再理解 Prometheus rules 与 Alertmanager 的双层结构，在 Grafana UI 里点几下就能让告警直达 Telegram 或 Discord（两者均有官方配置文档）。
3. 部署门槛的两端：一端是 Grafana Cloud 永久免费档——无需信用卡，含指标/日志/追踪与告警，1 万活跃序列、50GB 日志、50GB 追踪、3 个活跃用户、14 天指标保留，Pro 从 $19/月起（官方定价页、免费档页面、用量限额文档）；另一端是 VictoriaMetrics 单机版——官方大规模对比基准显示其内存占用远低于 Prometheus（RSS 16.8GB vs 69GB）、磁盘占用约为 1/10（0.4 vs 4 字节/数据点）（对比检索：Last9: Prometheus vs VictoriaMetrics）。注意：这是大规模基准，不能直接外推到家用规模——家用场景下标准栈的实测口径约 0.5–1GB 内存（单一社区样本，见 2.2 与 ref 25），VM 在小机器上的角色是"更省"而非"必需"。Prometheus 自身也在跟进：3.0 官方公告即以同负载 macrobenchmark 展示了 TSDB 在 CPU 与内存上的效率改进（官方公告）。

1.4 时间线速查表

二、横轴：横向对比

2.1 对比对象与宏观背景

在"给自己的个人服务（几台 VPS、一台家庭 NAS、十来个 Docker 容器、若干 Web 站点）做监控 + 告警"这个目标下，2026 年当下市场上有五条主要路线：

注：E 类另有一个 InfluxDB 3 + Telegraf 变体（见 2.3 末尾的 E3），因对入门者概念更杂、不作首选，本报告将其列为"补充观察"而非路线，不进入后续各对比表。

一个重要的时代背景：OpenTelemetry 正在成为全行业的数据协议收敛点。Prometheus 3.0（2024-11）把 OTLP 接入转正（官方公告）；Zabbix 8.0 LTS（2026）也把 OTLP/APM 列入官方 What's New（官方 What's New、第三方评述）；Grafana Alloy 原生支持 OTel 采集。这意味着今天无论选哪条路线，"指标怎么定义、怎么传输"正在快速趋同——选型的差异越来越多地体现在告警工作流、运维负担和商业模式上，而不是"能不能采到数"上。这是横轴对比的第一条宏观结论。

2.2 路线级总览对比表

2.3 逐项对比要点

B 路线（Uptime Kuma + Beszel）——本课题最直接的分流对手。 Uptime Kuma 2.0 正式版于 2025-10-20 发布（架构升级、MariaDB 支持、远程监控节点），到 2026 年 10 月已迭代至 2.5.x（releases、v2 新特性）。Beszel 是 2026 年社区上升最快的轻量监控新星：hub-agent 架构，覆盖 CPU/内存/磁盘/网络与 Docker 容器统计（Beszel）。关键差异在"深度"：Uptime Kuma 回答的是"活着吗"（HTTP 状态码、关键词、端口、证书过期、心跳），没有指标历史的多维查询——你无法回答"过去一周我的 API p95 延迟是多少"；Prometheus 栈回答的是"活得好不好、为什么、从什么时候开始"。告警侧则反过来：Uptime Kuma 的通知渠道矩阵远比 Alertmanager 开箱形态丰富（Alertmanager 内置邮件/Slack/PagerDuty/Webhook 等接收器，Telegram 等更多渠道要靠 Webhook 自接或改用 Grafana Alerting 直连）。要提醒一个真实的坑：Uptime Kuma 1.23 → 2.x 升级涉及数据库迁移，大型实例可能超过 2 小时，官方有专门迁移指南——"简单工具"在版本升级时刻的复杂度并不一定低。二者不是替代关系：有社区文章把"Uptime Kuma 管对外拨测 + Prometheus 管指标分析"总结为一种常见的组合用法（社区对比，其判断是二者"在测不同的东西、不同的时间尺度"，互补而非互斥；该说法目前仅此一源，故本报告不称"主流"）。

C 路线（Netdata）——零配置的"即时满足"，与 Prometheus 是两种哲学。 Prometheus 是先定义指标、再采集（pull，白盒）；Netdata 是装上就全采（agent 本地自动发现，秒级粒度），v2.0（2024-11-13）最大亮点是原生 Windows 监控支持（Netdata）。它的告警开箱即用（内置大量健康表告警与异常检测），恰是 Prometheus 栈的最大门槛（必须自己写 PromQL 规则再配 Alertmanager）。许可上 Agent 本体 GPLv3+，但 Netdata Cloud 仪表盘 UI 采用专有许可 NCUL1，云服务 Business 从 $7/节点起——对纯自托管洁癖用户是真实的心理成本。就 2.2 的对比看，本报告的判断是：Netdata 强在"实时本机"，Prometheus 强在"长期保留与规模化"。

D 路线（Zabbix 8.0 LTS）——"一体化企业范"的老对手还在进化。 8.0 LTS（2026 年发布，LTS 支持 5 年）明确向现代可观测性靠拢：基于 OpenTelemetry 的 APM 与 OTLP 采集（Proxy 可直接收 OTLP/gRPC）、新增移动 App 与推送通知媒介、CEP 复杂事件处理（按因果分组做事件关联降噪）、可选 ClickHouse 历史存储（官方 What's New，当日直读；第三方评述）。它的优势场景非常明确：设备类型杂（打印机、交换机、UPS 等靠 SNMP 说话的设备）、需要成熟模板库与权限体系。对个人用户门槛在于概念体系重（主机/监控项/触发器/动作/媒介层层嵌套）。与本课题的对比本质是"一体化 vs 组合式"：组合式每一层都可换可学，长期技能复利高；一体化上手后省心，但被锁在自家体系里。

E1 路线（VictoriaMetrics）——同一生态内的"换引擎"。 VictoriaMetrics 不是竞争对手，而是本课题的直系替身：兼容 Prometheus 数据模型与 PromQL，vmalert 官方目标即"与 Prometheus 告警/记录规则语法完全兼容"（vmalert 文档），LTS 每 6 个月发布一条（LTS 策略）。对个人服务器的现实意义：如果标准栈在你那台小内存机器上跑得紧张（工作口径：小规模实测约 0.5–1GB 内存，1GB VPS 无余量，见 2.2），而你想给机器上的其他服务留出余量，可以整体换成 vmagent + VictoriaMetrics 单机版 + vmalert，Grafana 与告警规则全部原样保留——这是 2026 年自托管社区的常见操作。

E2 路线（Grafana Cloud / Datadog）——要不要花钱买省心。 Grafana Cloud 免费层对个人用户非常友好（1 万活跃序列、50GB 日志、50GB 追踪、3 用户、14 天保留，Pro 从 $19/月起，定价、用量限额）：它运行的就是托管版 Prometheus + Grafana，本地只需跑一个采集器（Alloy）。对"想学本课题但不想配 Prometheus"的人，这是 2026 年最平滑的入门方式。代价是数据出域、免费层 14 天保留太短。Datadog 是商业标杆（Pro 约 $15/主机/月年付、APM 另收，定价、第三方解析），对个人服务的免费额度之外成本结构完全不划算；列在这里主要作为"商业全家桶"的参照系——它验证了监控/告警作为独立产品品类的价值，也反衬出自托管路线对个人用户的意义。

E3 补充观察（InfluxDB 3 + Telegraf；非路线，不计入各对比表）——时序数据库路线的重新入场。 InfluxDB 3 Core 于 2025-01-13 公开 alpha（MIT/Apache 双许可），2025-04-15 GA；2025-11 宣布 InfluxDB 3 Enterprise 对家用免费（InfluxData 博客、GitHub）。它适合"已经在用 Grafana、想要 SQL 查询与更长保留"的进阶玩家，但生态（Flux/SQL 双语言、Telegraf 配置）比 Prometheus 栈概念更杂，不作为入门首选。它的意义在于佐证：时序存储层在 2024–2026 年发生了许可证与商业模式的集体松动，"存指标"这一层已经是买方市场，入门者不应为此焦虑。

2.4 聚焦子问题 A：个人服务应该监控哪些指标

通用答案是经典四个黄金信号：延迟（latency）、流量（traffic）、错误（errors）、饱和度（saturation）（出自 Google SRE 手册，属稳定公开知识，见 sre.google/sre-book/monitoring-distributed-systems/，本次未单独检索验证）。它与 RED/USE 是层级互补而非并列竞争的关系：四个黄金信号是 Google SRE 对"服务该盯什么"的抽象口径，RED 是其在请求驱动服务上的具体化（Rate/Errors/Duration），USE 则补齐资源层（Utilization/Saturation/Errors）——服务层看 RED，资源层看 USE。个人场景再叠加一组"家用特供"项：证书过期、磁盘剩余、内存/交换、容器重启、备份是否成功、心跳（dead man's switch）（其中证书、磁盘、心跳三类的最小规则示例见 3.8）。下表横向对照各路线对这套清单的开箱覆盖能力：

横向结论：指标清单本身与工具无关（先想清楚要盯什么，再选工具）；但"开箱覆盖"与"表达深度"呈反比分布——Uptime Kuma/Netdata/Zabbix 用模板与预设换来开箱即用，Prometheus 用"一切自己定义"换来无限表达力。对入门者，务实的路径是：用 B 路线兜底可用性告警，用 A 路线逐步补齐深度指标，而不是一开始就追求全量表。

2.5 聚焦子问题 B：如何设置告警

告警是各路线差异最大的地方：

三个值得单独说明的判断：

1. Alertmanager 的四个概念（分组/静默/抑制/路由）是全行业告警工作流的"普通话"——学它不是学一个工具，而是学一套可以迁移到 Grafana 告警、vmalert 乃至商业产品的通用心智模型（Alertmanager 文档）。
2. 个人场景的告警要点与企业不同：个人最需要的其实是"心跳告警"（监控本身挂了要知道，即 dead man's switch）与"证书/磁盘这类低频但致命的告警"，而不是复杂的降噪体系。Uptime Kuma 的心跳监控开箱即有；Prometheus 栈则需要额外接 Healthchecks.io 这类外部死开关，或自己写 Watchdog + absent() 规则（最小配置见 3.8）——这是本课题栈在个人场景下最容易被忽略的一课。
3. 2026 年的新变量是"告警即代码"：Grafana 12 把看板、告警、记录规则的 Terraform/CLI 管理转正（Grafana 12 发布文），VictoriaMetrics vmalert 保持与 Prometheus 规则语法完全兼容。这意味着告警配置正在从"网页上点点点"走向"配置文件 + Git"，与 Prometheus 一直以来的"规则文件"哲学合流——本课题学的告警规则写法，恰好站在这次合流的中心。

三、交叉洞察：两轴结合说明了什么

3.1 一条十四年的"门槛下降曲线"，终点是把开放题变成选择题

纵轴的六个阶段串起来看，是一个持续下沉的门槛序列：Borgmon 思想外溢（思想门槛）→ Prometheus 开源并进入 CNCF（获取门槛）→ 2.0 新 TSDB 与 Grafana 2.0 后端化（部署门槛）→ Grafana 8 统一告警（配置门槛）→ Grafana Cloud 免费档与 VictoriaMetrics（金钱与运维门槛）→ Grafana 13 Suggested Dashboards 与 AI 助手（认知门槛）。横轴的 2026 年截面恰好是这条曲线的终点状态：Uptime Kuma 社区实测约 10 分钟部署（ref 25），Grafana Cloud 免费层零运维，Suggested Dashboards 意味着用户甚至不需要先想好"该监控什么"——接上数据源，系统会建议面板与告警。两轴互证的结论是：这条技术线花了十四年，把"监控哪些指标、如何设置告警"从一道需要专家判断的开放题，变成了一道有默认答案的选择题。 这也解释了为什么本课题在今天值得回答又容易回答：答案已经收敛，剩下的是按场景做选择。

3.2 协议层收敛之后，选型的真正分野在告警工作流与商业模式

纵轴阶段六记录了 Prometheus 3.0 转正 OTLP（2024-11）、Alloy 统一采集管线（2024-04）；横轴则观察到 Zabbix 8.0 拥抱 OTLP（2026）、Grafana Cloud/Datadog 天然支持 OTel。两条轴拼在一起得到横轴的宏观结论：2026 年"能不能采到指标"不再是路线差异，真正的分野是三个问题——谁替你运维（自托管 vs 托管）、告警工作流深度（阈值 vs 路由树）、许可证与账单形态（开源 vs 开核 vs SaaS）。这个判断对入门者的含义是：不必再为"选哪个采集器/时序库"焦虑（存指标已是买方市场，InfluxDB 3 开源化、VictoriaMetrics 崛起、Prometheus 3.0 共同佐证），应该把学习预算花在告警工作流上——那是差异真正存在的地方。

3.3 工具门槛在下降，但告警纪律没有贬值——"入门的真实成本不在安装"

横轴洞察指出："入门"的真实成本不在安装（社区实测：Uptime Kuma 约 10 分钟跑通、Prometheus 全栈首次部署 2–4 小时，见 2.2 与 ref 25），而在告警纪律——分组、静默、抑制、心跳、防风暴设计，即 Alertmanager 四件套所代表的方法论。纵轴为这个判断提供了历史注脚：告警体验的两次平民化（Alertmanager 把通知治理做成开箱配置、Grafana 8 把配置入口搬进 UI）降低的都是工具操作门槛，而方法论文从未过时——Grafana 统一告警支持的能力项（分组/静默/抑制/路由）与 Alertmanager 一一对应，vmalert 又与 Prometheus 规则语法完全兼容。两轴结合的结论是：无论 UI 多么友好，"CPU>90% 就发 Telegram"这一档告警在 2026 年依然不够用；反过来说，如果你永远只需要这一档，Uptime Kuma 已是更优解，选型应诚实面对这一点。 学 Alertmanager 四概念，学的是一套可迁移的心智模型，而不是一个特定工具的用法。

3.4 指标清单与工具无关，但"开箱覆盖 ↔ 表达深度"的反比是普遍规律

纵轴显示指标方法论的定型过程（2018–2019：四黄金信号 → RED/USE），横轴则展示了这套清单在五条路线上的开箱覆盖差异。这个反比规律在 2.4 的对照表中已逐行展示，不再重复；此处只补横轴特有的推论：没有任何一条路线同时占据"开箱覆盖"与"表达深度"两端。由此推出个人用户的最优路径不是"选一个全能工具"，而是分层组合——具体分工见 3.7 表的"组合拳"一行。同时要警惕工具给你划定的盲区：Prometheus 栈默认没有心跳告警（见 2.5 的说明与 3.8 的 Watchdog 示例），极简工具则给不了"过去一周 p95 延迟"这类历史分析——清单先于工具，盲区意识源于清单。

3.5 知识资产的可迁移性，是选标准栈的隐性回报

横轴的对比揭示了一个容易被忽略的事实：PromQL 规则、Grafana 看板 JSON、Alertmanager 配置在 VictoriaMetrics、Grafana Cloud 甚至多数兼容产品间可平移；而极简工具的配置（拨测项、模板）迁移时基本要重来。纵轴为这一点提供了完整的时间证据：VictoriaMetrics 用"兼容 PromQL + vmalert 兼容告警规则语法"实现了对 Prometheus 用户的无痛接收，Grafana Cloud 运行的就是托管版 Prometheus + Grafana，Grafana 12 的 observability as code 又把告警配置推向 Terraform/CLI 与 Git 管理。两条轴共同指向一个结论：对以"学习"为目标的入门课题，选事实标准（Prometheus + Grafana）买的不是当下的功能，而是未来十年的选择权——你在标准栈上积累的每一份配置，都可能在下一次"换引擎"或"上云"时原样带走。

3.6 展示层一家独大，解释了课题为什么把两者并列

横轴注意到：除 Uptime Kuma 外几乎每条路线（Netdata Cloud、Zabbix、InfluxDB、VictoriaMetrics、云厂商）都能接 Grafana 或对标它——"选监控后端"与"选看板"已经解耦。纵轴解释了原因：Grafana 从第一天就写着"Democratize metrics"的纲领，2016 年 Grafana 3.0 的插件/面板仓库让社区面板生态滚雪球（版本沿革见 Wikipedia: Grafana 与 Ödegaard UX 史），此后十四年的版本迭代持续加固这个位置（13.3.0 仍在活跃发布）。课题把 Prometheus 与 Grafana 并列讲授，恰好对应了行业里"查询/存储层竞争激烈、展示层高度集中"的真实格局：学 PromQL 是学一门会随存储层更替而迁移的查询技能，学 Grafana 则是学一个几乎横跨所有路线的通用展示层——两者的学习回报结构不同，但都高于学习任何一个封闭一体化产品的专有配置。

3.7 对个人用户的判断与建议

综合两轴，给出按场景的选型建议：

四条可执行的操作建议：

1. 指标清单先于工具：无论选哪条路线，先把这份清单抄下来——服务层四个黄金信号/RED，资源层 USE，家用特供项（证书过期、磁盘剩余、内存/交换、容器重启、备份成败、心跳）。这份清单与工具无关，换任何工具都不用重写。
2. 心跳告警优先于一切降噪设计（论述见 2.5 第二条，最小配置见 3.8）：监控本身挂了却没人知道，是个人场景最常见也最致命的失败模式。Prometheus 栈请第一件事就配 Watchdog + Healthchecks；Uptime Kuma 开箱即有。
3. 告警分两档配置：第一档"低频但致命"（证书、磁盘、备份、心跳）用最简单的阈值即可（阈值起步值见 3.8 的三条示例）；第二档"高频需治理"（服务错误率、延迟）才需要分组/静默/抑制/路由。不要一开始就照搬企业级降噪体系。
4. 从免费托管起步不丢人，而且是正路：Grafana Cloud 免费层运行的就是标准 Prometheus + Grafana，学的每一课（PromQL、告警规则、看板）都能平移到自托管；等数据量或保留期需求超出免费层（14 天保留是主要限制），再迁回自托管或换 VictoriaMetrics，知识资产全程无损。

3.8 最小告警配置示例：证书、磁盘、心跳三条规则起步

这一节正面回答"第一条告警规则到底怎么写"。三条规则对应 2.4"家用特供项"里最致命的三类（证书、磁盘、心跳），基于 Prometheus 原生规则 + Alertmanager；阈值为示例值。诚实说明：本节与 3.9 的配置按官方文档和社区教程的稳定语法编写（参考来源 27–29），未在本会话实际部署验证。

# /etc/prometheus/rules/basics.yml —— 三条起步规则（阈值均为示例值，请按服务调整）
groups:
  - name: home-basics
    rules:
      # 规则 1：证书 14 天内过期。
      # probe_ssl_earliest_cert_expiry 是 blackbox_exporter 导出的
      # "证书链中最早过期证书的 Unix 时间戳"（秒），减去当前时间即剩余秒数。
      # 注意：证书已过期或 TLS 握手失败时该指标可能缺失，需配合 probe_success == 0 兜底。
      - alert: CertExpiringSoon
        expr: probe_ssl_earliest_cert_expiry - time() < 14 * 24 * 3600
        for: 1h
        labels:
          severity: warning
        annotations:
          summary: "{{ $labels.instance }} 证书将在 14 天内过期（剩余 {{ $value | humanizeDuration }}）"

      # 规则 2：磁盘水位——可用空间低于 10% 且持续 30 分钟。
      # 排除 tmpfs/overlay/squashfs 等伪文件系统，避免容器层噪音。
      - alert: DiskAlmostFull
        expr: >
          node_filesystem_avail_bytes{fstype!~"tmpfs|overlay|squashfs"}
          / node_filesystem_size_bytes{fstype!~"tmpfs|overlay|squashfs"}
          < 0.10
        for: 30m
        labels:
          severity: warning
        annotations:
          summary: "{{ $labels.mountpoint }} 可用空间不足 10%（已持续 30 分钟）"

      # 规则 3：心跳（dead man's switch）——一条"永远在触发"的规则。
      # 它的作用不是通知你，而是被外部服务检查"它是否还在触发"：
      # 连它都停了，说明监控链路本身挂了（见 2.5 第二条）。
      - alert: Watchdog
        expr: vector(1)
        labels:
          severity: none
        annotations:
          summary: "始终触发的看门狗：它停止触发即说明监控链路本身故障"

Alertmanager 侧的最小配置——Watchdog 走独立分支发往 Healthchecks.io（死开关服务），其余告警进 Telegram：

# /etc/alertmanager/alertmanager.yml
route:
  receiver: default-telegram
  group_by: [alertname]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
    # Watchdog 分支：Healthchecks 期望周期性 ping，repeat_interval 就是 ping 周期，
    # 需与 Healthchecks 里该 check 的周期设置一致（如 1 小时周期 + 30 分钟宽限）
    - matchers:
        - alertname = "Watchdog"
      receiver: healthchecks-heartbeat
      repeat_interval: 1h

receivers:
  - name: default-telegram
    telegram_configs:
      - bot_token: "<你的 Telegram Bot Token>"
        chat_id: 123456789   # 换成你的 chat id
        send_resolved: true
  - name: healthchecks-heartbeat
    webhook_configs:
      - url: "https://hc-ping.com/<你在 Healthchecks.io 创建的 check 的 UUID>"
        send_resolved: true

不接外部服务时的单点兜底——目标消失（absent）或抓取失败（up==0）任一成立即触发；但它发现不了"Prometheus 自己挂了"，这正是外部死开关不可替代的原因：

up{job="node"} == 0 or absent(up{job="node"})

阈值起步值小结：证书 14 天（给续期留出操作窗口）、磁盘 10%（给清理与扩容留出反应时间）、心跳每 1 小时一 ping（Healthchecks 侧设 1 小时周期 + 30 分钟宽限）。这三个数字是起步默认值，不是真理，按服务的实际节奏调。若走 Grafana Alerting / Grafana Cloud 路线：三条表达式可原样填进 Grafana 告警规则的查询框（Grafana 8+ 支持对 Prometheus 数据源直接建告警，不必自管 Alertmanager，见阶段五与 2.5），Healthchecks 分支改用 Grafana 的 Webhook 通知点指向同一个 ping URL。

3.9 下一步动手清单：读者最可能追问的四个问题

① 第一条告警规则怎么写、阈值定多少？ 抄 3.8 的三条即可：证书 14 天、磁盘 10%、心跳 1 小时。目标不是"配得好"，而是"链路通"——先让自己收到第一条 Telegram 通知，再按 3.7 的两档配置谈治理。

② 标准栈最小部署长什么样？Grafana Cloud 免费层怎么接？ 自托管最小骨架是五个容器的 docker-compose：

# docker-compose.yml —— 标准栈最小骨架（示意：scrape 任务、数据源、健康检查等以官方文档为准）
services:
  prometheus:
    image: prom/prometheus:latest
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml   # 内含 rule_files 指向 3.8 的规则
      - ./rules:/etc/prometheus/rules
      - prom-data:/prometheus
    ports: ["9090:9090"]
  alertmanager:
    image: prom/alertmanager:latest
    volumes:
      - ./alertmanager.yml:/etc/alertmanager/alertmanager.yml
    ports: ["9093:9093"]
  grafana:
    image: grafana/grafana:latest
    ports: ["3000:3000"]
    volumes: ["grafana-data:/var/lib/grafana"]            # 数据源指向 http://prometheus:9090
  node-exporter:
    image: quay.io/prometheus/node-exporter:latest
    pid: host
    volumes: ["/:/host:ro,rslave"]
    command: ["--path.rootfs=/host"]                      # 采集本机资源指标（:9100）
  blackbox-exporter:
    image: prom/blackbox-exporter:latest
    ports: ["9115:9115"]                                  # 证书/URL 拨测（3.8 规则 1 依赖它）
volumes:
  prom-data:
  grafana-data:

prometheus.yml 需定义 node_exporter（:9100）与 blackbox_exporter（:9115）的 scrape 任务并挂上 rule_files，写法照抄官方文档。不想自托管就走 Grafana Cloud 免费层：注册（无需信用卡）→ 控制台按指引装 Alloy 采集器（一个容器，拿到令牌即向云端上报）→ 告警规则在网页 UI 里建（表达式同 3.8）→ 添加 Telegram/邮件通知点；主要限额是 14 天指标保留与 1 万活跃序列（见 1.3）。

③ 1GB 内存的 VPS 能不能跑标准栈？ 能跑，但没有余量：社区实测小规模全栈约 0.5–1GB 内存（ref 25，单一来源；本报告未独立实测），1GB VPS 属于"能跑但紧张"——要收敛保留期、少加组件，并接受偶发 OOM 的风险。务实排序：2GB 左右的 VPS 从容跑全栈；只有 1GB 时二选一——(a) 精简部署（减 exporter、缩短保留期），(b) 按 3.7 用 VictoriaMetrics 替换存储/采集层，更省内存但非必需。

④ 组合拳里，Uptime Kuma 和 Prometheus 的告警怎么去重？ 先说事实：两套系统互相不知道对方存在，Alertmanager 的分组/抑制只作用于它自己收到的告警，管不到 Uptime Kuma——所以去重不靠功能，靠安排：(a) 职责分工（ref 25 的建议）：Uptime Kuma 只管"对外活着吗"（HTTP/端口/证书），Prometheus 只管指标类告警，重叠面天然很小，这正是组合拳成立的前提；(b) 渠道分离：两边发同一个 Telegram 时用不同话题（topic）或标签前缀，或干脆分频道；(c) 统一聚合（进阶，非起步项）：真要一个收口，引入 Grafana OnCall 这类通知层把两边都接进去，再做统一降噪。

参考来源

历史与版本时间线（纵轴部分）

1. Wikipedia: Prometheus (software))——发起时间/团队、CNCF 托管与毕业、版本信息框（全文直读）
2. Wikipedia: Grafana——版本时间线、融资史、Loki/Mimir/Alloy 信息（全文直读）
3. Torkel Ödegaard《The (Mostly) Complete History of Grafana UX》(2019-09-03)——Grafana 设计原则与各版本 UX 演进（全文直读）
4. SoundCloud《Prometheus: Monitoring at SoundCloud》(2015-01-26)——官宣开源（直读超时，要点经 Wikipedia 引注与多路搜索交叉确认）
5. Flagsmith 播客《The Grafana Labs Origin Story》——Grafana 首个 commit 时间
6. Prometheus 官方博客《Changes in Prometheus 2.0》(2018-01-24)——新 TSDB 性能数字
7. GeekWire：Prometheus 从 CNCF 毕业 (2018-08-09)
8. Grafana 官方公告：Grafana/Loki/Tempo 转 AGPLv3 (2021-04-20)
9. Grafana 官方 what's new v8.0：统一告警 (2021-06)
10. Prometheus 官方博客《Prometheus Turns 10》(2022-11-08)——URL 为按官方博客日期格式重建，两次直读失败，事实经交叉印证
11. Prometheus 3.0 发布公告 (2024-11-14)——OTLP 转正、Remote Write 2.0、TSDB CPU/内存效率 macrobenchmark（1.3 引用，当日直读）
12. Grafana 12 发布文 (2025-05-08)——observability as code、告警 Terraform/CLI 管理
13. Grafana 13 发布文 (2026-04-21)——Suggested Dashboards

方法论与官方文档（两章共用）

1. Google SRE 手册：Monitoring Distributed Systems（四个黄金信号）——经典方法论，引用自既有知识，本次未单独检索验证
2. Weave: RED Method for Prometheus、Last9: RED vs USE
3. Alertmanager 官方文档（分组/静默/抑制/路由）
4. Prometheus 官方 exporter 列表、windows_exporter

替代路线与选型（横轴部分，均为 2026-10-31 当日检索）

1. Grafana Cloud 定价、免费档页面、用量限额文档——1 万活跃序列/50GB 日志/50GB 追踪/3 用户/14 天保留，Pro $19/月起
2. VictoriaMetrics LTS 策略、vmalert 兼容性、发布页；资源对比数据：Last9: Prometheus vs VictoriaMetrics（官方基准数字经第三方转引）
3. Netdata 开源许可说明——Agent GPLv3+ / Cloud UI NCUL1 / Business $7 起
4. Zabbix 8.0 官方 What's New（OTLP/APM、CEP 事件关联、ClickHouse 历史存储、移动 App 与推送媒介，当日直读）、第三方评述；官方路线图页仅作发布计划佐证，不用于已发布特性
5. Beszel (henrygd/beszel)
6. Uptime Kuma releases、v2 新特性——2.0 于 2025-10-20 正式发布，1.23→2 迁移注意事项
7. Datadog 定价、第三方解析
8. 2026 年家庭实验室监控栈社区对比——当日直读：上手时间实测（Uptime Kuma 约 10 分钟、Prometheus 全栈 2–4 小时）、内存实测（Uptime Kuma 约 50MB、Prometheus 栈约 0.5–1GB）、成本对比与"按要回答的问题分工"的组合建议（单一社区来源，本报告多处关键口径依赖它）
9. InfluxDB 3 开源计划、GitHub

告警配置示例来源（3.8/3.9 节，2026-10-31 当日检索核实）

1. Prometheus 官方文档：Alerting rules 示例（Watchdog 死开关）、DigitalOcean：How To Set Up a Dead Man's Switch in Prometheus——Watchdog 规则（expr: vector(1)）与 Alertmanager→Healthchecks webhook 配置
2. Digitalis：Monitoring HTTPS Certificate Expiry with Prometheus and Blackbox Exporter——probe_ssl_earliest_cert_expiry 的定义、14 天标准规则写法，及"证书已过期/握手失败时指标可能缺失"的边界
3. Healthchecks.io 文档——死开关 ping 机制（check 周期 + 宽限期，ping 停止即告警）

综合说明（修订记录）

本文由以下两份分章报告综合修订而成，供后续修订参考：

• 纵轴篇：output/reports/parts/2026-10-31-Prometheus与Grafana监控入门-个人服务监控指标与告警-vertical.md
• 横轴篇：output/reports/parts/2026-10-31-Prometheus-Grafana监控入门-个人服务指标与告警-horizontal.md

已消除的重复：Prometheus 3.0/OTLP 合流、Grafana 版本时间线、Grafana Cloud 免费档、VictoriaMetrics 资源对比等两章共有的内容，统一收口到单一出处；RED/USE（纵轴）与四个黄金信号（横轴）合并为"三层口径"的层级关系表述，不再作为并列的竞争性方法论出现。

已统一的口径：① 告警渠道表述——区分 Alertmanager（内置接收器有限）与 Grafana Alerting（渠道矩阵广、可直连 Telegram/Discord），消除纵轴"直连 Telegram/Discord"与横轴"Alertmanager 需 Webhook 自接"之间的表面歧义；② VictoriaMetrics 资源数据——统一采用官方大规模对比基准数字（RSS 16.8GB vs 69GB、磁盘 0.4 vs 4 字节/数据点），标注其经第三方（Last9）转引；③ Grafana Cloud 免费档——统一为"1 万活跃序列、50GB 日志、50GB 追踪、3 用户、14 天保留、Pro $19/月起"；④ 工具门槛与告警纪律的关系——明确"工具门槛下降 ≠ 方法论贬值"，调和纵轴"两次平民化"与横轴"告警纪律是真正溢价"的表述。

验证情况如实说明：SoundCloud 官宣博文与《Prometheus Turns 10》两个页面在检索会话中直读失败（前者连接超时、后者两次网络错误），相关事实改由 Wikipedia 引注与多路搜索交叉印证，后者 URL 为重建；Grafana 2.0 发布日期（2015-08-13）来自检索摘要而非原文直读；四个黄金信号与 USE 方法为经典方法论，按既有知识引用，未单独检索验证；各工具的精确内存占用在综合时未能核实，以定性表述处理，未编造数字——final 修订时补得一份社区实测（ref 25：Uptime Kuma 约 50MB、Prometheus 栈约 0.5–1GB），并全文统一为该口径（见下）。

final 修订补充（2026-10-31，按独立审读意见修订时的验证与诚实声明）：本次修订当日新做的核实——① Prometheus 3.0 官方公告直读，确认其含"TSDB 在 CPU 与内存上的效率改进"表述（1.3 的引用依据，初稿该句无出处）；② Uptime Kuma GitHub README 直读，确认无"5 分钟部署"官方表述，相关三处改为 ref 25 实测口径（约 10 分钟）；③ ref 25（nxsi.io）当日直读，取其实测数字（Uptime Kuma 约 10 分钟/约 50MB、Prometheus 全栈 2–4 小时/约 0.5–1GB 内存），并确认其"组合使用"主张为单一来源——故全文降格为"有社区文章总结的一种常见组合"，不再称"主流终态"；④ Zabbix 8.0 官方 What's New 直读，确认 OTLP/APM、CEP 事件关联、ClickHouse 历史存储与移动端条目，正文来源由路线图改为该页；⑤ blackbox_exporter README 直读未列指标表，probe_ssl_earliest_cert_expiry 的定义、14 天标准规则与边界（证书已过期/握手失败时指标可能缺失）经第三方教程（Digitalis）与检索交叉确认；⑥ Watchdog 死开关模式（expr: vector(1)）与 Alertmanager→Healthchecks webhook 配置见 Prometheus 官方告警示例文档与 DigitalOcean 教程。3.8/3.9 的规则、YAML 与 docker-compose 骨架按上述来源的稳定语法编写，未在本会话实际部署验证，阈值均为示例值；"1GB VPS 能跑但无余量"的判断基于 ref 25 单一样本加定性推断，本报告未做受控实测。