第7章交付后监控部署与交接

对应简历：技能第9条「熟悉 Prometheus + Grafana 监控部署与告警接入，保障交付后可观测」/ 项目一职责「参与 BCS 边缘自治系统与数币智能合约管理平台部署联调……部署 Prometheus + Node Exporter 基础监控」/ 项目二职责「部署 Prometheus + Grafana + kube-state-metrics 监控体系与 Kuboard 可视化管控平台」

实施版定位：监控是交付包的"最后一公里"——装起来、告警通、能交接，客户验收才算闭环。本章压缩为四节：部署交付、告警接入验证、监控交接文档、够用版指标与查询。PromQL 进阶、告警降噪治理、长期存储等深度内容回查运维版第 7 章。术语约定：Kubernetes（以下简称 K8s，正文简写）。

7.1 Prometheus + Grafana 部署交付（混合部署选型）【必背】

标准回答（60–90 秒，"监控怎么搭的"标准答案）: 我的监控部署方案是"独立节点 + 集群内"混合部署，这是按"每个组件放哪最合适"分别决策的结果。Prometheus 和 Grafana 放独立监控节点用二进制部署（apt 安装），两个理由：一是监控不占集群资源，采集和业务负载互不影响；二是故障隔离——集群出问题时监控还活着，"观察者不能和被观察者一起死"，如果 Prometheus 本身在集群里，集群挂了你正需要看数据的时候它也没了。

kube-state-metrics 必须部署在集群内：它的工作就是监听 K8s API、把 Deployment 副本数、Pod 状态这些对象状态转成指标，离开集群无从工作——Deployment 加 NodePort 30080 暴露。Node Exporter 全节点安装：内网仓库没有它的容器镜像，我直接 apt install prometheus-node-exporter，systemd 托管二进制运行、默认 9100 端口，指标输出与容器版完全兼容，Prometheus 侧配置一行不用改——"容器不可得时二进制等价替代"，工具形态服从目标。

采集发现用 static_configs 静态配置：三个 job——node-exporter 各节点 9100、kube-state-metrics 的 30080、apiserver 走 CLB VIP（https 加 insecure_skip_verify，后端增减和故障切换对 Prometheus 来说入口永远是一个 target，配置不用动）。为什么不用 kubernetes_sd_configs 服务发现：六台节点的规模、变更频率低，静态列表一目了然、排障直观；扩到几十上百节点再切——取舍我能讲清楚。银行项目的对应版本是配套级：按 BCS 监控规范部署 Prometheus 2.33.5 加 Node Exporter 1.3.1 到 monitor 命名空间，ARM 镜像走离线导入（复用第 5 章批量脚本），配合平台验收。从"配套部署"到"自选型设计"，这条演进线我在面试里常讲。 实操模板（prometheus.yml 核心结构，移动云真实，IP 占位）：

yaml

global:
  scrape_interval: 15s          # 采集周期：实时性与存储的平衡点
  evaluation_interval: 15s
scrape_configs:
  - job_name: 'node-exporter'        # 全节点主机指标
    static_configs:
    - targets: ['<node1-ip>:9100','<node2-ip>:9100','<node3-ip>:9100']
  - job_name: 'kube-state-metrics'   # 集群对象指标（NodePort 30080）
    static_configs:
    - targets: ['<任一节点-ip>:30080']
  - job_name: 'kubernetes-apiserver' # 控制平面（走 CLB VIP 不感知后端变化）
    scheme: https
    tls_config:
      insecure_skip_verify: true
    static_configs:
    - targets: ['<CLB-VIP>:6443']

追问链：

迭问1：部署完怎么确认"装好了"？ → 答：我的固定动作三个：Web UI 的 Status → Targets 页看各 job 全部 UP——这是部署完成的验收线；Grafana 加 Prometheus 数据源（http://127.0.0.1:9090，同机部署走回环）Save & Test 通过；导 Node Exporter Full（ID 1860）和 K8s 大盘，面板出图并配节点下拉变量（label_values 查询）。Targets 页还有个排障妙用：每个 target 的错误信息（connection refused、timeout、401）直接指向原因，比翻日志快。
迭问2：部署监控自己踩过什么坑？ → 答：三个真实坑都在避坑清单里：Grafana 的 apt 源 GPG 公钥 404 装不上——源配置加 [trusted=yes] 跳过签名校验（内网可控环境的取舍）或下 DEB 包本地装；apt install promtool 报找不到包——promtool 内置在 prometheus 主包里，装主包即可；node-exporter 无容器镜像——apt 二进制等价替代。"部署监控前先解决监控工具自己的供给"是这三个坑的共同教训，我把它写成了部署方案的前置检查项。
迭问3（了解）：Zabbix 为什么不用？ → 答：场景匹配问题：K8s 里 Pod 随时生灭，Zabbix 的静态主机模型跟不上——每天都有新主机出现旧主机消失；Prometheus 的 pull 加服务发现和 kube-state-metrics 生态就是为这种环境设计的。同时我不贬低 Zabbix——传统物理机和网络设备监控它依然合适（课程实验搭过完整架构，理解其 Proxy 分层设计），工具匹配场景，不匹配信仰。
迭问4：node-exporter 为什么可以用 apt 版替代容器版？ → 答：因为 node-exporter 的数据源是主机的 /proc 和 /sys，部署形态不影响它采什么——容器版反而要额外挂载宿主的 /proc、/sys 并配 hostNetwork 才能拿到主机视角；apt 二进制版天然跑在主机上，默认监听 9100，指标名称和输出格式与容器版完全一致，Prometheus 侧配置一行不用改。这是"工具形态服从目标"的实例：内网仓库没镜像时，能等价达成目标的路径就是好路径——交付现场要的是结果，不是形态洁癖。

7.2 告警接入与全链路验证【必背】

标准回答: 告警链路先说清：告警规则在 Prometheus 的 rules 文件里定义、按 evaluation_interval 周期评估，条件满足且过了 for 持续时间，推给 Alertmanager 做降噪和分发——分组（同类告警合并成一条，一个机房断网不该收两百条通知）、抑制（高级别压掉衍生低级别）、静默（维护窗口临时屏蔽）——再路由到邮件、企业微信或钉钉渠道。规则侧我必上的第一批：第一条永远是 up == 0——任何 job 的任何目标失联超过 1 分钟就告警，一条规则覆盖全部目标的存活监控，"监控体系自己先兜住底"；然后是资源类：磁盘满最高优先级（磁盘满是节点级灾难，触发 Pod 驱逐），配 85% 预警；CPU 持续超阈值；再补"慢故障"类——证书剩余天数、etcd 健康，这类不报警但一炸就是大事的项目最容易漏。

for 参数必须会解释：条件需持续满足 N 分钟才真正触发，作用是防抖——CPU 尖峰 10 秒就过去、网络抖一下 up 瞬间为 0，这类毛刺不该半夜叫醒人；窗口 [5m] 平滑曲线加 for 确认，两层过滤后还响的基本是真问题。最重要的动作是全链路演练：上线前故意 systemctl stop 一个 node-exporter，让 up==0 真实触发——观察 Alertmanager 收到、渠道通知送达、恢复后收到 resolved 恢复通知。没有演练过的告警体系等于没配——"告警本身也需要被测试"，这是我在交付验收时坚持的一条：监控验收不只看大盘出图，要看告警真的能把人叫醒。 实操模板（告警规则，部署后第一批）：

yaml

# /etc/prometheus/rules/alert.yml（prometheus.yml 里 rule_files 引用）
groups:
- name: node-alerts
  rules:
  - alert: NodeDown                 # 第一条永远是它：目标失联
    expr: up == 0
    for: 1m
    labels: { severity: critical }
    annotations:
      summary: "节点 {{ $labels.instance }} 采集失联"
  - alert: HighDisk                 # 磁盘满最高优先级
    expr: 100 - node_filesystem_avail_bytes{mountpoint="/"} /
           node_filesystem_size_bytes{mountpoint="/"} * 100 > 85
    for: 5m
    labels: { severity: warning }
    annotations:
      summary: "节点 {{ $labels.instance }} 根分区使用率超 85%"

追问链：

迭问1：scrape_interval 设多少、怎么权衡？ → 答：15 到 60 秒之间选，是实时性和成本的权衡：间隔减半存储翻倍，间隔太长漏短时毛刺、告警响应变慢。我们规模下 15 秒是实测平衡点——存储可控、告警 1 分钟内确认。关键是知道这是权衡并能说出存储估算逻辑（序列数 × 86400/间隔 × 每样本字节数 × 保留天数），不是背一个数。
迭问2：怎么验证告警规则"生效了"？ → 答：三个检查：Web UI 的 Alerts 页看每条规则状态——inactive（正常）、pending（条件满足还在 for 期内）、firing（已触发）；Status → Rules 页确认规则文件加载无误；再加上线前的真实触发演练（停一个 exporter）。"配了"和"生效了"是两回事——交接时我会现场给客户演示一遍 pending 到 firing 到通知送达的全过程，这是监控培训最有说服力的一幕。
迭问3：告警通知到什么渠道、怎么分级？ → 答：链路是 Prometheus rules 评估触发 → Alertmanager 按标签分组路由 → 邮件、企业微信或钉钉 webhook 渠道。分级触达：critical（节点失联、apiserver 不可用、磁盘将满）直达人——电话或强提醒，要求立即响应；warning（CPU 持续超阈值、副本不满、重启上涨）进群通知，工作时间处理；info 只进面板不推送。规则文件和 prometheus.yml 一起纳入文档版本化管理——这条纪律也让交接时"规则从哪来、为什么这么定"有据可答。

7.3 交付后的监控交接（交接文档怎么写）【必背】

标准回答（实施版特色题，与第 15 章呼应）: 监控交付的完整性不在装了多少组件，在客户接手后能不能自己用起来。我的交接包四件：第一件监控交接文档——写四个部分：架构图（谁采谁、数据流向，一页讲清）、访问信息（Grafana 地址、账号权限分级、数据源对应关系）、指标口径表（每块大盘看什么指标、异常长什么样、正常水位线是多少）、变更方法（加一个节点 target 怎么改配置怎么 reload——Prometheus 热加载用 SIGHUP 或 POST /-/reload，不用重启）。第二件告警响应手册——每条告警一页：什么含义、第一步看什么、常见原因清单、升级给谁；以 NodeDown 为例五栏齐全：定义与含义、第一步动作、常见原因（实例停机/安全组误改/节点宕机/网络断）、升级路径、关联预案。值班同学拿到告警不靠猜，这是告警体系真正的"交付物"。

第三件培训与实操——对客户运维做一场带实操的培训：大盘怎么看（总览盘 30 秒回答"有没有事"）、告警怎么响应（按手册走一遍真实告警）、简单变更怎么做（加 target、静默一条告警）；培训完当场让客户自己操作一遍——能独立操作才算知识转移完成。第四件验收记录——把 Targets 全 UP 截图、告警演练的时间线、大盘清单列进验收报告。我在银行项目交接就是这么做的，之后客户自己能处理日常巡检和一般告警，需要我们的频率明显下降——交接做得好，后续支持成本就低，这对交付方是很实际的动力。 追问链：

迭问1：客户问"这监控以后谁维护"，你怎么答？ → 答：分层答：日常维护客户自己来——手册覆盖的加节点、改阈值、静默告警都培训过；升级和架构调整我可以按需支持或写进维保条款；真正的深度排障保留升级通道。这样答的底气来自交接包的完整：维护动作都有 SOP，客户不是"接了个黑盒"。实施岗的职业习惯是"把自己设计成可以被替代的"——交接文档越完整，客户越信任你，反而更愿意续维保。
迭问2：监控指标口径怎么定，客户看不懂怎么办？ → 答：我在指标口径表里给每个指标配三个东西：人话解释（"CPU 使用率=CPU 忙碌比例，85% 以上持续 5 分钟要关注"）、正常水位（基于部署初期观测定的基线，比如 worker 节点 CPU 常态 60% 附近）、异常示例（截图标注什么样该动手）。培训时用"30 秒三问"检验：什么东西坏了、影响多大、要不要升级——值班的人能在 30 秒内回答这三个问题，这块大盘才算交接成功。
迭问3：交接时最容易漏交什么？ → 答：我的经验三个易漏项：一是"变更方法"——加节点 target、改阈值、reload 配置这类日常动作，不写清楚客户第一次扩容就卡住；二是告警响应手册——只交了大盘没交"告警响了怎么办"，监控就只是看的花瓶；三是访问信息的权限分级——Grafana 管理员账号和只读账号要分开交，全交管理员等于埋雷。我的交接四件套（文档、手册、培训、验收记录）就是按"客户接手后能不能自己转起来"倒推设计的——漏哪样转不起来，就交哪样。

7.4 够用版：指标分层与常用 PromQL 自检【理解】

标准回答（够用即可，被深挖回查运维版第 7 章）: 监控指标我按三层铺，这也是交付方案里监控章节的骨架。第一层基础设施：主机存活（up 指标）加 CPU/内存/磁盘/网络（node-exporter）。第二层容器平台：apiserver 可达、etcd 健康、节点 Ready、集群对象状态（kube-state-metrics 的 Pod phase、副本数、重启次数——重启次数突增就是 CrashLoop 的信号）。第三层应用服务：按业务逐个接，属于演进项——我方案里写了规划（黄金指标四件套：延迟、流量、错误、饱和度），"已做的"和"规划中的"分开讲，口径诚实。

必背的三条 PromQL：CPU 使用率 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)——rate 把 Counter 的累积值换算成每秒增长率，avg by (instance) 把所有核归一；内存 (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100——用 MemAvailable 而不是 MemFree（available 含可回收缓存，才是应用真实可用）；磁盘使用率按 mountpoint 过滤再相除。一个关键认知：rate 只能用于 Counter（只增计数器），用在 Gauge 上结果就错了——"用对指标加用对函数"是基本盘，更深的 PromQL（recording rules、predict_linear 预测告警）我理解用法，生产主导用的是这三条基础款。 追问链：

迭问1：node-exporter 和 kube-state-metrics 分工？ → 答：一句话：node-exporter 回答"机器资源用量怎么样"（数据来自 /proc 和 /sys），kube-state-metrics 回答"K8s 对象状态怎么样"（数据来自 watch apiserver——Pod 在什么 phase、Deployment 可用副本差多少、节点 Ready 与否），它不含资源使用率——容器用量是 kubelet 内置 cAdvisor 的职责。三件套拼起来才是 K8s 监控完整拼图，缺了哪块都有盲区，我在方案选型时就是这么排的。

7.5 本章案例

【真实项目】移动云监控体系混合部署（STAR）：背景是生产 K8s 集群上线必须有监控配套，且内网环境镜像和软件源受限。任务是我负责监控方案选型与部署。行动：设计混合部署——独立监控节点（4C8G）二进制部署 Prometheus + Grafana，集群内部署 kube-state-metrics（Deployment 加 NodePort 30080、复用内置 view 只读角色做 RBAC 绑定——roleRef 不可变的坑就是配权限时踩的，删除重建解决），全节点 apt 安装 node-exporter；配置三个抓取 job，Grafana 配数据源导 Node Exporter 和 K8s 大盘；上告警规则（up==0 打底）并做全链路演练。结果：大盘覆盖节点、控制平面、集群对象三层指标，部署过程三个坑（Grafana GPG 404、promtool 无独立包、node-exporter 无镜像）全部解决并写进 9 项避坑清单——监控从选型、部署到踩坑闭环都是我独立完成的。
【真实项目】银行项目基础监控（STAR）：背景是数币平台上线验收要求配套基础监控。任务是部署 Prometheus 加 Node Exporter。行动：按 BCS 监控规范在 monitor 命名空间部署 Prometheus 2.33.5 和 Node Exporter 1.3.1，ARM 环境镜像全部走离线导入（复用批量加载脚本），配置各节点抓取；配合平台上线做监控验收。结果：基础监控随平台通过客户验收——这个项目给我的监控"第一手经验"是 ARM 离线环境部署标准组件的全流程。
【经典故障】Zabbix 历史数据爆库（课程八股案例，讲"监控系统自己也要被容量规划"）：现象是 Zabbix 的 history 表按采集粒度无限堆积，数据盘占满、Web 卡顿。处理：按时间清理历史数据加回收空间；长期方案是配置保留策略、用趋势表替代长期明细。教学点：监控存储不设上限，监控系统就是下一个故障源——我给 Prometheus 配 retention、给容器日志配限额，都是同一条原则的落地。

7.6 章末自测清单（快问快答）

混合部署怎么分工？ → Prometheus/Grafana 独立节点二进制（故障隔离）；kube-state-metrics 集群内；node-exporter 全节点 apt 版。
为什么监控不放集群里？ → 观察者不能和被观察者一起死；且不占集群资源。
三个抓取 job？ → node-exporter 9100、kube-state-metrics 30080、apiserver 走 CLB VIP（https + insecure_skip_verify）。
部署完成的验收线？ → Targets 页全 UP + Grafana 数据源 Save & Test + 大盘出图。
第一条告警规则是什么？ → up == 0 持续 1 分钟——一条规则覆盖全部目标存活。
for 参数干什么用？ → 条件持续满足才触发，防毛刺误报。
告警怎么验证真的会响？ → 全链路演练：停一个 exporter 真实触发，看通知送达和恢复通知。
磁盘告警为什么最高优先级？ → 磁盘满是节点级灾难（Pod 驱逐、组件崩溃连锁）。
监控交接四件套？ → 交接文档（架构/访问/口径/变更）、告警响应手册、带实操的培训、验收记录。
告警响应手册一页五栏？ → 定义含义、第一步动作、常见原因、升级路径、关联预案。
培训完成的标志？ → 客户当场独立操作（看盘、响应告警、加 target）。
CPU 使用率三条公式之一？ → 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)。
内存用哪个指标？ → MemAvailable（含可回收缓存），不是 MemFree。
rate 能用在 Gauge 上吗？ → 不能，只用于 Counter。
node-exporter 与 kube-state-metrics 一句话？ → 前者看机器资源，后者看 K8s 对象状态；容器用量归 cAdvisor。
监控部署三坑？ → Grafana GPG 404、promtool 在主包、node-exporter 无镜像用 apt 替代。

第7章 交付后监控部署与交接 ​

7.1 Prometheus + Grafana 部署交付（混合部署选型） 【必背】 ​

7.2 告警接入与全链路验证 【必背】 ​

7.3 交付后的监控交接（交接文档怎么写） 【必背】 ​

7.4 够用版：指标分层与常用 PromQL 自检 【理解】 ​

7.5 本章案例 ​