运维监控软件手册

按「监控软件 / 平台」拆分的详细手册：一个软件一篇，共 25 篇，分 7 类，约 1.1 万行。 每篇都是完整的「介绍 + 使用方法 + 配置说明 + 实战 + 排障 + 速查」，不是命令清单。 与 《运维工具手册》 互补：那边按命令行小工具讲"这台机器现在卡在哪"，这边按平台讲"怎么把整个环境长期监控起来、告警怎么发、数据留多久"。

怎么用

每篇统一结构：它解决什么问题 → 核心概念与架构 → 安装与部署 → 配置文件详解 → 核心使用方法 → 告警与通知 → 实战场景 → 日常运维与故障排查 → 性能容量与高可用 → 安全加固备份升级 → 常见坑 → 速查表 → 选型建议与同类对比 → 参考链接。

监控体系分层

任何一套监控，本质都是下面这条链路。本手册的分类就是按链路上的位置切的：

  ┌── 采集层 ──────────┐  ┌── 存储层 ──────────┐  ┌── 查询/可视化 ──┐  ┌── 告警与触达 ──┐
  │ Node Exporter      │  │ Prometheus TSDB    │  │ PromQL / LogQL  │  │ Alertmanager   │
  │ Categraf / Telegraf│  │ VictoriaMetrics    │  │ KQL / Flux      │  │ Grafana Alert  │
  │ Zabbix Agent       │─▶│ Thanos + 对象存储  │─▶│ Grafana / Kibana│─▶│ 各平台规则引擎 │─▶ 企微/钉钉/邮件
  │ Filebeat / Alloy   │  │ Elasticsearch      │  │ 状态页 / 大盘   │  │ 静默 / 升级    │    / On-call
  │ cAdvisor / 探针    │  │ Loki / InfluxDB    │  │                 │  │                │
  └────────────────────┘  └────────────────────┘  └─────────────────┘  └────────────────┘
        01 / 03 / 04 / 05 / 06 分类            01 / 04 分类              02 分类         01 / 02 / 03 分类

关键认知：组件分工，没有银弹。Prometheus 只评估告警不发送通知，不渲染大盘；Grafana 不存指标；Kibana 不采日志；Loki 不索引日志全文。把它们按链路拼起来，才是"一套监控"。

分类索引

01 指标采集与时序存储（6 篇）

02 可视化与告警呈现（3 篇）

03 一体化监控平台（6 篇）

04 日志监控与分析（4 篇）

05 APM 与链路追踪（2 篇）

06 容器与云原生监控（2 篇）

07 商业与云监控（2 篇）

典型组合方案

方案 A：最小可用监控（10~50 台，1 人维护）

Node Exporter(每台) ──pull──► Prometheus ──► Alertmanager ──► 企业微信/钉钉/邮件
                                 │
                                 └──► Grafana（大盘 + 统一告警）
外部可用性：Uptime Kuma（独立部署，别和被监控对象放同一机房）

部署顺序：Node Exporter → Prometheus（先配 static_configs）→ Grafana 导入 Node Exporter 大盘 → Alertmanager → 告警规则（先只配「主机 down / 磁盘 >85% / 内存 >90%」三条）→ Uptime Kuma。 关键端口：9100 / 9090 / 3000 / 9093 / 3001。 取舍：Prometheus 本地盘默认保留 15 天；要长期留存再叠 VictoriaMetrics 或 Thanos，别一上来就上分布式。

方案 B：Kubernetes 多集群（云原生团队）

kube-prometheus-stack（Operator + Prometheus + Alertmanager + Grafana + node-exporter + kube-state-metrics）
        │ remote_write                          │
        ▼                                      ▼
VictoriaMetrics 或 Thanos(对象存储)      Loki + Alloy/Promtail(日志)
        │                                      │
        └──────────────► Grafana 统一数据源 ◄───┘
告警：PrometheusRule / Loki Ruler → Alertmanager → 按 namespace 路由到业务团队

部署顺序：Helm 装 kube-prometheus-stack → 用 ServiceMonitor 接入一个业务 → 验证 CRD 被 Operator 选中 → 再接长期存储 → 最后接日志与告警分流。 要点：ServiceMonitor 不生效是本方案最高频故障，排查链见该篇第 8 章；标签基数（cardinality）必须在接入业务前定规范。

方案 C：传统机房 / 信创内网

Zabbix 或 夜莺 Nightingale（采集 + 告警 + Web 一体）
   ├── Zabbix Agent / Categraf  →  主机与进程
   ├── SNMP + Cacti             →  交换机端口流量、专线带宽
   └── Netdata                 →  单机秒级应急排障（临时启用，不长期留存）
告警 → 企业微信 / 短信 / 值班表；跨地域用 Zabbix Proxy 或夜莺边缘节点

要点：内网无外网时优先选可离线安装的发行版包/二进制；信创 CPU 与国产 OS 需实测镜像与依赖，各篇「常见坑」有说明；夜莺各版本架构变化大，先锁版本再写配置。

方案 D：日志 + APM 全栈（微服务）

应用日志 → Filebeat / Alloy → (Logstash 可选) → Elasticsearch → Kibana     【全文检索重】
应用日志 → Alloy / Promtail → Loki             → Grafana                  【成本敏感】
Java/Go 服务 → SkyWalking Agent 或 OTel SDK → OAP / Jaeger Collector → UI  【链路与性能】
三套数据用 trace_id 关联，Grafana 里从指标下钻到日志再到链路

要点：ELK 与 PLG 二选一即可，不要两套都上；统一 service.name / trace_id / 日志时间时区是关联的前提。

方案 E：云上 / 混合

云厂商监控（云产品指标 + 平台事件 + 账单告警） ─┐
自建 Prometheus（应用与业务指标）              ├─► 统一 On-call / 告警收敛
Datadog 或托管 Prometheus（跨云聚合，可选）    ─┘

要点：云监控拿不到应用内部指标，自建栈拿不到 RDS/SLB 平台侧指标，两者是互补不是替代；告警务必收敛到一个入口，否则值班会被三套通知淹没。

需求 → 工具决策表

核心工具横向对比

指标与时序栈

一体化监控平台

日志与 APM

Graylog、Fluent Bit、Vector、Tempo、Zipkin、Pinpoint 暂未单独成篇，见扩展计划。

默认端口与路径速查

均为默认端口，可被配置覆盖；同一组件不同版本可能有差异，以各篇第 3、12 章为准。

通用约定与版本差异

• $ 普通用户，# root 或 sudo，<xxx> 为占位符；⚠️ 标注危险操作，生产执行前先备份或 --dry-run。
• 命令默认 Linux（glibc + systemd）；Alpine、国产 OS、信创 CPU 的差异在各篇「常见坑」里单独说明。
• 文中不绑定固定版本号与镜像 tag，一律写"以官方最新稳定版为准"。安装前到官方下载页/仓库确认当前版本，跨大版本升级先看官方迁移说明。
• 需要特别注意的版本差异（各篇已展开）：
  • Elasticsearch 8.x 起默认开启安全特性，首次启动要处理证书与内置用户密码；
  • Grafana 使用 Unified Alerting，与旧版 Dashboard Alerting 配置方式不同；
  • Loki 生态推荐用 Grafana Alloy 替代 Promtail，旧采集端有 EOL 时间点；
  • Jaeger v2 基于 OpenTelemetry Collector，与 v1 组件模型不同；
  • 夜莺 v5 / v6 / v9 架构与依赖变化较大，先锁版本再写配置；
  • Kubernetes 中 cAdvisor 已内置于 kubelet，独立部署前先确认端口与指标路径；
  • Zabbix 7.0 LTS、Checkmk Raw 与商业版、Nagios 与 Icinga 的功能边界均以官方文档为准。
• 所有规则与大盘纳入 Git：Prometheus rules、Grafana provisioning、Alertmanager 路由、Helm values 都应配置即代码，禁止只在 Web 上点。
• 监控系统自身必须被监控（meta-monitoring）：Prometheus 抓取失败、Alertmanager 静默过期、磁盘剩余、采集延迟都要有独立告警通道，否则监控挂了没人知道。

监控上线检查清单

1. 全链路 NTP/chrony 时钟同步已验证（指标被判未来时间会直接丢弃）。
2. 保留期 × 采样频率 × 序列数算出磁盘需求，并预留 compaction/合并所需的额外空间。
3. 标签规范已定稿，明确禁止把 user_id、request_id、trace_id 之类高基数字段做标签。
4. 指标名、job、instance、service 命名统一，跨团队大盘口径一致（用 recording rule 固化）。
5. 告警分级（P0~P3）与值班表、升级路径已确认；P0 走电话/短信，P3 只进群。
6. 通知渠道已实测：企业微信/钉钉/Webhook 发一条测试告警，别等故障才发现 token 过期。
7. 静默、抑制、分组、重复通知间隔已配置，能扛住一次机房级故障引发的告警风暴。
8. 大盘有「全局概览 → 服务 → 单机」三层下钻路径，而不只是一堆曲线。
9. 配置、大盘 JSON、告警规则、数据库已备份，并演练过一次恢复。
10. 认证鉴权、TLS、最小权限、网络暴露面收敛完成；监控端口不对公网开放。
11. 监控系统自身有独立告警通道（最好跨机房/跨云），避免"监控挂了无人知"。
12. 做过一次告警演练（主动停一台非关键服务），验证从采集到通知全链路耗时。
13. 容量与成本有上限：日志采样率、指标抓取间隔、对象存储生命周期策略都已设定。
14. 文档沉淀：部署架构图、端口表、值班 SOP、常见故障处置，随配置一起进仓库。

与现有手册的关系

扩展计划

后续可按需增补，仍按「一个软件一篇、14 章结构」补齐：

• 采集与传输：Grafana Alloy、Fluent Bit、Vector、OpenTelemetry Collector、Blackbox Exporter、SNMP Exporter、windows_exporter、Pushgateway、statsd_exporter。
• 存储与查询：Grafana Mimir、Cortex、Tempo、ClickHouse（日志/Trace 存储）、TimescaleDB。
• 日志：Graylog、Fluentd、OpenSearch、Loki Ruler 深入实践。
• APM / 链路：Zipkin、Pinpoint、Pyroscope（持续性能剖析）、eBPF 可观测（Cilium Hubble、Pixie）。
• 网络与拨测：Smokeping、Blackbox Exporter 进阶、BGP/专线监控。
• 告警与 On-call：Grafana OnCall、PagerDuty、告警降噪与 SLO / Error Budget 实践。
• 平台与生态：Open-Falcon、蓝鲸智云、Wazuh（安全监控）、Prometheus 联邦与多租户治理、监控数据合规与信创适配。

本手册是通用参考，与具体环境强相关的部分（端口规范、保留期、通知渠道、备份路径、账号权限、值班分级）请替换为团队实际值，沉淀为内部 SOP 后再上生产。