第7章 监控 Prometheus 与可观测性

对应简历：技能第6条「熟练掌握 Prometheus + Grafana + kube-state-metrics 监控告警与可观测体系、Kuboard 可视化运维平台」/ 项目二职责「搭建监控体系：独立节点二进制部署 Prometheus + Grafana，集群内部署 kube-state-metrics，全节点安装 Node Exporter，实现节点、控制平面与集群对象指标采集与可视化大盘」/ 项目一职责「部署 Prometheus + Node Exporter 实现基础监控，配合完成平台上线与客户验收」

术语约定：Kubernetes（以下简称 K8s，仅正文简写）。

7.1 Prometheus 架构与六大组件 【必背】

标准回答（60–90 秒口径）： Prometheus 是 CNCF 的开源监控系统，内置时序数据库 TSDB，三个核心特征：pull 拉取模型、带标签的多维数据模型、PromQL 查询语言。架构六大组件我顺着数据流讲：第一 Prometheus Server 是核心——按 scrape_configs 周期抓取各目标的 /metrics 接口、把数据存进本地 TSDB、并周期性评估规则文件；第二 Exporter 是采集端——把系统或中间件的状态转成 Prometheus 格式暴露出来，node_exporter 采主机、kube-state-metrics 采 K8s 对象、mysqld_exporter 采数据库，各种中间件基本都有现成的；第三 Pushgateway 是短任务中转站——跑完就退出的批处理任务先 push 过来暂存，Server 再统一拉；第四 Alertmanager 负责告警的降噪和分发——接收 Server 推来的告警，做分组、抑制、静默后路由到通知渠道；第五 Web UI 是自带的查询界面（9090 端口），能执行 PromQL、看 Targets 状态；第六 Rules 规则文件分两种——记录规则预计算常用表达式、告警规则定义触发条件。

数据流一句话串起来：Exporter 暴露指标 → Server 拉取存储 → 规则评估 → 告警发 Alertmanager → 渠道通知；可视化交给 Grafana 做。 追问链：

• 追问1：为什么用 pull 不用 push？ → 答：pull 把控制权完全放在采集端，带来四个好处：目标列表集中管理、抓取频率统一可控；目标挂了 Server 天然感知——up 指标变 0 就是现成的存活告警，不用额外心跳机制；避免大量 Agent 向 Server 打流量的回压问题；配合服务发现能自动适应动态环境。短生命周期的任务拉不到，才用 Pushgateway 补充。对比我了解的传统 push 体系（Zabbix Agent 上报）在云原生动态环境里"主机注册跟不上 Pod 生灭"的痛点，pull 加服务发现是更匹配的设计。
• 追问2（深挖）：Prometheus 自己挂了谁监控它？ → 答：分层答。我们小规模环境是单节点部署：靠 systemd Restart=always 自动拉起，加上节点级的存活告警兜底；同时 Server 会采集自身指标（self-monitor），up 指标覆盖所有目标。更大规模要做高可用：双副本各自独立采集（简单粗暴但有效），长期存储和全局查询上 Thanos 或 VictoriaMetrics，联邦集群做层级聚合。这块我理解到方案选型层面，生产没有实际搭过 Thanos——如实说，并把我们的规模和对应方案讲清楚，展示的是"按规模选架构"而不是装懂。

关联话术："我两个项目都是 Prometheus 体系，但形态不同：银行项目是 BCS 区块链平台配套的 Prometheus 2.33.5 加 Node Exporter 1.3.1 做基础监控，部署在 monitor 命名空间，配合平台上线验收；移动云项目是我自己设计的混合部署——独立监控节点二进制跑 Prometheus 和 Grafana（不占集群资源、故障隔离），集群内跑 kube-state-metrics，全节点装 Node Exporter。从'配套部署'到'自选型设计'，这条演进线我在面试里常讲。"

7.2 pull 模型与 scrape_configs 抓取配置 【必背】

标准回答： 抓取目标在 prometheus.yml 的 scrape_configs 段声明，结构按层讲：每个 job_name 是一组同类目标的逻辑分组；scrape_interval 定义采集周期（我们 15 秒）；static_configs.targets 列出目标地址（host:port，默认路径 /metrics）；https 目标配 tls_config（自签环境用 insecure_skip_verify）；需要认证的用 bearer_token_file 挂 token。

配置改完 systemctl restart prometheus 重载，验证的固定动作是到 Web UI 的 Status → Targets 页看各 job 的 UP 状态——这是部署完成后我必做的检查，所有 target 显示 UP 才算完成。

出问题时 Targets 页的错误信息（connection refused、timeout、HTTP 401）直接指向原因，比看日志更快。

我在移动云项目手写了全部抓取配置：node-exporter、kube-state-metrics、apiserver 三个 job（模板见下）。 追问链：

• 追问1：scrape_interval 设多少合适？ → 答：15 到 60 秒之间选，是个实时性和成本的权衡：间隔减半存储也翻倍，还要考虑网络开销；间隔太长又会漏掉短时毛刺、告警响应变慢。我们 6 个节点加 15 秒是实测平衡点——存储可控、告警在 1 分钟内能确认；通用经验是 15 秒或 30 秒二选一。关键不是数字本身，是"知道这是权衡、能说出理由"——被追问时我把存储量估算逻辑也讲出来。
• 迭问2：怎么发现某个目标抓不到了？ → 答：两层机制：被动层——Prometheus 内置 up 指标，每个抓取目标对应一条 up{job=..., instance=...} 序列，抓取失败 up 变 0；主动层——配一条 up == 0 for 1m 的告警规则，任何 job 的任何目标失联超过 1 分钟就告警，一条规则覆盖全部目标的存活监控，性价比极高。这是我们告警规则的第一条，部署完先上它——"监控体系自己先兜住底"。 关联话术："移动云项目里 apiserver 的抓取走的是 CLB 的 VIP 地址（https 加 insecure_skip_verify）——这样设计的妙处是：后端 master 增减、故障切换、健康检查摘除，对 Prometheus 来说入口永远是那一个 target，配置完全不用动。'采静态入口、不追动态后端'是我从这次设计里提炼的原则。"

实操模板（prometheus.yml，移动云项目真实结构，IP 用占位符替换）：

global:
  scrape_interval: 15s          # 采集周期
  evaluation_interval: 15s      # 规则评估周期

scrape_configs:
  # 1. 全节点 node_exporter（主机指标）
  - job_name: 'node-exporter'
    static_configs:
    - targets:
      - '<master01-ip>:9100'
      - '<master02-ip>:9100'
      - '<master03-ip>:9100'
      - '<worker01-ip>:9100'
      - '<worker02-ip>:9100'
      - '<worker03-ip>:9100'

  # 2. 集群对象指标（集群内 Deployment + NodePort 30080 暴露）
  - job_name: 'kube-state-metrics'
    static_configs:
    - targets: ['<任一节点-ip>:30080']

  # 3. 控制平面 apiserver（走 CLB VIP，不感知后端变化）
  - job_name: 'kubernetes-apiserver'
    scheme: https
    tls_config:
      insecure_skip_verify: true
    static_configs:
    - targets: ['<CLB-VIP>:6443']

7.3 数据模型：指标、标签与时间序列 【理解】

标准回答： Prometheus 的数据模型一句话：每条监控数据 = 指标名 + 一组标签 + 时间戳 + 浮点值。指标名加一组唯一标签组合就构成一条时间序列（time series），例如 node_cpu_seconds_total{instance="x", mode="idle", cpu="0"}——同一个指标名，按 instance、mode、cpu 的不同取值展开成大量独立序列。

标签天然多维的价值在于查询时可以按任意维度聚合和切片：按 instance 求每台机器的均值、按 mode 过滤出 idle、按 job 分组统计——传统监控里要预先定义好"监控项"的僵化模型，在多维标签体系里变成查询时自由组合。这也是 PromQL 表达力强的根基。要配套理解的约束是高基数问题：标签的每个取值都会展开一条新序列，取值无界的标签（user_id、URL 全量）会让序列数爆炸。 追问链：

• 迭问1：什么是高基数（high cardinality）问题？ → 答：标签取值无界时序列数按取值数量线性膨胀——把 user_id 打上标签，10 万用户就是 10 万条序列，TSDB 内存和存储暴涨甚至 OOM，查询也变慢。规避原则两条：标签只用有限取值的维度（节点名、job、状态码大类）；无界信息（具体 URL、用户、traceID）放日志和链路系统，不放指标。设计指标时先问"这个标签的可能取值有多少"——这个检查习惯我在评审监控方案时会主动提。

7.4 四大指标类型 【必背】

标准回答： Prometheus 指标四种类型，按使用频率讲。Counter 计数器：只增不减的累积值——http_requests_total、node_cpu_seconds_total 都是，重启归零是允许的（rate 函数会处理）。关键点：Counter 的原始值几乎没意义（开机以来累计多少秒 CPU 没法直接用），必须配 rate() 求每秒增长率才有意义——这是新手最常犯的错。

Gauge 仪表盘：可增可减的当前值——内存可用量、队列长度、温度，直接读、直接算百分比。Histogram 直方图：把观测值按预设的 bucket 分桶采样（比如请求延迟 <0.1s、<0.5s、<1s 各多少个），服务端可以基于桶数据计算 p95/p99 分位数，而且多实例的桶可以聚合后再算——跨实例聚合是它的核心优势。

Summary 摘要：在客户端预先算好分位数直接上报，查询端省计算，但不同实例的分位数不能合并聚合。选型结论：需要聚合算全局分位数必须 Histogram，单实例且想省服务端计算用 Summary，生产通用建议 Histogram。 追问链：

• 迭问1：CPU 使用率为什么不能直接读一个值？ → 答：因为 node_cpu_seconds_total 是 Counter——它记录的是"开机以来该核在 idle 模式累积消耗的 CPU 秒数"，一个单调递增的大数字，直接读毫无意义。必须 rate(node_cpu_seconds_total{mode="idle"}[5m]) 求最近 5 分钟每秒的增长率——增长率就是"这一秒里 idle 占的比例"，再用 1 减它得到使用率。理解"Counter 要 rate"这一条，能避掉一大类看错指标的事故。
• 迭问2：Histogram 和 Summary 怎么选？ → 答：判断标准只有一个——要不要聚合。多个实例（Pod 副本、多节点）的延迟数据要合并算整体 p95 时，Histogram 的桶是可以跨实例相加再算分位数的，Summary 的分位数在客户端算死了没法合并。所以微服务多副本场景一律 Histogram；单实例监控、想减轻服务端计算压力时 Summary 也可以。我们环境的应用指标层还在演进，我的建议口径是"新接的应用指标统一 Histogram"——为将来的聚合留能力。

7.5 PromQL 基础与 CPU 使用率计算 【必背】

标准回答： PromQL 必背三函数一语法：rate() 求时间窗口内 Counter 的每秒平均增长率（只用于 Counter，窗口如 [5m]）；sum()/avg()/max() 聚合函数，配 by (标签) 分组；[5m] 时间范围选择器。CPU 使用率的核心逻辑一句话：使用率 = 1 − 空闲占比。

标准表达式我能默写：100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)——逐层拆解：rate 算出每核每秒的 idle 增长占比（0 到 1 之间），avg by (instance) 把同一节点所有核求平均（所以不用手动除以核数，平均已经把核数归一），1 减得到使用率再乘 100。

这个表达式在 Grafana 大盘和告警规则里反复出现，是 node 层监控的基石查询。配套常用表达式还有内存和磁盘使用率（Gauge 类型直接相除，见追问）。 实操模板（必背三条）：

100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)   # CPU
(1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100           # 内存
100 - node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"} * 100  # 磁盘

追问链：

• 迭问1：内存使用率怎么写？ → 答：(1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100。要点两个：用 MemAvailable 而不是 MemFree——available 包含可回收的 buff/cache，才是应用真实可用的量（呼应第 1 章 free -h 看 available 的原则）；Gauge 类型直接相除，不需要也不能 rate——rate 只用于 Counter，用在 Gauge 上结果错误。这两个点都是"用对指标 + 用对函数"的基本功。
• 迭问2：磁盘使用率？ → 答：100 - node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"} * 100。注意必须用 mountpoint 标签过滤——不加过滤会把所有挂载点、包括 overlay 和临时文件系统都算进来，大盘会多出一堆无意义曲线。实际生产我会对关键挂载点（根分区、数据盘）分别建查询或配告警，阈值一般是 85% warning、95% critical——磁盘满是节点级灾难（Pod 驱逐），这条告警优先级很高。
• 迭问3（深挖）：[5m] 窗口有什么讲究？ → 答：两个约束：第一 rate 至少需要窗口内两个采样点，窗口必须大于等于 2 倍抓取周期——15 秒抓取配 5 分钟窗口有 20 个点，绰绰有余；配 30 秒抓取的 1 分钟窗口就只剩 2 个点，勉强及格。第二窗口长短是灵敏度和稳定度的权衡：窗口越长曲线越平滑、毛刺越少，但对突发的响应越慢。5m 配 15s 抓取是常规搭配，告警场景再配 for 持续时间做二次防抖。

7.6 服务发现：static_configs 与 kubernetes_sd_configs 【必背】

标准回答： 目标发现两种方式。static_configs 静态配置：目标列表直接写在配置文件里——直观、可控、排错简单，改配置重载即生效，适合节点规模小、拓扑固定的环境。kubernetes_sd_configs 动态发现：Prometheus 直接调 K8s apiserver，按 role（node、pod、service、endpoints）自动发现目标，配 relabel_configs 做过滤和标签改写——节点动态扩缩、Pod 随时生灭的环境必须用它，否则 target 列表永远追不上现实。

我的真实取舍（面试亮点，整段讲）：移动云项目我选了 static_configs，理由三条：一是全集群只有 6 个采集节点加 1 个 kube-state-metrics，目标数个位数，静态列表维护成本最低；二是节点扩容是低频事件，加一行 target 十秒钟，不值得为它引入服务发现的认证和 relabel 复杂度；三是 apiserver 走 CLB VIP 采集，天然只有一个目标。

等规模到几十上百节点、或者上了自动扩缩容，再切 kubernetes_sd_configs 加 relabel——什么时候该换、为什么现在不换，我能讲清楚。 追问链：

• 迭问1：kubernetes_sd 需要什么权限？ → 答：要给 Prometheus 一个专用的 ServiceAccount，通过 RBAC 授权它 list/watch 相应资源（node、pod、endpoints 等——取决于用哪些 role），然后把 SA 的 token 挂给 Prometheus 做认证。权限上遵循最小化：只读的 get/list/watch，不给写权限。这套配置和我给 kube-state-metrics 配 view 只读角色是同一套思路——监控组件一律只读权限，是我们 RBAC 规范的一部分。
• 迭问2：集群外的 Prometheus 怎么采到集群内指标？ → 答：我们的实际做法两条路并行：kube-state-metrics 用 NodePort 30080 暴露，监控节点直连任一节点的 30080 采集；node-exporter 本来就跑在主机网络 9100 端口，监控节点直接逐台连。另一条路是走 apiserver 的 proxy 接口访问集群内 Service——需要认证配置但不用开 NodePort，适合安全要求更高的场景。我们选 NodePort 是因为内网可控且配置最简单——两种路的取舍我都能讲。

7.7 node_exporter 指标要点 【理解】

标准回答： node_exporter 采集主机层指标，核心指标族按资源分类记：CPU——node_cpu_seconds_total 按 mode 标签分 idle/user/system/iowait，是 CPU 使用率计算的原料；内存——node_memory_MemTotal_bytes 和 MemAvailable_bytes；磁盘空间——node_filesystem_avail_bytes 和 size_bytes（按 mountpoint 标签区分挂载点）；磁盘 IO——node_disk_reads/writes_completed_total；网络——node_network_receive/transmit_bytes_total；还有负载 node_load1/5/15 和 uptime。

部署方式两种：容器化用 DaemonSet 跑（注意必须挂载宿主 /proc 和 /sys 只读、配 hostNetwork，否则采到的是容器自己的指标）；systemd 二进制跑（服务托管、资源独立）。

移动云项目内网仓库没有它的容器镜像，我改用全节点 apt install prometheus-node-exporter——systemd 托管、默认 9100 端口、指标输出与容器版完全兼容，Prometheus 侧配置一行不用改——"容器不可得时二进制等价替代"的实例。 追问链：

• 迭问1：容器版 node_exporter 要注意什么？ → 答：三个必须：挂载宿主机的 /proc 和 /sys（只读），因为 node_exporter 的数据源是这两个伪文件系统，不挂载采到的就是容器命名空间里的假数据；配 hostNetwork 让它看到主机网络栈（网络指标才有意义）；一般还配 hostPID。一句话总结：node_exporter 要的是"宿主机的视角"，容器化部署必须把这些宿主资源显式共享给它——这就是为什么很多监控 Agent 宁可用 DaemonSet 加一堆 host 配置。
• 迭问2：free 和 available 看哪个？ → 答：available。free 是完全未使用的内存，available = free + 可回收的 buff/cache——内核会在需要时自动释放缓存，所以"应用还能用多少"由 available 回答。Linux 侧 free -h 看 available 列、Prometheus 侧用 node_memory_MemAvailable_bytes，两边是同一个道理——我的监控指标和命令行习惯是一致的，这套一致性讲出来很顺。

7.8 kube-state-metrics 与 node_exporter 的区别 【必背】

标准回答（一句话口径 + 展开）： 一句话分工：node_exporter 回答"机器资源用量怎么样"，kube-state-metrics 回答"K8s 对象状态怎么样"，cAdvisor 回答"容器用量怎么样"。展开：node_exporter 的数据来自主机的 /proc、/sys——CPU、内存、磁盘、网络这些 OS 层指标；kube-state-metrics 的数据来自 watch apiserver——它把 Pod 处于什么 phase、Deployment 期望副本和可用副本差多少、节点 Ready 与否、容器重启次数这些"对象状态"转成指标，注意它不含任何资源使用率——资源用量是 cAdvisor/metrics-server 的职责。

三者的典型指标要能各举两个：node 的 cpu_seconds_total、filesystem_avail；kube-state 的 kube_pod_status_phase、kube_pod_container_restarts_total（重启次数告警）、kube_deployment_status_replicas_available 对比 spec_replicas（副本不满告警）、kube_node_status_condition（节点 Ready）。这三件套拼起来才是 K8s 监控的完整拼图——缺了哪块都有盲区。 追问链：

• 迭问1：Pod 的 CPU 使用率从哪来？ → 答：来自 kubelet 内置的 cAdvisor——kubelet 在 10250 暴露 /metrics/cadvisor，提供每个容器的 CPU/内存用量；kubectl top 和 HPA 用的 metrics-server 也是从 kubelet 的 API 汇总数据。我们大盘上容器用量这层当时主要靠 kubectl top 和 Kuboard 的资源视图，cAdvisor 指标接入 Prometheus 属于我方案里的演进项——如实讲现状和规划，比说"全都做了"可信。
• 迭问2：kube-state-metrics 的典型指标？ → 答：我背四个常用的：kube_pod_status_phase（Pod 处于 Pending/Running/Failed 哪个阶段，配告警抓 Pod 异常堆积）；kube_pod_container_restarts_total（重启次数，突增说明 CrashLoop）；kube_deployment_status_replicas_available 对比 kube_deployment_spec_replicas（可用副本少于期望，扩容失败或 Pod 起不来）；kube_node_status_condition（节点 Ready/NotReady）。这四个覆盖了"对象异常"的主要告警场景，是我们监控规则里 K8s 层的主力。
• 迭问3：你部署它时踩过什么坑？ → 答：真实坑（避坑清单第 4 条）：给它配权限时，apply 修改 ClusterRoleBinding 报"字段不可更新"——roleRef 是不可变字段。解法是 kubectl delete clusterrolebinding xxx --ignore-not-found 删除重建，并且直接复用系统内置的 view 只读 ClusterRole 绑定——只读权限恰好覆盖它 watch 的需要，天然满足最小权限。这个坑让我记住了两类 K8s 不可变字段的存在意义（还有 Service 的 clusterIP、PV 的存储类）。

实操模板（部署与权限绑定，真实命令）：

kubectl create ns monitoring
kubectl create serviceaccount kube-state-metrics -n monitoring
# roleRef 不可变：先删旧绑定再建，复用内置只读角色
kubectl delete clusterrolebinding kube-state-metrics --ignore-not-found
kubectl create clusterrolebinding kube-state-metrics \
  --clusterrole=view \
  --serviceaccount=monitoring:kube-state-metrics
# Deployment 用内网仓库镜像，Service 用 NodePort 30080 暴露
kubectl get pods -n monitoring -w

7.9 Alertmanager：分组、抑制、静默与告警渠道 【必背】

标准回答： 告警链路先说清：Prometheus 的告警规则周期评估（evaluation_interval），条件满足且过了 for 持续时间，把告警推给 Alertmanager——Server 只管"发现"，Alertmanager 管"降噪和分发"，它的三大机制：分组 group_by——按标签（cluster、alertname 等）把同类告警合并成一条通知，解决告警风暴：一个机房断网不该收到两百条邮件，而应是一条"该机房 200 个目标失联"；抑制 inhibition——高级别告警触发时自动压掉相关的低级别：节点宕机（critical）时，该节点上所有服务不可达（warning）的告警被抑制，因为它们是同一根因的衍生现象；静默 silence——维护窗口期临时屏蔽匹配规则的告警，到期自动恢复，避免计划内变更刷屏。

路由 route 按标签树分发到不同渠道：critical 走电话短信、warning 走邮件钉钉企业微信 webhook。规则侧的 for 参数要会解释：条件需持续满足 N 分钟才真正触发，防指标抖动误报。 实操模板（告警规则：节点失联 + CPU 过高）：

# /etc/prometheus/rules/alert.yml（prometheus.yml 里 rule_files 引用）
groups:
- name: node-alerts
  rules:
  - alert: NodeDown              # 目标失联 = up 为 0
    expr: up == 0
    for: 1m
    labels:
      severity: critical
    annotations:
      summary: "节点 {{ $labels.instance }} 采集失联"
  - alert: HighCPU               # CPU 使用率 > 85% 持续 5 分钟
    expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "节点 {{ $labels.instance }} CPU 使用率超过 85%"

追问链：

• 迭问1：告警规则里的 for 是干什么的？ → 答：for 定义"条件持续满足"的确认期：表达式为真后进入 pending 状态，持续满 for 时长才 firing 并真正通知。作用是防抖——CPU 尖峰 10 秒就过去、网络抖一下 up 瞬间为 0，这类毛刺不该半夜叫醒人。for 的取值和指标窗口配合：窗口 [5m] 平滑曲线，for 2-5m 确认持续性，两层过滤后还报警的基本是真问题。这个思路和 Zabbix 触发器里 avg(5m) 的设计是一个道理——不同工具、同一原则。
• 迭问2：怎么验证告警链路通不通？ → 答：我的做法是上线前做全链路演练：故意 systemctl stop 一个 node-exporter，让 up==0 的告警真实触发——观察 Alertmanager 收到、渠道通知送达、恢复后是否收到 resolved 恢复通知，全链路走一遍。没有演练过的告警体系等于没配——"告警本身也需要被测试"是我强调的原则，因为我们监控的目的是"有人被叫醒"，链路任何一环断掉都是白配。

7.10 Grafana：数据源与大盘 【理解】

标准回答： Grafana 在体系里只做可视化不做采集。使用流程三步：添加 Prometheus 数据源——地址填 http://127.0.0.1:9090（我们同机部署所以是本机回环），Save & Test 通过即可；导入大盘——用社区现成模板，Node Exporter Full（ID 1860）看主机、Kubernetes 集群大盘看集群对象，导入后数据源对上立刻出图；配变量——variable 查询做节点下拉切换，一块大盘看所有机器。

面板的本质是 PromQL 加图表类型：折线图看趋势、仪表盘看水位、表格看列表。Grafana 也有自己的告警功能，我们的选择是统一走 Alertmanager——规则集中在 Prometheus 的 rules 文件里管理，和采集配置一起纳入文档版本化；Grafana alerting 适合没有 Prometheus 规则体系的轻量场景。两者职责一句话：Prometheus 管数据、Alertmanager 管告警、Grafana 管展示。 追问链：

• 迭问1：大盘上的节点下拉框怎么实现？ → 答：用 Grafana 的 Template variable：新建变量，Query 类型填 label_values(node_cpu_seconds_total, instance)——label_values 函数返回该指标上 instance 标签的全部取值，变成下拉选项；再把面板的 PromQL 里 instance 的值写成 $变量名。效果是选哪个节点、所有面板就过滤到哪个节点——一块模板大盘服务全部节点。这是配大盘的标准动作，我给节点和集群层大盘都配了变量。
• 迭问2：Grafana 告警和 Alertmanager 告警用哪个？ → 答：我们统一走 Alertmanager，理由三点：规则和采集配置放同一套文件，集中管理；Alertmanager 的分组、抑制、静默这些降噪能力 Grafana 原生告警当年不具备；值班升级、多渠道路由在 Alertmanager 里更成熟。Grafana alerting 的适用场景是快速可视化验证或没有 Prometheus 规则体系的小环境。我的原则："告警链路只有一条"，两个系统都发告警必然出现口径不一致和重复通知。

关联话术："移动云项目 Grafana 部署还踩过一个坑：apt 装 Grafana 时阿里云镜像站的 GPG 公钥 404，装不上——最后是源配置加 [trusted=yes] 跳过签名校验解决（内网可控环境的权衡），或者下 DEB 包本地装。这条在我们 9 项避坑清单里排第 5——监控工具自己都装不上，说明'部署监控前先解决监控工具的供给'也是个真实话题。"

7.11 Zabbix 与 Prometheus 对比 【理解】

标准回答（沿用课程八股框架，表格为速查）： 两个监控系统我按六个维度对比。架构：Zabbix 是 C/S——Server 加 Agent（或 Proxy 分层），数据存 MySQL 等关系库；Prometheus 是 Server 加 Exporter，数据存自研 TSDB——为时序数据专门设计，写入和按时间查询效率高。模式：Zabbix 以 Agent 主动/被动上报为主（push）；Prometheus 是 Server 拉取（pull）加服务发现。

查询：Zabbix 用 Web 图形化配置触发器表达式，上手友好但复杂聚合弱；Prometheus 用 PromQL，多维标签聚合灵活强大，学习曲线陡一点。规模：Zabbix 单机约支撑数千节点、数据库易成瓶颈；Prometheus 单机可处理每秒千万级数据点。场景分界是核心结论：传统 IT——物理机、网络设备 SNMP、静态环境、图形化配置需求——Zabbix 合适；云原生动态环境——Pod 生灭、K8s 服务发现、容器生态——Prometheus 是标配。

短板各自也有：Zabbix 扩展性和存储效率弱；Prometheus 长期存储要外挂 Thanos/VictoriaMetrics，且没有 Zabbix 那种开箱的图形化配置。

维度	Zabbix	Prometheus
架构	C/S，Server + Agent/Proxy，数据存关系型数据库（MySQL）	Server + Exporter，数据存自研 TSDB
模式	Agent 主动/被动上报（push 为主）	Server 拉取（pull）+ 服务发现
查询	Web 图形化、触发器表达式	PromQL 多维聚合，灵活强大
规模	单机约 5000 节点，数据库易成瓶颈	单机千万级数据点/秒
场景	传统 IT：物理机、网络设备（SNMP）、图形化配置友好	云原生动态环境：K8s 服务发现、容器生态标配
短板	扩展性差、存储效率低	长期存储要外挂 Thanos/VictoriaMetrics，学习曲线陡

追问链：

• 迭问1：你们为什么不用 Zabbix？ → 答：环境决定的：K8s 里 Pod 随时生灭，Zabbix 的静态主机模型和主机注册流程跟不上——每天都有"新主机出现旧主机消失"，光维护主机清单就不可持续；Prometheus 的服务发现加短生命周期指标模型就是为这种环境设计的，而且 kube-state-metrics、cAdvisor 天然出标准指标，生态契合。同时我补一句公正的：Zabbix 我会用（课程实验加理解口径），传统物理机和网络设备监控场景它依然合适，SNMP 支持和图形化配置是它的长项——不贬低工具，只讲匹配。
• 迭问2：Zabbix 跨网段怎么做？ → 答：部署 Zabbix Proxy：在目标网段放一台 Proxy，它负责采集本网段 Agent 的数据再回传主 Server——Proxy 解决了跨网段连通性和集中server压力两个问题。配置要点：Server 和 Proxy 间 10051 端口通、Agent 配置指向 Proxy、路由和防火墙放行。这个架构思想（分层采集代理）在各类监控体系里通用，Nagios、Prometheus 的联邦都有类似分层设计。

7.12 监控体系设计思路：三层指标与黄金指标 【理解】

标准回答： 从零设计监控我按三层铺。第一层基础设施：主机存活（up 指标）、CPU/内存/磁盘/网络（node_exporter）、硬件层（IPMI/iBMC 带外，银行项目 TaiShan 的 iBMC 就是这个层）。第二层容器平台：节点 Ready、控制平面组件健康（apiserver 的 up、etcd endpoint health、kubelet 状态）、K8s 对象状态（kube-state-metrics 的 Pod phase/副本数/重启次数）、容器资源用量（cAdvisor）。

第三层应用服务：用 Google SRE 的黄金指标四件套——延迟 Latency（接口 P95/P99）、流量 Traffic（QPS）、错误 Errors（5xx 比例）、饱和度 Saturation（连接池/队列水位/资源利用率）。

实施策略：先把下两层做扎实保可用性，应用层按业务逐个接埋点演进；告警必须分级（critical/warning/info）并对人——谁能处理谁接收，告警发出去没人看等于没有。这个框架是我移动云监控方案的骨架。 追问链：

• 迭问1：先做哪三件事？ → 答：优先级排三件：一是主机存活加资源告警——其中磁盘满最高优先级，磁盘满是节点级灾难（触发 Pod 驱逐、组件崩溃连锁反应），我们配 85% 预警；二是核心组件状态——apiserver up、etcd 三副本 health、节点 Ready，控制面失聪比单机故障严重得多；三是"慢故障"类——证书有效期（30 天预警）、etcd 磁盘水位、时间同步状态，这类不报警但一炸就是大事的项目最容易漏。先快故障后慢故障，是排优先级的思路。 关联话术："移动云项目我就是按这三层落地的：全节点 node_exporter 是第一层，kube-state-metrics 加 apiserver 指标是第二层，第三层应用指标和链路追踪写进了建设方案的演进规划章节——'已做的'和'规划中的'分开讲，既展示体系思维又保持口径诚实，这是我答规划类问题的方式。"

7.13 可观测性三支柱：指标、日志、链路 【理解】

标准回答（一句话口径，必背）： 可观测性三支柱的一句话分工：**指标 Metrics 回答"发生了什么"——Prometheus 负责，数字化的聚合视角；日志 Logging 回答"为什么发生"——ELK/Loki 负责，离散的事件细节；链路 Tracing 回答"问题出在哪一环"——Jaeger/SkyWalking 负责，跨服务调用的全路径视图。

** 三者靠标签和 traceID 关联起来才构成完整的可观测：指标发现问题（错误率升了）、链路定位环节（卡在支付服务的 DB 调用）、日志确认根因（那条慢 SQL 的报错）。还要区分两个概念：监控是可观测的子集——监控负责"发现故障并告警"，可观测还要支撑快速定位和复盘，把 MTTR 往下压。这就是为什么云原生体系里三者要一起建。 追问链：

• 迭问1：你们项目做到哪一层？ → 答：诚实分层答：指标层完整落地——三层指标加 Grafana 大盘加 Alertmanager 告警；日志层用 Kuboard 的日志终端做容器内排障（进容器看实时日志，覆盖日常排障场景），集中式日志（Loki/EFK）和链路追踪（Jaeger/SkyWalking）在方案演进规划里。我的答法是主动把它讲成"我规划过下一步怎么做"——Loki 轻量接入现有 Prometheus 生态、应用先统一日志格式、链路从网关层开始埋——而不是"我没做过"，这是口径的艺术也是事实。
• 迭问2：SLI/SLO/SLA 是什么？ → 答：三个递进：SLI 是量化的服务等级指标——比如接口成功率、P99 延迟，是"测量什么"；SLO 是给 SLI 定的内部目标——成功率不低于 99.9%，是"要求多好"；SLA 是对外合同化的承诺——通常比 SLO 松，违约有赔偿条款，是"对外承诺"。落到我们：集群控制平面按 99.99% 可用性目标设计（三副本 etcd 加 CLB 秒级摘除），这是设计目标的口径，不是运行实测 SLA——用这套语言能把"监控指标"提升到"服务可靠性管理"的层面。

7.14 Pushgateway 与短任务监控 【了解】

标准回答： Pushgateway 解决的场景：短生命周期任务（定时脚本、批处理作业）在 Prometheus 拉取周期到来之前就退出了，pull 模型永远抓不到它——所以让任务结束时把指标 push 到 Pushgateway 暂存，Server 再定期从 Pushgateway 拉取。

典型用法是备份脚本结束时 push 一条"backup_success 1 加耗时"的指标，监控备份是否成功。它的两个局限要知道：一是单点——本身没有高可用时是链路里的脆弱点；二是指标不会自动过期——任务死了它的最后值还挂在上面造成"看似正常的假象"，必须配 TTL 清理或脚本主动删。所以定位是"兜底组件，只补短任务，不做主力通道"。

我们环境没有短任务指标需求，所以没部署——"知道它解决什么、判断自己需不需要"是这题的答法。 追问链：

• 迭问1：脚本指标还有什么办法？ → 答：两条更轻的路：一是脚本自己暴露 /metrics 让 Prometheus 直接拉——把脚本改造成常驻的 mini exporter，适合持续运行的采集逻辑；二是用 node_exporter 的 textfile collector——脚本定期把指标写进 /var/lib/node_exporter/textfile 目录的 .prom 文件，node_exporter 采集时自动带上，零额外组件。备份结果、证书到期天数这类"每天算一次"的指标用 textfile 最优雅——我的证书到期巡检脚本就适合这个方案。

7.15 Kuboard 与监控的配合 【了解】

标准回答： 简历技能第 6 条同时提了 Kuboard，和 Prometheus 是互补关系不是竞争：Prometheus 加 Grafana 负责"指标与告警"——看趋势、设阈值、通知人；Kuboard 负责"资源可视化与操作"——工作负载编排、日志终端进容器排障、RBAC 多级权限、操作审计，它还能对接 Prometheus 数据源在平台内直接看监控图。

日常工作的分工实感：80% 的日常运维操作（发布、扩缩容、看日志、查事件）在 Kuboard 页面完成，降低了团队 kubectl 门槛；指标异常和容量规划回 Grafana 看历史趋势和大盘。选它的理由很实际：给团队降低使用门槛——不是人人都会 kubectl，但人人都会点网页，而权限和审计保证了"能点"不等于"乱点"。 追问链：

• 迭问1：为什么要两个工具？ → 答：因为它们解决的是不同问题：Grafana 是通用可视化平台，只能看不能操作，解决不了"对集群做变更"的需求；Kuboard 是 K8s 运维操作平台，面向日常操作和权限管理，但时序分析能力远不如 Grafana。组合的价值是"监控看 Grafana、操作用 Kuboard"，给不同角色合适的入口——开发看自己服务的图、运维做操作、领导看总览——工具跟着角色走，这是我给团队设计工具链的思路。

7.16 Prometheus 数据存储与长期存储 【了解】

标准回答： Prometheus 本地 TSDB 的存储机制：数据按 2 小时一个 block 落盘，block 内按时间分块压缩；保留期由启动参数 --storage.tsdb.retention.time 控制（新版本默认 15 天），过期 block 自动删除。这个设计的隐含定位：Prometheus 是"近期数据的高性能存取"，不是长期仓库。

要长期存储或全局查询时两条主流路：Thanos——每个 Prometheus 旁挂 sidecar 把 block 上传对象存储（S3/OSS），Querier 组件跨多个数据源做全局查询，还可配 Compactor 压缩降采样；VictoriaMetrics——独立的兼容存储，直接作为 Prometheus 的 remote write 后端，部署更简单性能好。

我们的判断：6 节点规模、单机 TSDB、默认保留期完全够用，容量和查询都没有压力——存储方案跟着数据量和保留需求走，不为"可能会用到"提前上复杂架构。 追问链（兜底话术示范）：被问 Thanos 细节 → "生产上我按单节点加 retention 的方式管理过 Prometheus 存储，容量和保留期的权衡我实际做过；Thanos 我理解到 sidecar 上传 block 到对象存储、Querier 做跨源聚合这一层，组件级的调优（比如 Compactor 的降采样策略）我还没实际操作过，可以会后补——不过我们的规模用不上它，这也是我当时没选它的原因。"——先答实践、再答理解、最后讲选型判断，兜底也要有结构。

7.17 Prometheus 常被问到的三个"落地"问题（速答）

• 你们监控告警怎么通知的？ → 答：完整链路是告警规则在 Prometheus 的 rules 文件里定义、周期评估，满足条件且过了 for 防抖时间后推给 Alertmanager，它按标签分组路由到邮件、企业微信或钉钉 webhook 渠道；critical 和 warning 分级触达——critical 找值班人、warning 进群通知。规则文件和 prometheus.yml 一起纳入文档管理，改规则走评审。
• 监控覆盖了哪些对象？ → 答：三层口径答：第一层 6 节点主机指标（node_exporter 的 CPU/内存/磁盘/网络）；第二层控制平面与集群对象（apiserver 指标、etcd 健康、kube-state-metrics 的 Pod/副本/节点状态）；第三层 Grafana 大盘可视化汇总。应用层指标是演进项，方案里已有规划——覆盖范围如实划界，不虚报。
• 怎么知道告警规则生效了？ → 答：三个检查动作：Prometheus Web UI 的 Alerts 页看每条规则的状态——inactive（正常）、pending（条件满足但还在 for 期内）、firing（已触发）；Status → Rules 页确认规则文件加载无误；上线前做过 up==0 的全链路演练——停一个 exporter 真实触发，验证通知送达和恢复通知。"配了"和"生效了"是两回事，验证动作必须有。

7.20 PromQL 进阶：常用查询集与运算符 【理解】

标准回答： PromQL 的进阶用法我按"运维会用到什么"整理成查询集。聚合分组：sum by (instance) (指标) 按节点汇总、avg by (pod) (...) 按 Pod 均值——by 是最常用的修饰符。过滤：标签匹配 up{job="node-exporter"} 等值、{status=~"5.."} 正则匹配（=~）；范围选择 [5m] 配 rate/avg/sum_over_time 等函数。

对账型查询（我最有心得的一类）：算集群总请求量 sum(rate(http_requests_total[5m]))；算 5xx 比例 sum(rate(http_requests_total{status=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) * 100——分子分母同窗口相除，这个"比率查询"模式通用于错误率、命中率、使用率；对比类：(1 - 命中数/总数) 取反。

时间函数：avg_over_time(指标[1h]) 窗口均值（容量规划看趋势）、predict_linear(指标[1h], 4*3600) 按近 1 小时斜率预测 4 小时后的值——磁盘满预测告警的写法：predict_linear(node_filesystem_free_bytes[2h], 8*3600) < 0 表示"按当前增速 8 小时内写满"，比静态 85% 阈值聪明得多。

这套查询集是我大盘和告警规则的实际原料。 追问链：

• 迭问1：increase 和 rate 的区别？ → 答：rate 求每秒平均增长率，increase 求窗口内的总增量——increase(计数器[1h]) 就是这一小时涨了多少，二者本质同源（increase ≈ rate × 窗口秒数）。使用习惯：算 QPS、CPU 使用率用 rate；算"今天新增了多少请求/错误"这类总量报表用 increase。还有个关联细节：Counter 重启归零时这两个函数都能自动处理（检测到计数下降会按重启补偿），所以不用担心重启导致的负值污染曲线——这是 Prometheus 对 Counter 语义的内置照顾。
• 迭问2：predict_linear 预测告警怎么配才不误报？ → 答：三个要点：窗口别太短——用 [2h] 以上，几分钟的窗口会把备份这类周期性写入放大成"即将写满"的假警报；阈值方向确认——predict_linear(空闲字节, N 小时) < 0 表示 N 小时后耗尽；再配 for 5m 持续条件防单点毛刺。我的组合拳：predict_linear 做"提前预警"（提前半天到一天知道要满），静态 90% 做"当下止损"——两条规则互补，预测给人规划时间、硬阈值保底线。

7.21 recording rules：记录规则预计算 【理解】

标准回答： recording rules 解决的问题是"常用且重的查询每次实时算太贵"：把复杂表达式预先算好存成一条新指标，大盘和告警直接查新指标。机制：规则文件里 record: instance:node_cpu_util:rate5m 给新指标命名，expr: 100 - (avg by (instance) (rate(...)) * 100) 写原表达式，Prometheus 按评估周期（evaluation_interval，我们 15 秒）持续计算并落 TSDB。

三个收益：性能——CPU 使用率这种多序列聚合的查询，面板每次刷新都重算历史窗口，预计算后变成查一条现成序列，大面板加载明显变快；复用——同一表达式在大盘、告警、周报里用，规则算一次处处用，口径还统一（都来自同一条 record）；语义化——指标名本身表达了业务含义，查询语句可读性大增。

命名约定我按官方惯例 level:metric:operations（如 instance:node_cpu_util:rate5m），一眼看出层级和算子。 追问链：

• 迭问1：什么表达式值得做成 record？ → 答：判断标准两条：使用频率高（多面板共用）且计算重（rate 加聚合加多序列）；或者被告警规则依赖——告警每 15 秒评估一次，重的 expr 每次都算，预计算把成本摊销掉。反过来，一次性 ad-hoc 查询、轻量单序列查询不值得。我的实践顺序：先写裸 expr 用起来，发现它在三个以上地方出现或告警评估压力大，就沉淀成 record——"规则从使用中长出来"，不要一开始过度设计。

7.22 告警分级、值班与降噪实践 【理解】

标准回答： 告警体系的实战关键不在"配出告警"而在"配出能被人响应的告警"。

我的分级实践：critical——影响业务的确定性故障（节点失联、 apiserver 不可用、磁盘将满），电话或强提醒直达人，要求立即响应；warning——异常趋势（CPU 持续 85%、副本不满、重启次数上涨），进群通知，工作时间处理；info——记录性事件（配置变更、证书剩余 30 天），只进面板不推送。降噪三条纪律：每条告警必须有人认领负责——没人认领的告警要么删要么降级，"发给所有人就是发给没有人"；同根因聚合——靠 Alertmanager 分组（7.9）把一次故障压成一条通知；定期复盘告警质量——每月统计告警量和误报率，删掉从未"真响过"的规则。还有一条验收标准：真正的 critical 响应时间以分钟计——告警链路我们做过演练（7.9 的追问 2），从触发到通知送达全程可验证。 追问链：

• 迭问1：怎么处理"告警风暴"？ → 答：事前预防：规则层面 for 防抖 + 分组聚合 + 抑制规则（主机宕机压掉该机所有衍生告警）；事中止血：维护窗口用 silence 静默（例如批量变更时段提前静默相关告警 30 分钟），风暴已发生时先在 Alertmanager 上按标签临时静默一类，保住 critical 通道的注意力；事后治理：复盘风暴根因——多数风暴是"一个根因 × 一批对象 × 每对象一条规则"的乘法效应，解法是把规则改成聚合维度（按集群而非按节点发）。这套"防、止、治"的框架是我的实际做法。

7.23 常见 Exporter 清单与选型 【了解】

标准回答： 按对象记一份我熟悉和用过的 Exporter 地图。主机层：node_exporter——我们全节点部署（apt 二进制版）。K8s 层：kube-state-metrics（对象状态）加 kubelet 自带 cAdvisor（容器用量）加 apiserver/etcd 自带 metrics 端点（组件指标）。

数据库：mysqld_exporter（连接数、QPS、复制状态）、postgres_exporter（PG 系，Vastbase 场景理论同源）。中间件：redis_exporter（内存、命中、主从）、kafka/jmx 类。黑盒探测：blackbox_exporter——从外部探测 HTTP/TCP/Ping/DNS，做"用户视角"的可用性监控（拨测），和内部指标互补。

使用模式我总结三句：优先官方或社区主流 exporter，读它的 /metrics 确认关键指标存在；采集配置遵循"标签有限"原则防高基数；exporter 本身要被监控（up 指标天然覆盖）。

我的实际部署覆盖前两类，数据库和中间件类属于"知道怎么接"的层——云上对应能力由云监控承担，我的职责是把云侧告警接入统一通道。 追问链：

• 迭问1：blackbox 和内部 exporter 什么区别？ → 答：视角不同：内部 exporter 报告"组件自己觉得怎么样"（内存、队列、线程），blackbox 从外部模拟用户访问"入口到底通不通、多快"——HTTP 状态码、耗时、证书过期时间。两者互补的典型场景：服务内部指标全绿但入口 502（中间链路问题），只有拨测能第一时间发现。金融客户对"用户视角可用性"很敏感，我在方案里规划过拨测层（公网入口探活加证书到期监控），属于演进项——答的时候同样按"已做/规划"分层。

7.24 Prometheus 自身监控与容量 【理解】

标准回答： 监控系统的自我管理三个动作。自监控指标：Prometheus 自身暴露 metrics（9090），关键几个要盯：prometheus_tsdb_head_series 当前序列总数（容量水位的核心）、scrape_duration_seconds 各 job 抓取耗时（接近 scrape_interval 就会丢点）、scrape_samples_scraped 单目标样本量、prometheus_rule_evaluation_failures 规则评估失败数（规则写错这里报警）。

容量判断逻辑：序列数和内存正相关（经验值每百万序列若干 GB），抓取超时应小于周期的三分之二；我们的规模（6 节点加少量 job）这些指标非常宽裕。

高可用口径：单实例 + systemd 自动拉起 + 节点级告警兜底（7.1 讲过），监控节点本身也被另一个维度的云监控看住——"谁监控监控者"的答案在我们的架构里是分层互看：Prometheus 看集群，云平台基础监控看监控节点。 追问链：

• 迭问1：Prometheus 变慢、内存高，怎么定位和治理？ → 答：定位按数据流倒着查：先看 head_series 是不是暴涨——新序列来源多半是某个 exporter 的标签基数变大（某应用版本给指标加了 user 维度），找出高基数 job（topk 按_job_ 或者 TSDB 页面看）后从源头改标签；再查抓取负载——samples_scraped 最大的目标、scrape_duration 超时的目标，降频（该 job 的 scrape_interval 单独放大）或裁剪 exporter 暴露的指标（metric_relabel_configs drop 无用指标）；最后查查询侧——昂贵的大范围查询（无过滤的全量 rate）会拖慢服务，用 recording rules 预计算。三步分别对应"存储、采集、查询"三个子系统——按子系统拆解是这类性能问题的通用框架。

7.25 日志方案：Loki 与 EFK 概念与选型 【了解】

标准回答： 集中式日志两大流派我按架构和成本讲。EFK（Elasticsearch + Fluentd/Filebeat + Kibana）：日志全文进 ES 建索引，Kibana 查询可视化——搜索能力强（任意关键字全文检索）、生态成熟；代价是资源重（ES 集群本身吃大量 CPU 内存磁盘）、按索引存储成本高。

Loki（Grafana 系）：只索引标签（哪些服务、哪些 Pod），日志内容压缩存对象存储不建索引——查询时先按标签缩小范围再过滤内容；架构轻、成本低一个量级，配合 Grafana 原生查询界面；代价是没有全文索引，"不知道标签的大海捞针"查询慢。选型逻辑：云原生 K8s 环境、日志按服务/命名空间检索为主 → Loki 性价比极高；有强全文检索合规需求（审计追溯）→ ES 系。

我们的现状：容器内日志用 Kuboard 日志终端按 Pod 查看（够用），Loki 接入在我方案的演进规划里——理由是它和我们 Prometheus + Grafana 技术栈同源，标签体系和监控指标打通，接入成本最低。 追问链：

• 迭问1：为什么 K8s 场景 Loki 更受欢迎？ → 答：因为 K8s 的日志天然带"标签结构"：namespace、pod、container 这些维度抓取时就有了——Loki 只索引这些标签正好匹配；而日志正文里随机关键字检索的需求在排障中占比其实不高（多数排障是"看某个服务最近的错误"，按标签定位足够）。加上 Loki 的存储用对象存储、组件少、和 Grafana 一套体系，运维负担远低于维护一个 ES 集群。我们的规划顺序也说明这一点：先 Loki 覆盖 80% 场景，真有全文检索刚需再考虑给特定日志（审计类）单独上 ES——按需分层而不是一步到位。

7.26 链路追踪：Jaeger / SkyWalking 概念 【了解】

标准回答： 链路追踪解决"一次请求经过了 8 个服务，慢在哪个"的定位问题，属于可观测三支柱里我们未落地的一支（7.13 的话术：规划过、没做过）。核心概念我按串起来讲：trace 一次请求的全程唯一 ID（traceID），随请求头在服务间透传；span 一个处理步骤（一次 RPC、一次 DB 查询），记录起止时间和标签，span 之间父子嵌套；全部 span 按 traceID 聚合，就得到这次请求的瀑布图——耗时分布在哪个服务、哪次调用一目了然。

实现机制：应用侧靠 SDK 埋点（Java Agent 字节码增强对业务无侵入）或服务网格 sidecar 拦截；数据上报收集器存储；查询界面按 traceID 或服务筛选。产品对比一句话：Jaeger 是 CNCF 开源标准实现（Uber 出品，云原生亲和）；SkyWalking 国产 Apache 顶会项目，对国内技术栈（Java 生态、告警一体、拓扑图）友好。

接入路径的规划口径：从网关和核心链路先埋点，traceID 打进日志——这样指标（哪个接口慢）、链路（哪一段慢）、日志（那一段报了什么）三者就串起来了。 追问链：

• 迭问1：traceID 怎么把日志和链路串起来？ → 答：约定链路 SDK 把 traceID 放进日志上下文（MDC），应用每行日志都自动带上 traceID；排查流程变成：告警发现接口错误率升（指标层）→ 在 Grafana 看到错误样本的 traceID（应用日志）→ 拿 traceID 到追踪系统展开瀑布图（链路层）→ 定位到具体 span 后再看那个服务的日志细节（日志层）。三支柱靠 traceID 变成一条排查动线——这就是"可观测性"比"监控"多出来的部分：不只是报替，还能导航。我把这套动线在演进方案里写成了目标态。

7.27 监控大盘设计原则 【理解】

标准回答： 大盘不是图表堆砌，我的设计原则五条。第一条按"用户和决策"分层：总览盘给管理者和值班——集群健康度、核心业务可用性、告警概览，一眼判断"现在有没有事"；细节盘给排查者——单节点资源、单服务指标、下钻入口。第二条黄金位置给关键指标：首屏放 up 状态、错误率、资源水位这类"决定要不要行动"的指标，装饰性图表全部后置。

第三条一个面板回答一个问题：标题写成问句（"哪些节点 CPU 过热？"）比"CPU 监控"有用；面板类型匹配数据性质——趋势用折线、水位用仪表、构成用堆叠、状态用表格。第四条变量驱动复用：节点/命名空间下拉变量（7.10）让一块模板服务所有对象，避免复制粘贴几十块面板。第五条阈值可视化：面板上画出告警线（85% 的 reference line），看图的人不需要背阈值。

我们移动云的节点大盘和集群对象大盘就是按这套原则搭的——从"能看"到"好用"差距就在这五条。 追问链：

• 迭问1：怎么衡量一块大盘做得好不好？ → 答：我的检验标准是场景化的：半夜告警响了，值班同学打开大盘能否在 30 秒内回答三个问题——什么东西坏了、影响多大、要不要升级。达不到就是信息架构有问题（关键指标没在首屏、缺少上下文标注）。另一个检验是新人测试：没参与建设的人独立用大盘定位一次注入的故障——能走通说明结构自解释。大盘是给别人用的不是给自己看的，这两个测试都过了才算合格。

7.28 从 0 到 1 的监控落地检查单 【理解】

标准回答： 把我整个监控建设过程提炼成可复用的从 0 到 1 检查单，十步：① 明确监控对象清单和优先级（节点、控制面、对象、应用四层）；② 部署 Prometheus + Grafana（部署位置决策：独立节点 vs 集群内——我们选独立节点为故障隔离）；③ 逐层接采集（node-exporter → kube-state-metrics → apiserver），每接一层 Targets 页确认 UP；④ 配大盘（先总览后细节，按 7.25 的设计原则）；⑤ 第一条告警永远是 up==0（保住"监控自己活着"）；⑥ 再铺资源告警（磁盘满最高优先级）；⑦ 接 Alertmanager 渠道并做一次全链路演练（停一个 exporter 真实触发）；⑧ 建立告警分级和认领制度；⑨ 沉淀 recording rules 和面板到文档；⑩ 定期复盘（告警量、误报率、覆盖率缺口）。

这份检查单的每一步我在移动云项目都真实走过，其中踩坑修正的位置我都标注了（时间同步在 0 步就要做、镜像供给先于部署）——它是我"标准化方法论"的监控分册。 追问链：

• 迭问1：接手一个没有监控的存量环境，第一步做什么？ → 答：不是装工具而是"摸底定优先级"：先盘点什么在跑（节点、服务、依赖关系）、哪些是核心链路、历史上哪里出过事——据此排出监控对象的优先级，然后从优先级最高的那层开始按检查单走。切忌一上来铺全家桶：没有优先级的全面监控等于没有监控，第一批告警永远配给"挂了最疼"的对象。我在移动云就是这个顺序：先集群三件套（节点/控制面/对象）再谈演进——"先保命、再治病、后健身"。

7.29 指标单位、口径与常见换算 【了解】

标准回答： 监控指标的"单位坑"看起来基础，实际是误读数据的重灾区，我把容易错的几类整理清楚。字节的进制：Prometheus 指标全是基本单位字节（bytes）——node_memory_MemAvailable_bytes 是字节不是 MB，换算用 1024 进制；Grafana 面板的单位设成 bytes(IEC) 它会自动渲染成 GiB，别在表达式里手动除以 1024 的三次方再叠加面板单位，会双重换算。CPU 的口径：usage 是"核"的小数（0.5 = 半核），container_cpu_usage_seconds_total 是累积秒、要 rate；requests 的 500m 就是 0.5 核——把 mCPU 和核换算清楚才不会得出"CPU 500%"的笑话。百分比的方向：磁盘使用率是 used/total，Prometheus 常用"1 - avail/total"来算（可用量的补集），两个公式结果一致但要固定口径，否则不同面板对不上。时间的口径：rate 的窗口 [5m]、for 的持续、scrape_interval 三者是不同维度——窗口是数据的平滑、for 是告警的确认、interval 是采集密度，面试里能区分这三个时间参数，说明真用过多长时间序列。

追问链：

• 迭问1：为什么面板数值和 kubectl top 对不上？ → 答：两个口径差异：数据源——kubectl top 来自 metrics-server 的快照（采样点值），Grafana 面板通常是 rate 加窗口平滑后的均值——瞬时值和平滑值本来就有差；容器边界的口径——cAdvisor 的 container 指标和 Pod 级汇总（含 pause 容器与否）、CPU 的平均和加权方式（limit 加权）都会造成几个百分点的差异。我的处理原则：对趋势和告警看 Prometheus（一致可比），对"此刻这个 Pod 用了多少"的即时判断用 kubectl top——两个工具回答不同问题，不追求它们显示同一个数。

7.30 Thanos 与 VictoriaMetrics：长期存储方案对比 【了解】

标准回答： Prometheus 长期存储两大方案，按架构讲。Thanos：组件化路线——每个 Prometheus 旁挂 sidecar，把 TSDB block 上传对象存储（S3/OSS/COS）实现长期保留；Querier 聚合多个数据源（各 Prometheus 加对象存储）提供全局查询视图；Store Gateway 读对象存储里的历史数据；Compactor 降采样压缩（保留原始、5 分钟、1 小时三档精度）；可选 Ruler 做集中告警评估。优点是彻底的社区标准、对象存储成本低、可配全局高可用；代价是组件多（五六个）、部署和排障复杂度明显上升。VictoriaMetrics：一体化路线——作为 Prometheus 兼容的独立存储，Prometheus 配 remote_write 把数据推给它即完成，单二进制部署、压缩率和查询性能都优秀、兼容 PromQL（大部分）。优点是简单省心、资源效率高；取舍是绑定这个存储生态、部分高级 PromQL 语法兼容有边角差异。我的选型建议：已有对象存储、要标准化的多集群大场景 Thanos；中小团队想要"低运维成本的一站式长期存储" VictoriaMetrics 更省心——我们当前规模单机 TSDB 够用，这题我按"知道边界、能给选型建议"的口径答（7.16 的兜底话术延续）。

追问链：

• 迭问1：remote_write 会不会拖垮 Prometheus？ → 答：可能，所以要懂它的保护参数：remote_write 是异步批量发送——数据先进内存 shard 队列，按 batch_send_interval 和 max_samples_per_send 批量推送；对端慢会导致队列堆积，参数上靠 max_shards 上限并发、capacity 控内存；更有效的手段是降载——发送前用 write_relabel_configs 丢弃低价值指标（开发环境、debug 级指标），把远程写入的数据量压到必要集合。判断健康看两个自身指标：prometheus_remote_storage_shards 和 pending samples。这套容量保护思路我在答"监控系统自己也要被容量规划"时一起讲。

7.31 云监控与自建监控的配合 【理解】

标准回答： 移动云项目我的监控体系是"云监控 + 自建 Prometheus"双层配合，这个组合逻辑值得讲清。云监控层（平台自带）：云服务器的基础指标（CPU/内存/磁盘/网络）、CLB 后端健康状态、云数据库和 Redis 的实例状态与延迟、告警短信通道——它的优势是零部署、覆盖基础设施层、通道可靠（短信电话级）。自建 Prometheus 层：K8s 集群内部视角——节点（node-exporter）、控制平面（apiserver）、集群对象（kube-state-metrics）加 Grafana 大盘——它的优势是云内视角细、PromQL 灵活、标签体系能按业务聚合。配合的三条原则：分工不重叠——基础层告警交给云监控（它看得到硬件和宿主层，自建看不到），集群内视角交给 Prometheus，同一对象不配双份告警避免重复通知；通道归一——两类告警最终汇到同一组接收人（云监控短信 + Prometheus 经 Alertmanager 到群），值班的人只认一个告警入口；口径统一——大盘引用两边数据时标注来源，跨层对照排障（云监控说实例网络丢包 + Prometheus 说 Pod 重启）正是双层设计的价值：一次故障从"基础设施还是集群"的定位，靠两层对照几秒钟完成。

追问链：

• 迭问1：云监控和自建监控冲突了（一个报警一个正常）怎么解释？ → 答：通常是视角差异而不是谁错：云监控看的是实例/宿主层（节点 CPU、磁盘 IO），自建看的是集群内对象（Pod、Service）——节点资源告警但 Pod 正常（限值不同、或 Pod 有 limit 保护）；或 Pod 重启但节点正常（应用层问题不影响节点）。处理流程：先确认两边的检测对象和口径是否同一层，不是同一层就各自解读；确实是同一层的冲突（都看节点磁盘），再核对采集时刻、阈值定义。我的经验："告警不一致"大多数时候是信息（提示问题在层与层之间），不是故障——双层监控的价值恰恰是提供这种交叉验证。

7.32 监控 SOP 与运维文档化 【了解】

标准回答： 监控建设"从 1 到 100"的关键是把经验变成 SOP（标准作业程序），这是我简历里"制定运维规范"职责在监控域的落地。我的 SOP 清单四类：告警响应手册——每条 critical/warning 告警对应一页"什么含义、第一步看什么、常见原因清单、升级给谁"，值班同学拿到告警不靠猜；巡检 SOP——7.28 检查单的日常版：每天看什么大盘、记录什么快照、异常怎么记录；变更检查单——改监控配置（加 target、改规则）的自检流程：改前备份、改后 Targets/Alerts 页验证、回滚方法写明；故障复盘模板——时间线（告警触发时间、响应时间、恢复时间）、根因、监控为什么没更早发现、要新增哪条规则。这套文档在移动云项目落地为三份实际产出：标准化建设方案（含监控章节）、9 项避坑清单（每条都是"故障 → 解法 → 预防"的微 SOP）、运维规范文档（证书续期、etcd 备份、故障切换演练流程）。我的观点：监控系统的产出不只是大盘和告警，还有"组织对这个系统的可复制认知"——人可以休假，SOP 不休假。

追问链：

• 迭问1：告警响应手册具体长什么样？ → 答：以"节点失联 NodeDown"为例，一页手册包含五栏：告警定义（up==0 持续 1 分钟）与含义（该节点所有指标采集中断，可能是宕机/网络断/进程亡）；第一步动作（云控制台看实例状态——区分云层故障和 OS 层故障）；常见原因清单（实例停机、安全组误改、节点宕机、Prometheus 到节点网络断）；升级路径（10 分钟未定位 → 云厂商工单 + 团长）；关联预案（节点维护 SOP、Pod 驱逐影响评估）。每个高频告警一页，值班同学按单操作——新同学第一天也能正确响应，这就是手册的价值。

7.33 Prometheus HTTP API 与外部集成 【理解】

标准回答： Prometheus 的能力通过 HTTP API（9090 端口）开放出来，这是它"可被集成"的关键。常用三类接口：即时查询 /api/v1/query?query=<PromQL>——返回当前时刻的值，外部程序取指标（比如把磁盘水位写进巡检报表）就用它；范围查询 /api/v1/query_range——带 start/end/step 取一段时间序列，报表绘图用；_targets 和 /api/v1/alerts—— Targets 健康状态和告警当前状态，做"监控系统的自监控仪表"或巡检脚本采集都方便。安全方面必须提醒：API 默认无认证，生产要靠网络隔离（仅内网/监控节点访问）或反向代理加认证——绝不能暴露公网。我的实际用法：巡检脚本 curl 它的 query 接口取关键指标落报表、值班面板嵌 Targets 状态——"把监控系统当数据源用"是运维开发的入门动作，也是我往 FastAPI 运维工具方向走的素材之一（技能第 3 条的衔接）。

追问链：

• 迭问1：怎么安全地把 Prometheus 查询暴露给其他系统？ → 答：三种模式按安全等级：内网直连——可信内网里直接调 API，靠网络边界保护（我们的现状）；反向代理加认证——Nginx 挂在前面做 basic auth 或 LDAP，按路径限制只开放 /api/v1/query（第 4 章技能的直接复用）；只读导出——不暴露 Prometheus 本身，把需要的指标用 recording rules 或推送到外部只读存储再开放。核心原则是"读写分离"——查询可以按需开放，admin 接口（删序列、关采集）永远不出去。

7.34 监控成本与存储估算 【了解】

标准回答： 监控不是免费的，我的估算方法一套公式加三个例子。估算公式：每日样本量 = 序列数 × (86400 / 采集间隔)；存储量 ≈ 每样本约 1-2 字节压缩后 × 每日样本 × 保留天数。代三个真实数字：单节点 node_exporter 约 500-1000 条序列，6 节点加 kube-state-metrics 加 apiserver，全集群约 8000-15000 条序列；15 秒采集下每序列每天 5760 个点，全集群每天约 1 亿样本点——压缩后每天数百 MB 量级、15 天保留几个 G 到十几 G，单机完全无压力。什么时候需要认真算：加新 exporter（估算它带来多少序列）、缩短采集间隔（15s → 5s 存储翻三倍）、延长保留期——每个决策都拿这套公式先算再动。成本意识的另一面是"删"：用不到的指标（metric_relabel_configs drop）、开发环境的低价值采集，都是存储账单上的赘肉。我们规模的结论"单机 TSDB 加默认保留够用"就是算出来的，不是拍脑袋。

追问链：

• 迭问1：怎么知道当前集群实际有多少序列、占多少空间？ → 答：两个现成入口：Prometheus 自身指标 prometheus_tsdb_head_series 直接给出当前活跃序列数，prometheus_tsdb_storage_blocks_bytes 给磁盘占用——一条 query 就有答案；更细的维度看 TSDB status 页面（head 统计按 job/instance 的序列分布），找出"序列大户"。我们的巡检里就有这两个数——序列数突增（比如新部署的应用带了高基数标签）会在趋势上立刻显形，这就是"监控自己也要被监控"的具体落地。

7.35 值班与应急响应：从告警到恢复的流程 【了解】

标准回答： 监控的终点是"有人被叫醒并且知道做什么"，我的应急响应流程五步走。① 确认收到（0-2 分钟）：看告警的 severity 和对象，critical 先响应；一条告警先判断"影响面"——是单节点还是全局、影响哪个业务。② 快速定位（2-10 分钟）：按 7.32 的告警响应手册执行第一步动作——大盘看关联指标（比如 NodeDown 就看同机房其他节点、该节点上的 Pod 状态），把"哪里坏"缩小到一层。③ 决策处置：能自愈的执行预案（重启、切换、扩容——按 SOP 而不是即兴）；不能立即修的先降级保业务（摘流量、切备用），抢修放后面。④ 通报与协同：影响业务的要按模板通报（现象、影响、当前动作、预计恢复）——通报本身就是职责，不是可选动作。⑤ 恢复与复盘：确认恢复（指标回归 + 业务验证）、补一条复盘记录（时间线、根因、告警是否及时、预案是否有效）。我驻场银行两年参与过多轮故障响应，这套流程是实战里长出来的——第 12 章人事与场景问答会再用到这些故事。

追问链：

• 迭问1：半夜收到告警但看不出来是什么问题，怎么办？ → 答：按"保底动作"走：先确认告警是否真实（是不是监控自身故障或已知维护）——假告警静默并记录；真实的、一时定位不了的，按影响面决策——影响业务就先做保守动作（比如把可疑节点摘流量），不做超出权限的激进变更；同时按升级路径叫人（二线/原厂/云厂商工单——银行项目我们有明确的"一线我、二线华为"分工）；全过程记录时间线和动作。半夜的原则是"宁可保守不可炫技"——大动作留给白天和人多的时刻，这是我驻场学到的最重要的应急纪律。

7.37 容器层监控落地：cAdvisor 指标接入 【理解】

标准回答： Pod/容器资源用量这一层（我们当时的演进项）的落地方案我可以完整讲出来，体现"规划过"的深度。数据源：kubelet 内置的 cAdvisor——每个节点在 10250 端口暴露 /metrics/cadvisor，指标按 container 维度打标签（pod、namespace、container 名）——container_cpu_usage_seconds_total、container_memory_working_set_bytes（这是 OOM 判定依据的口径，比 rss 更准）等。接入三步：Prometheus 配 kubernetes_sd_configs 按 node role 自动发现节点、relabel 把地址改写成 kubelet 的 metrics 接口（tls 加 bearer token 认证）；或简化版——static_configs 直接列六个节点地址（延续我们静态配置的风格）；大盘与告警——按 Pod 聚合 CPU/内存使用率（对 requests 的占比）、配"容器内存逼近 limit"的预警规则（working_set 超过 limit 的 90% 提前告警，赶在 OOMKilled 之前）。接入后能回答的高价值问题：哪个 Pod 是资源大户、requests 设得合不合理（6.10 的容量依据）、谁在被 throttle——监控数据和调度参数形成闭环，这是它比"多几块图"更重要的意义。

追问链：

• 迭问1：container_memory_working_set_bytes 和 rss 有什么区别？ → 答：working_set ≈ RSS 减去inactive_file（不活跃的文件页缓存）——它更接近"容器真正离不开的内存"，内核 cgroup OOM 判定参考的就是它，所以告警和容量评估用 working_set 才和 OOM 行为对齐；rss 包含了可回收的页缓存，会虚高。细节还没完：Java 容器还要看堆内外（堆 + Metaspace + DirectBuffer），容器 working_set 涨不一定是堆涨——"指标口径和故障判定口径一致"是我选监控指标的原则，这个例子最典型。

7.38 用监控数据做容量规划 【理解】

标准回答： 监控数据的终极价值之一是支撑资源决策，我的容量规划方法三步。第一步定对象和口径：节点 CPU/内存、Pod 密度（每节点 Pod 数）、磁盘增长速率、数据库连接数——按对象各选一个"水位指标"和"趋势指标"（P95 使用率 + 30 天增长斜率）。第二步读数据定结论：PromQL 出各维度的 P95（不是均值——均值会掩盖高峰）、avg_over_time 看 30 天趋势、predict_linear 预测到达阈值的时间（7.20 的预测告警思路用于容量）；结论落到"按当前增速，磁盘 X 个月后到 85%"这类可执行表述。第三步给决策选项：扩容（何时、加多少——留出采购周期）、调优（压缩资源虚占：过大的 requests 收回、日志清理降磁盘增速）、限制（LimitRange 防新应用虚占）。我们移动云的实践样例：节点资源用 Grafana 看月度 P95 趋势，worker 的 CPU 长期 P95 在 60% 附近定为健康水位，高于 70% 连续两周就触发扩容评估——"有数字、有阈值、有动作"的容量规则，比"感觉快不够了"的拍脑袋文化可靠得多。

追问链：

• 迭问1：容量规划用 P95 还是峰值？ → 答：看资源类型：CPU 看P95——CPU 短时峰值可以靠超卖和弹性消化，按峰值配是浪费；内存和磁盘看峰值/上限——内存是不能压缩的硬资源，超了就是 OOM，磁盘有明确的满点——这两个要按峰值加安全余量配；网络带宽介于两者之间（可限流但影响体验）。一句话："弹性资源看分位、刚性资源看上限"——把资源性质分清楚，规划口径就不会错，这也是我给业务方解释"为什么 CPU 不按峰值买"的标准答案。

7.39 告警规则的测试与版本化 【理解】

标准回答： 告警规则也是代码，也要有质量流程——我的三条实践。规则测试：新规则上线前用 PromQL 在 Web UI 里直接跑 expr，用真实数据验证"它能触发吗、触发范围对不对"——比如 CPU 85% 的规则，先查当前有多少节点在阈值之上，确认不会一上线就告警风暴；再人为制造条件（压测或调低阈值）验证触发链路（7.9 的演练思想用在规则上）。规则版本化：rules 文件进 git，改动走评审——重点审两件事：expr 的正确性（标签过滤对不对、窗口合理吗）和通知策略（severity 定级对吗、发给谁）；线上 prometheus.yml 的 rule_files 指向 git 检出目录，发布即"拉取 + reload"（Prometheus 热加载规则：kill -HUP 或 POST /-/reload）。规则台账：一张表记录每条规则的"名称、expr、级别、负责人、最近一次真实触发时间"——半年没真响过的规则进入待删评审。这三条让告警体系保持"每条规则都有存在理由"的健康状态，是我从"告警越来越多人越来越麻"的反面教训里提炼的治理方法。

追问链：

• 迭问1：Prometheus 怎么热加载规则，不重启服务？ → 答：两个方式：给进程发 SIGHUP（kill -HUP $(pgrep prometheus)）或启动时开了 --web.enable-lifecycle 后 curl -X POST http://localhost:9090/-/reload——两者都会重读配置和规则文件，语法错误时保留旧配置并在日志报错（和 Nginx reload 的防御行为同款设计）。我们的规则变更流程就是"改文件 → curl reload → Alerts 页确认规则加载 → 观察一轮"——全程不中断采集，这是 Prometheus 运维友好的一个点。

7.40 从监控到 AIOps：我的演进路线 【了解】

标准回答： 被问"你对监控/运维的下一步怎么看"，我的答案结合了自己的 AI 实践（项目三）。AIOps 在监控域的落地点我按成熟度排三档。已在做的：告警聚合降噪（Alertmanager 分组抑制就是最朴素的形态）、容量预测（predict_linear 的线性外推——7.20）、知识库支撑排障——我们公司的 RAG 知识库（阿里云百炼 + Cherry Studio 搭建）已经导入运维文档，排障时"告警现象 + 处置 SOP"的检索问答是新同事的效率倍增器，这是我亲手落地的"AIOps 最小闭环"。可以做的：告警根因关联（按拓扑把告警聚类成事件）、异常检测（对指标做无阈值异常识别，补静态阈值的盲区）——需要指标质量和数据积累到位。远期的：故障自愈闭环（检测 → 诊断 → 执行预案 → 验证），必须建立在"预案 SOP 化 + 操作可审计"之上（7.32 的文档化是它的地基）。我的立场：AIOps 不是买工具，是"数据 → 规则 → 文档 → 自动化"逐层爬楼梯——我三年走完了数据到文档两层，AI 知识库是第四层的起跑，这是我简历上 AI 项目和运维主线交汇的地方，也是我的差异化。

追问链：

• 迭问1：你的 RAG 知识库怎么服务运维场景的？ → 答：具体做法：把公司的部署指南、避坑清单、运维规范、历史故障复盘导入知识库（文档切分加向量化，百炼的模型做问答）；使用场景两个——新员工/新人查询"这个告警怎么处理"直接得到带出处的答案（RAG 的引用特性让答案可溯源，不会瞎编），售前快速检索方案细节。效果：重复咨询明显减少、新人上手周期缩短。我的理解：RAG 本质是"把组织的隐性经验变成可检索资产"，运维 SOP 是最适合 RAG 化的内容之一——因为它天然是"问题 → 答案"结构。这个实践让我聊 AIOps 不是概念，是有真东西的。

7.41 本章案例

• 【真实项目】移动云监控体系混合部署（STAR）：背景是生产 K8s 集群上线必须有监控配套，且内网环境镜像和软件源受限。任务是我负责监控方案选型与部署。行动：设计混合部署——独立监控节点（4C8G）二进制部署 Prometheus + Grafana（apt 装，不占集群资源、与集群故障隔离），集群内部署 kube-state-metrics（Deployment 加 NodePort 30080 暴露、复用内置 view 只读角色做 RBAC 绑定），全节点 apt 安装 prometheus-node-exporter（内网仓库无镜像的等价替代，9100 指标完全兼容）；配置三个抓取 job（node-exporter 六台、kube-state-metrics、apiserver 走 CLB VIP），Grafana 配数据源导 Node Exporter 和 K8s 大盘。结果：大盘覆盖节点、控制平面、集群对象三层指标，部署过程三个坑（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 Server/Agent/Proxy 完整架构，配置 Web 场景监测、触发器与动作联动，实验跨网段的 Proxy 分层采集方案。这个实验让我理解了 Zabbix 与 Prometheus 的场景分界——答对比题时我两边都能讲内行话，而不是只会贬低没用过的工具。
• 【经典故障】Zabbix 历史数据爆库（课程八股案例）：现象是 Zabbix 的 history 表按采集粒度无限堆积，MySQL 数据盘占满、Web 界面卡顿。处理：按时间 DELETE 过期历史数据加 OPTIMIZE TABLE 回收空间；长期方案是配置 Housekeeper 保留策略、用趋势表（trend）聚合替代长期明细。这个案例的教学点是"监控系统自己也要被容量规划"——监控存储不设上限，监控系统就是下一个故障源；我在移动云给 Prometheus 配 retention、给 journald 配限额，都是同一条原则的落地。

7.42 章末自测清单

1. Prometheus 六大组件？ → Server、Exporter、Pushgateway、Alertmanager、Web UI、Rules。
2. pull 模型三大好处？ → 采集端可控、目标状态天然感知（up）、配服务发现适应动态环境。
3. 四大指标类型一句话？ → Counter 只增、Gauge 可变、Histogram 分桶可聚合、Summary 客户端算分位数。
4. CPU 使用率 PromQL？ → 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)。
5. rate() 能用在 Gauge 上吗？ → 不能，只用于 Counter。
6. static 和 kubernetes_sd 怎么选？ → 小规模固定拓扑 static；动态扩缩集群 kubernetes_sd + relabel。
7. node_exporter 与 kube-state-metrics 一句话区别？ → 前者看机器资源用量，后者看 K8s 对象状态。
8. Pod CPU 使用率从哪来？ → kubelet 内置 cAdvisor（metrics-server 也从 kubelet 汇总）。
9. Alertmanager 三大降噪机制？ → 分组、抑制、静默。
10. 告警规则里 for 的作用？ → 持续满足才触发，防抖动。
11. Zabbix 和 Prometheus 场景分界？ → 传统静态 IT 用 Zabbix，云原生动态环境用 Prometheus。
12. 黄金指标四件套？ → 延迟、流量、错误、饱和度。
13. 可观测性三支柱？ → 指标、日志、链路。
14. 高基数问题是什么？ → 无界标签导致时间序列爆炸，无界信息放日志不放指标。
15. 你们监控的采集周期与理由？ → 15s，实时性与存储的平衡点。
16. Grafana 和 Kuboard 分工？ → Grafana 管指标可视化，Kuboard 管资源操作与权限审计，Kuboard 可对接 Prometheus 看图。
17. SLI/SLO/SLA？ → SLI 量化指标、SLO 目标值、SLA 对外承诺；我们控制平面 99.99% 是设计目标口径。