运维常见题-Prometheus监控

2026-07-10 2026-08-25 约 4200 字预计阅读 20 分钟

本文所引用的核心资料与数据，均由 DeepSeek V4 Flash 辅助生成。为确保内容的可靠性，笔者已对大部分关键论点进行了人工复核与校验。但鉴于大模型的固有局限，本文仍可能存在认知偏差或未尽准确之处。若您在阅读中发现存疑或矛盾之处，欢迎反馈讨论，笔者将及时核实与修正。

🤔 Prometheus 有哪些核心组件及其作用？

Prometheus 核心组件：①Prometheus Server（主服务：抓取/存储/查询/告警规则）②exporter（指标采集器）③Pushgateway（短任务指标汇聚）④Alertmanager（告警处理）⑤Service Discovery（服务发现）+ 可视化（Grafana）。核心是拉取（Pull）模型：Server 主动从 exporter 拉取指标。
- Prometheus Server（主服务）
  - 指标抓取（Scraping）：按间隔（scrape_interval）从 exporter 拉取指标
  - 存储：时序数据库（TSDB），本地磁盘存储指标
  - 查询：PromQL 查询语言、promtool 工具
  - 告警规则：内置规则评估（rules），产生告警发送给 Alertmanager
  - 核心：retrieval（抓取）、TSDB（存储）、promql（查询）、rule engine（规则）
- Exporter（采集器）
  - 运行在被监控目标上，把指标暴露成 HTTP 端点（/metrics）
  - 常见：node_exporter（主机）、mysqld_exporter、nginx_exporter、blackbox_exporter 等
  - Server 通过 HTTP 拉取 exporter 暴露的指标
- Pushgateway（推送网关）
  - 用于"短生命周期任务"（批处理/定时任务）推送指标（因任务结束时 exporter 已消亡，无法被 Pull）
  - 任务执行时把指标 Push 到 Pushgateway，Prometheus 再拉取
- Alertmanager（告警管理）
  - 接收 Prometheus 推送的告警，做去重、分组、抑制、静默
  - 通知到多种渠道（邮箱/钉钉/企业微信/Slack）
- Service Discovery（服务发现）
  - 自动发现采集目标（文件、Consul、K8s、云），替代手工配置目标
  - 配合 relabel_configs 动态筛选目标
- Grafana（可视化，生态组件）
  - 数据可视化面板（非 Prometheus 自带，常搭配使用）
  - 通过 Prometheus 数据源展示监控图表
协助记忆
- 核心四件套："Server（抓存储查）+ exporter（采集）+ Alertmanager（告警）+ Pushgateway（短任务）"。
- 数据流："exporter 暴露 /metrics → Server 拉取 → TSDB 存储 → PromQL 查询/规则 → Alertmanager 告警 → Grafana 展示"。
进阶思考
- 为什么 Pushgateway 是"补丁"而不是主流？
  - Prometheus 设计是 Pull 模型（Server 知道目标、可控制抓取）。Pushgateway 是给"无法被 Pull“的短任务（批处理）用的：任务结束进程就没了，无法被拉。但 Pushgateway 也引入风险（Single Point、指标 TTL）：任务挂了指标还在（陈旧），需注意清理。
- Exporter 和被监控对象是什么关系？
  - Exporter 是"翻译官”：把被监控对象的信息（系统状态/应用指标）翻译成 Prometheus 能理解的 /metrics 格式。被监控对象自身的监控数据格式五花八门，exporter 统一转成 Prometheus 指标格式。
- Alertmanager 和 Prometheus 的告警分工？
  - Prometheus 负责"评估规则"（指标值触发阈值 → 生成告警）；Alertmanager 负责"告警处理"（去重/分组/通知渠道）。告警从 Prometheus 发往 Alertmanager，由 Alertmanager 统一管理和发送。

扩展信息

架构示意图：

1
2
3
目标(Exporter) → Prometheus Server → Alertmanager → 通知渠道
                       ↓
                 TSDB → PromQL → Grafana

核心内部模块：retrieval（抓取）、tsdb（存储）、promql（查询）、rule（规则）、discovery（发现）、notifier（通知）

🤔 Prometheus 有哪些数据指标类型及其应用场景？

Prometheus 4 种指标类型：Counter（计数器，只增不减）、Gauge（仪表盘，可增减）、Histogram（直方图，分布统计）、Summary（摘要，分位数）。应用：Counter 看累计量（请求数/错误数），Gauge 看当前值（CPU/连接数），Histogram/Summary 看延迟分布（P99 等）。

Counter（计数器）
- 特点：只增不减（重启归零），累计值
- 适用：请求总数、错误数、字节数（累计型指标）
- 查询：用 rate() 算速率（每秒增量）
- 例子：http_requests_total、process_cpu_seconds_total
Gauge（仪表盘）
- 特点：可增可减，反映当前值（瞬时值）
- 适用：CPU 使用率、内存使用、连接数、温度（状态型指标）
- 查询：直接取值，可用 min/max/avg 聚合
- 例子：node_load1（负载）、node_memory_MemFree_bytes、node_network_up
Histogram（直方图）
- 特点：累积桶（bucket）统计分布（如 ≤0.1s 多少、≤0.5s 多少），可算分位数（histogram_quantile）
- 适用：请求延迟分布、响应大小分布
- 查询：histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])) 算 P99
- 例子：http_request_duration_seconds_bucket、_sum、_count
Summary（摘要）
- 特点：客户端算好的分位数（φ 分位数直接暴露），适合已知分位的场景
- 适用：服务端算好的延迟分位数（如 {quantile="0.99"}）
- 与 Histogram 区别：Summary 客户端计算分位（不可聚合）；Histogram 服务端算（可聚合，支持多标签维度）
- 例子：http_request_duration_seconds{quantile="0.99"}

选型（何时用哪种）

指标	特点	典型场景
`Counter`	只增（累计）	请求数/错误数
`Gauge`	可增可减（瞬时）	CPU/内存/连接数
`Histogram`	桶分布（可聚合分位）	延迟分布（推荐）
`Summary`	客户端分位（不可聚合）	已知分位的延迟

协助记忆
- 四类型口诀："Counter 计数（只增）、Gauge 仪表（可变）、Histogram 分桶、Summary 摘要"。
- 延迟首选 Histogram（可聚合/多维度），旧系统用 Summary。
进阶思考
- Histogram 和 Summary 怎么选？
  - 需要"多标签/聚合分位数"（如按服务、按 URL 分别算 P99）用 Histogram（分位在 Prometheus 侧算，可聚合）；只需"单值分位"（固定 0.5/0.9/0.99）且不想存太多桶用 Summary（客户端算好）。现代推荐 Histogram（更灵活）。
- Counter 为什么常用 rate() 看？
  - Counter 是累计值（无限增长），看"速率"更有意义（rate() 转每秒增量 = QPS）。但绝对值也能用（如 increase() 看区间增量、累计总量对比），并非只有 rate 一种用法。
- Gauge 可以算速率吗？
  - 可以但语义不同：Gauge 是瞬时值，rate() 也能算变化速率（但更适合用 delta）。Counter 适合 rate（累计派生速率），Gauge 直接看当前值或变化量。
扩展信息
- 指标命名规范：<类型>_<单位>_<描述>（如 http_requests_total）、_total 后缀（Counter）、_bucket/_sum/_count（Histogram）
- 相关函数：rate()、irate()、increase()（Counter）；histogram_quantile()（Histogram）；min/max/avg（Gauge）

🤔 Prometheus 支持哪些服务发现方式？

Prometheus 服务发现（Service Discovery）用于自动发现采集目标：支持文件（file_sd）、Consul、Kubernetes、云（AWS/Azure/GCP）、DNS（dns_sd）、EC2、K8s 等。核心价值：动态环境（容器/云）中目标自动变化，无需手工维护 target 列表。

服务发现方式列表
- 文件发现（file_sd）：从文件中动态读目标列表（简单通用，可与 CMDB/脚本结合）
- Kubernetes 发现（kubernetes_sd）：按 Pod/Service/Ingress/Node/Endpoint 发现 K8s 目标（云原生核心）
- Consul 发现（consul_sd）：从 Consul 读取服务注册信息
- 云发现：ec2_sd（AWS）、Azure、GCP——按云实例发现
- DNS 发现（dns_sd）：通过 DNS 记录（SRV/A/AAAA）发现
- 其他：Consul、Eureka、Zookeeper/Mesos（注：zookeeper_sd/mesos_sd 在 Prometheus 3.0 已移除，仅 2.x 可用）
为什么服务发现重要（场景）
- 动态环境：K8s 里 Pod 频繁创建/销毁（伸缩/发布），IP 变化——手工配置不可能
- 大规模：上千台主机，手工维护 target 不可行
- 自动化：新实例自动纳入监控，销毁自动移除
- 配合 relabel：服务发现找到目标后，用 relabel 打标签/筛选

K8s 服务发现（最常见的一种）

1
2
3
4
5
6
7
scrape_configs:
  - job_name: kubernetes-pods
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      - source_labels: [__meta_kubernetes_pod_label_app]
        target_label: app

文件发现（file_sd，通用）

1
2
3
4
scrape_configs:
  - job_name: custom
    file_sd_configs:
      - files: ['/etc/prometheus/targets/*.json']

协助记忆
- 服务发现口诀：“文件（file_sd）、K8s（kubernetes_sd）、Consul、云、DNS”。
- 核心：“目标动态自动发现，配合 relabel 打标签筛选”。
进阶思考
- 服务发现和静态配置（static_configs）的区别？
  - 静态：手工写目标 IP 列表（适合固定目标，简单）。服务发现：自动获取（适合动态环境/大规模）。静态配置不会自动更新，服务发现在目标变化时自动维护。
- file_sd 为什么不那么"高大上"但很实用？
  - file_sd 从文件读目标：写个脚本/CMDB 导出 json 到文件，Prometheus 自动加载——简单、通用、不依赖具体注册中心。适合非 K8s 场景或与 CMDB 集成。
- 服务发现和 relabel_configs 怎么配合？
  - 服务发现找到目标（产生 __meta_* 元标签）→ relabel 用元标签筛选（只采某些）、重命名、打业务标签。流程：发现 → 筛选/打标（relabel）→ 抓取。
扩展信息
- 发现目标与 __meta_ 标签：服务发现的元信息存在 __meta_* 标签（K8s: __meta_kubernetes_*；AWS: __meta_ec2_*），relabel 引用它们
- 常见 SD 配置：kubernetes_sd_configs（role: node/pod/service/endpoints）、ec2_sd_configs、consul_sd_configs、dns_sd_configs

🤔 Pushgateway 的使用场景是什么？它解决了什么问题？

Pushgateway（推送网关）解决"短生命周期任务无法被 Pull 采集"的问题：批处理/定时任务执行时自己把指标 Push 到 Pushgateway，Prometheus 再从 Pushgateway 拉取。场景：一次性/定时批处理、任务无法暴露 /metrics 端点、指标度量在任务结束时完成。核心：把"无法被拉"的任务指标"中转"。
- 解决的场景（使用场景）
  - 短生命周期任务：批处理/定时任务（如每天跑一次的报表、数据同步），执行期间短暂，无法被 Prometheus 按间隔拉取（任务结束监就没了）
  - 任务完成才出指标：如"本次任务处理了多少条、耗时多少"，只有任务结束时才知道，任务结束 exporter 已停
  - 无法暴露端点：脚本/一次性程序不便起 HTTP 服务暴露 /metrics
  - 典型：cron 批处理、CI/CD 任务、一次性数据迁移
- 工作原理
  1 2
  短任务(脚本) → 执行完成 → Push 指标到 Pushgateway → Prometheus 按间隔从 Pushgateway 拉取指标（Pushgateway 是"目标"）
  - 脚本：echo 'job_done 1' | curl --data-binary @- http://pushgateway:9091/metrics/job/xxx
  - Pushgateway 聚合：把所有推送的短任务指标集中汇聚（按 job/instance/分组键分组存储），Prometheus 拉它
- 解决的问题
  - 让 Prometheus 的 Pull 模型也能覆盖"不能持续运行"的任务
  - 任务指标集中在一个"常驻的汇聚点"（Pushgateway）被拉取
- 注意/坑
  - 指标陈旧：任务挂了/没新数据，Pushgateway 里的旧指标还在（Prometheus 以为任务正常）→ Pushgateway 无内置 TTL/自动清理，需任务结束主动调 DELETE API 或外部脚本清理
  - 单点：Pushgateway 是 SPOF（都推它）
  - 非通用：长时间运行的服务不该用 Pushgateway（应直接暴露指标被拉）
  - 安全：Pushgateway 无认证，需限制访问
协助记忆
- Pushgateway = “短任务的指标信箱”：任务跑完把指标投进信箱，Prometheus 定期来取。
- 场景口诀：“批处理、短任务、任务结束出指标”。
进阶思考
- 为什么"长时间运行的服务不用 Pushgateway"？
  - 常驻服务（Web/数据库）可以被 Prometheus 直接拉取（Pull），用 Pushgateway 反而多一跳、引入单点和指标陈旧问题。Pushgateway 是"补丁"，给无法被 Pull 的短任务用。
- Prometheus 什么时候用 Push？
  - 标准做法主要是 Pull；Push 仅指短任务经 Pushgateway（间接 Push）。更广泛地，Prometheus 体系里 Push 用于短生命周期任务，长时间服务保持 Pull。
- Pushgateway 的"指标陈旧"问题怎么解决？
  - ①任务结束时主动删除指标（-X DELETE）②外部脚本/工具定期清理 ③Prometheus 侧用 absent() 检测任务是否有新数据。注意：Pushgateway 官方明确不做内置 TTL（指标不会被自动清理），所以清理靠任务侧/外部。

扩展信息

Pushgateway 部署：独立进程/容器，暴露 9091 端口

推送示例：

1
2
echo "cron_job_duration_seconds 12.3" | curl -X POST --data-binary @- http://pushgw:9091/metrics/job/sync
# 删除：curl -X DELETE http://pushgw:9091/metrics/job/sync

Prometheus 侧：scrape_configs 里加 job: pushgateway（target 指向它）

🤔 什么时候会用 relabel_configs？

relabel_configs（重打标签）用于"在抓取前对发现的目标做标签/筛选处理"：①筛选目标（只抓某类）②重命名/添加标签（打业务标签）③从元数据提取标签（__meta_* → 业务标签）④修改抓取 URL/端口。典型：K8s 服务发现后按 Pod 标签筛选、把 __meta_kubernetes_* 转成业务标签、按 job/环境打标签。

是什么（定义）
- 抓取前的"目标预处理"：对从服务发现/静态配置得到的目标做筛选和标签操作
- 作用于"目标级别"（target relabeling），在抓取前生效
- 另一个 metric_relabel_configs：作用于"指标级别"（抓取到的指标再处理）
典型使用场景
- 筛选目标：keep/drop 只保留/丢弃某些目标（如只监控打了 app=web 标签的 Pod）
- 元信息转业务标签：把服务发现的 __meta_* 标签转成业务标签（如 __meta_kubernetes_pod_label_app_kubernetes_io_name → app）
- 打静态标签：给该 job 的所有目标加固定标签（如 env=prod）
- 修改抓取配置：改 __address__（目标地址）、__scheme__（http/https）、__metrics_path__（路径）
- K8s 多角色发现：同一 job 按 label 区分采集不同角色

示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
relabel_configs:
  # 只保留 app=web 的 Pod
  - source_labels: [__meta_kubernetes_pod_label_app]
    regex: web
    action: keep
  # 把元标签转成 app 标签
  - source_labels: [__meta_kubernetes_pod_label_app]
    target_label: app
  # 加固定标签
  - target_label: env
    replacement: prod

action 类型
- keep：保留匹配的目标（不匹配丢弃）
- drop：丢弃匹配的目标
- labelmap：把源标签（含 __meta_）复制/改成新标签
- replace（默认）：替换标签值（改值/改名）
- labeldrop/labelkeep：删除/保留某标签

协助记忆
- relabel = “抓取前给目标"整容 + 筛选”：keep/drop 筛选，labelmap/replace 打标，__meta_ → 业务标签。
- action 口诀：“keep 留、drop 丢、replace 换、labelmap 映射”。
进阶思考
- relabel_configs 和 metric_relabel_configs 区别？
  - relabel_configs：抓取前处理目标（筛选目标/打目标标签）；metric_relabel_configs：抓取后处理指标（筛选指标/给指标改名/删高基数标签）。两者作用对象不同（目标 vs 指标）。
- keep 和 drop 怎么用（默认效果）？
  - keep：正则匹配的保留（没匹配的丢弃）；drop：正则匹配的丢弃（没匹配的保留）。场景：只想要某类目标用 keep；排除某类用 drop。
- 为什么要"控制标签基数"（metric_relabel 场景）？
  - 高基数标签（如请求 URL/用户 ID 作标签）会让指标组合爆炸、存储膨胀、查询慢。metric_relabel_configs 可在抓取时删除高基数标签/丢弃过高样本，控制数据量；聚合要靠 recording rule。这是大规模 Prometheus 必备优化。
扩展信息
- __meta_ 标签例：K8s __meta_kubernetes_pod_label_<label>、__meta_kubernetes_namespace；EC2 __meta_ec2_instance_id
- 内置标签：__address__（抓取地址）、__scheme__、__metrics_path__、instance（默认目标标签）
- 常用 action：keep、drop、replace、labelmap、labeldrop、labelkeep

🤔 你都用过哪些 Exporter？

常用 Exporter：主机（node_exporter）、数据库（mysqld_exporter、postgres_exporter、redis_exporter、mongodb_exporter）、中间件（nginx_exporter、kafka_exporter、rabbitmq_exporter）、网络（blackbox_exporter ICMP/TCP/HTTP 探活、snmp_exporter）、容器/K8s（cadvisor、kube-state-metrics、process_exporter 进程）等。核心：按监控对象选对应 exporter，暴露 /metrics 供 Prometheus 拉取。
- 主机/系统类
  - node_exporter：主机基础指标（CPU/内存/磁盘/网络/文件系统）——最常用
  - process_exporter：进程监控
  - windows_exporter：Windows 主机
  - ipmi_exporter：硬件监控（IPMI）
  - smartmon_exporter：磁盘 SMART
- 数据库类
  - mysqld_exporter：MySQL 指标（连接数/QPS/慢查询/主从）
  - postgres_exporter：PostgreSQL
  - redis_exporter：Redis（内存/命中率/客户端/持久化）
  - mongodb_exporter：MongoDB
- 中间件/应用类
  - nginx_exporter：Nginx（连接/请求/状态）
  - kafka_exporter：Kafka（分区/消费者/滞压）
  - rabbitmq_exporter：RabbitMQ
  - jvm_exporter → 正确命名是 jmx_exporter（prometheus/jmx_exporter，支持 javaagent），监控 Java 应用 JVM
  - 应用自定义：业务代码用 client library 暴露指标
- 网络/探活类
  - blackbox_exporter：黑盒探活（HTTP/TCP/ICMP/DNS）——测"服务通不通"
  - snmp_exporter：SNMP 设备（网络设备/打印机）
- 容器/K8s 类
  - cadvisor：容器资源指标（CPU/内存）——现代 K8s 中 cAdvisor 已内嵌于 kubelet（暴露在 :10250/metrics/cadvisor），独立部署时才是 8080 端口
  - kube-state-metrics：K8s 对象状态（Pod/Deployment 等）
  - kubelet 内置 /metrics：K8s 节点/容器基础
- Web 站点类
  - haproxy_exporter、coredns_exporter、etcd_exporter 等
- 选 Exporter 思路（怎么选）
  - 官方/社区先找现成（GitHub exporterhub.io）
  - 没有现成的：用 blackbox_exporter（探活）/snmp_exporter（硬件）/写自定义 exporter（client library）
协助记忆
- Exporter 口诀：“主机 node、数据库 mysqld、中间件 nginx/redis、探活 blackbox、K8s cadvisor/kube-state”。
- 找不到现成：先 blackbox/snmp，再考虑自写。
进阶思考
- node_exporter 和 cadvisor 有什么区别？
  - node_exporter：主机层（OS 指标：CPU/内存/磁盘），每个节点一个。cadvisor：容器层（容器指标），K8s 里收集每个容器的资源。监控"主机"用 node，监控"容器"用 cadvisor。
- blackbox_exporter 为什么特殊？
  - 它是"主动探测"（发 HTTP/TCP/ICMP 请求测目标通不通/响应时间），不需要目标装 exporter——适合测公网服务/URL/端口。生产里监控"外部依赖是否可达"用它。
- 自定义业务指标的 exporter 怎么写？
  - 用官方 client library（prometheus/client_golang、Python、Java）在应用里注册指标并暴露 /metrics；或写独立 exporter 调第三方 API 转指标。核心：指标命名/类型规范 + 暴露 HTTP。
扩展信息
- Exporter 查找：exporterhub.io、GitHub 搜索 <对象> exporter、官方文档列表
- 常用 exporter 端口：node 9100、mysqld 9104、redis 9121、nginx 9113、blackbox 9115、cadvisor 8080、kube-state-metrics 8080
- 统一思路：<对象>_exporter 命名规律（<对象> 即被监控对象）

🤔 你用过 Prometheus 哪些内置函数？

Prometheus 常用内置函数：速率类（rate/irate/increase）、聚合类（sum/avg/max/min/count/topk/quantile）、数学类（abs/ceil/floor/round）、时间类（time/timestamp）、直方图（histogram_quantile）、状态类（absent）、标签类（label_replace/label_join）。核心：rate 算速率、histogram_quantile 算延迟分位、sum by 聚合。注：up 是内置指标（目标在线状态）而非函数。

速率/增量类（Counter 用）
- rate()：区间内每秒平均速率（如 rate(http_requests_total[5m]) = QPS）——平滑，适合长期趋势
- irate()：区间内最后两个样本的瞬时速率——毛刺/突发行（比 rate 敏感）
- increase()：区间内总增量（如 5 分钟请求增量）
- delta()：Gauge 区间差值
聚合类
- sum/avg/max/min/count（求和/平均/最大/最小/计数）
- topk(n)/bottomk(n)（前 N/后 N）
- quantile(q)（聚合分位）、count_values（按值分布计数）
- sum by (label)：按标签分组聚合（如 sum by (instance) (rate(http_requests[5m]))）
- sum without (label)：除指定标签外聚合
直方图类
- histogram_quantile(φ, rate(hist_bucket[5m]))：从 Histogram 桶算分位数（P99 等）
- histogram_count()/histogram_sum()（2.40+，主要为原生直方图 native histogram 设计；经典直方图常规仍用 _count/_sum 序列）
状态/其他类
- up（内置指标：目标是否在线 0/1，不是函数）
- absent()（指标不存在返回 1——可用来检测任务没新数据）
- absent_over_time()（区间内无数据返回 1）
- label_replace()（改标签值/名）、label_join()（合并标签）
- time()（当前时间）、timestamp()（样本时间戳）
- clamp_max/clamp_min（限制范围）、predict_linear（线性预测）；比较用运算符（>/>=/==）

常用组合示例

1
2
3
4
5
6
# CPU 使用率
100 - avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100
# 请求 QPS 按实例分
sum by (instance) (rate(http_requests_total[5m]))
# P99 延迟
histogram_quantile(0.99, sum by (le) (rate(http_request_duration_bucket[5m])))

协助记忆
- 函数口诀：“速率 rate/irate、聚合 sum by、分位 histogram_quantile、状态 up/absent"。
- 常用三步："rate 算速率 → sum by 聚合 → topk/quantile 筛选”。
进阶思考
- rate 和 irate 区别/怎么选？
  - rate：整个区间平均（平滑，适合看长期趋势/告警，抗毛刺）。irate：最新两个点算瞬时速率（敏感，适合看尖峰/瞬时异常）。长期趋势用 rate，抓瞬时突刺用 irate。
- sum by 和 sum without 的区别？
  - sum by (label)：按指定标签分组（其他标签丢弃）；sum without (label)：排除指定标签聚合（其他保留）。结果区别在保留哪些维度——by 是"只要这几个"，without 是"去掉这几个"。
- 为什么延迟分位要用 histogram_quantile 而不是直接用值？
  - Histogram 存的是桶计数（≤0.1/0.5/1s 各多少），Prometheus 通过桶分布近似估算分位数（线性插值）——能看到 P50/P95/P99 等任意分位，且可聚合。直接存每请求延迟（Summary）不可聚合且数据量大。
扩展信息
- 告警常用表达式：rate() + 阈值、up == 0、absent()（无数据告警）
- predic_promql 工具：promtool query、Prometheus UI 的 Graph/Console 调试

🤔 Prometheus 存储机制是怎么样的？

Prometheus 存储是"本地磁盘时序数据库（TSDB）"：按 2 小时一个 block（块）写入，内存（WAL）+ 持久化，支持数据压缩、采样与保留策略（retention_time）。核心：block 结构（data/ 目录）、WAL 预写日志、mmap、块合并（compact）、按时间/标签索引查询。
- 整体架构（本地 TSDB）
  - Prometheus 把采集的时序数据存储到本地磁盘（默认 data/ 目录）
  - 结构：按时间段分块（block）存储，每个 block 内按标签/指纹索引
  - 无外部依赖（单机即可），但本地存储限制（不适合跨机久存/大容量）
- 核心机制
  - Block（块）：数据按 2 小时切块（01xxxx 目录），含样本/索引/元数据
  - WAL（预写日志）：新数据先写内存 + WAL（崩溃恢复），2 小时后落盘成 block
  - Head block（内存块）：最近 2 小时数据在内存（可查询），定期落盘；head 溢出 chunk 用 mmap 存 data/chunks_head
  - Compact（压缩合并）：旧的 block 自动合并（减少文件数/存储）
  - 保留策略：--storage.tsdb.retention.time（默认 15 天）自动删除旧 block
  - 注：降采样（downsampling）非原生支持，由 Thanos Compactor/VictoriaMetrics 等外部组件提供
- 数据存储细节
  - 数据格式：<时间戳, 值> + 标签（label）索引（倒排索引加速查询）
  - mmap：读优化（内存映射）
  - 查询：按标签选择器 + 时间范围定位 block
- 存储命令/查看
  1 2 3
  ls data/ # 查看 block 目录 promtool tsdb list # 列出 block promtool tsdb analyze # 分析存储（label 基数/大小）
- 存储限制（为什么不适合长期）
  - 单机本地磁盘：不支持集群水平扩展（原生）
  - 高基数（many unique label 组合）→ 存储/内存膨胀
  - 长期留存需要大量磁盘 + 压缩
  - 数据持久性：单机磁盘故障丢数据（无副本）
协助记忆
- 存储口诀：“2 小时一个块，WAL 预写内存先，落盘 block 压缩合并，retention 自动删老”。
- 核心：“本地 TSDB + block 结构 + WAL + 保留策略”。
进阶思考
- 为什么新数据先写内存 + WAL 而不是直接落盘？
  - 性能：时序写入频繁，直接落盘慢；先写内存（查询快）再定期批量落盘。WAL 保证崩溃不丢数据（重放 WAL 恢复）。这是时序数据库的常规设计。
- 为什么 2 小时一个 block？
  - 平衡：块太小文件碎片多，太大合并/查询变慢。2 小时是 Prometheus 选择的折中（减少文件数、便于合并和 retention 删除）。
- 数据保留（retention）怎么调？
  - --storage.tsdb.retention.time（如 90d）/--storage.tsdb.retention.size（按容量）。默认 15 天。注意：时间与大小同时设时先达者触发删除。
扩展信息
- 文件布局：data/01xxxx/（block：chunks/index/meta.json）、data/wal/（预写日志）、data/chunks_head（内存溢出 chunk）
- 远端存储（remote write）：Prometheus 可 remote_write 到外部存储（Thanos/VictoriaMetrics/云），突破本地限制
- 快照：/api/v1/admin/tsdb/snapshot（手动快照备份）

🤔 Prometheus 为什么不适合长期存储？

Prometheus 原生不适合长期存储的原因：①本地磁盘单机（无集群/无副本，容量与可用性受限）②高基数导致存储/内存膨胀 ③数据量随留存时间线性增长（15 天→长期，磁盘巨大）④查询长周期变慢 ⑤无多副本/跨机房容灾。解决：remote_write 到外部存储（Thanos/VictoriaMetrics/云 TSDB）或联邦。
- 原因一：本地磁盘单机
  - Prometheus 默认数据存本地磁盘（单机），无原生集群/水平扩展
  - 磁盘容量有限（长期数据需要大量空间）
  - 无副本（磁盘故障丢数据）、无跨机房容灾
- 原因二：数据量与留存线性增长
  - 数据按保留期保留，留得越久数据越多（磁盘线性增长）
  - 默认 15 天，若留 1 年需要 ~24 倍空间
  - 高采样频率 + 多目标 → 数据量大
- 原因三：高基数（cardinality）问题
  - 高基数标签（URL/用户 ID）导致指标组合爆炸，存储/内存/查询成本剧增
  - 长期存储高基数数据几乎不可行
- 原因四：查询性能
  - 长时间范围的查询（如 1 年趋势）要跨大量 block 扫描，变慢
  - 内存要求随数据范围增长
- 原因五：运维/容灾
  - 数据备份/恢复无内置机制（要手动处理）
  - 单点（存储不可扩展/不可替换）
- 解决方案（如何长期存储）
  - remote_write 到外部存储：Thanos（对象存储 S3/GCS）、VictoriaMetrics、云 TSDB——存外部、无限扩展
  - Thanos：Prometheus + 对象存储（极致扩展 + 长期留存 + 高可用）
  - VictoriaMetrics：兼容 Prometheus 的时序库（存储压缩更好、支持长期）
  - 联邦（Federation）：层级聚合计（但长期存储仍需外部）
协助记忆
- 不适合长期：“单机磁盘（容量/可用性）、数据线性增长、高基数膨胀、查询变慢、无容灾”。
- 解药口诀：“remote_write 到 Thanos/VictoriaMetrics/云”。
进阶思考
- Thanos 和 VictoriaMetrics 怎么解决"长期存储"？
  - Thanos：把数据 push 到对象存储（S3）——容量近乎无限、跨集群聚合；VictoriaMetrics：兼容 Prometheus API 的高效库 + 更好的压缩（长期留存成本低）。两者都是"Prometheus 的长期存储后端"。
- 为什么"高基数"是 Prometheus 的软肋？
  - Prometheus 每个唯一"指标+标签组合"（series）都要建索引和存储序列。高基数（如 path 直接做标签）导致 series 爆炸：存储/内存/查询全炸。所以生产必须控制标签基数（relabel 删除、避免动态标签）。
- 本地存储能提升（不改架构）吗？
  - 有限：加大磁盘、增大 retention、优化采集间隔（降采样）、控制基数。但"单机 + 本地"的容量天花板仍在，真正长期存储必须 external（remote_write）。
扩展信息
- remote_write 配置：Prometheus 里加 remote_write: - url: http://victoria:8428/api/v1/write
- 长期存储方案对比：Thanos（对象存储，功能全）、VictoriaMetrics（高效压缩，单点简单）、Mimir/Cortex（多租户云原生）、云 TSDB（托管）

🤔 Prometheus 出现 OOM 的常见原因及解决方案？

Prometheus OOM（Out of Memory）常见原因：①高基数（太多的唯一标签组合 → series 膨胀 → 内存爆）②抓取数据量过大（target/指标过多）③查询过重（大范围/高基数查询占用内存）④内存参数未调（默认内存限制、chunks 数量）⑤head block/内存块过大。解决：控基数、优化抓取、限制查询、调 --storage.tsdb 参数、加内存/降采样。
- 常见原因
  - 高基数（最常见）：动态/高基数标签（URL、UserID、容器 ID 等做标签）→ series 爆炸 → 内存、存储、查询全爆
  - 抓取量大：target 多、指标多、抓取频繁（scrape_interval 小）
  - 查询过重：大范围、sum 没聚合、高基数查询（Prometheus 查询要载入 series 到内存）
  - 内存参数不当：GOGC/GOMEMLIMIT（Go 内存参数）未调优、容器内存限制不足；head block 过大（大量短时间数据在内存未落盘）
  - 注：--storage.tsdb.min-block-duration 仅测试/调试用途（生产不应修改，影响 compactor），不是内存调优项
  - 规则过多：告警规则/记录规则重（rule 评估载入大量数据）
- 排查思路
  - 看日志（OOM killer）//proc/PID/status 内存
  - promtool tsdb analyze：分析 cardiality（高基数标签）
  - Grafana 查看内存趋势、go_memstats 指标
  - 查询过重：看查询日志/重启后内存恢复
- 解决方案
  - 控制基数（治本）：relabel 删高基数标签、避免动态标签、聚合指标
  - 优化抓取：降抓取频率（scrape_interval）、只采必要指标（metric_relabel 过滤）、减少 target
  - 限制查询：查询加标签过滤/时间范围、记录规则（recording rule）预聚合常用查询
  - 调内存参数：容器内存限制加足（Go 1.19+ 用 GOMEMLIMIT 设内存上限更稳；GOGC 调大会内存升高、CPU 下降，调小相反）；--storage.tsdb.retention.size 控制容量删除
  - 架构优化：联邦/分片（多 Prometheus 分职责）、remote_write 分担、Thanos/VictoriaMetrics
  - 容量：加内存（简单但治标）
协助记忆
- OOM 口诀：“基数高（治本）、抓取多、查询重、参数未调”。
- 解法：“控基数 → 限抓取 → 限查询 → 调参数 → 分片/外部”。
进阶思考
- 为什么"高基数"会让 Prometheus OOM？
  - Prometheus 每个唯一 series（指标+标签组合）在内存中维护索引和 head block。高基数 = 海量 series = 内存（+存储 + 查询暂存）暴涨。1000 个 URL 标签 → 1000 倍的 series。这是 Prometheus 第一大坑。
- 怎么快速定位高基数？
  - promtool tsdb analyze（Top 标签值数）、查询 count(metric)；Grafana 建"series 数量趋势"面板。定位后用 relabel/metric_relabel 清理。
- OOM 只加内存能解决吗？
  - 治标：加内存让 Prometheus 暂时不崩。治本：减 series（控基数）、优化查询/抓取。数据量持续膨胀时加内存只是拖延，必须架构/数据优化。
扩展信息
- 相关参数：--storage.tsdb.retention.time、--storage.tsdb.min-block-duration、--storage.tsdb.wal-compression、容器 memory limit
- 工具：promtool tsdb analyze（基数分析）、Grafana Prometheus 自查面板

🤔 Prometheus 有哪些主流高可用方案？

Prometheus 高可用方案核心是"多副本 + 统一查询/存储"：①原生多副本（多 Prometheus 拉同一目标 + Alertmanager 集群去重告警）②Thanos（多 Prometheus + 对象存储 + 统一查询）③VictoriaMetrics（兼容库 + 复制/集群）④Mimir/Cortex（多租户云原生）⑤联邦（层级聚合）。核心：告警去重 + 数据冗余 + 统一查询。
- 方案一：原生高可用（多副本 + Alertmanager 去重）
  - 部署两套相同配置的 Prometheus 拉同一批目标（相同规则）——无需特殊 flag，就是多实例同配置
  - Alertmanager 集群模式（--cluster.peer，gossip 同步）+ alert fingerprint 去重：跨副本相同告警只发一次（分组 grouping 只是合并同类通知，不起去重作用）
  - 优点：简单（告警不重复）；缺点：数据各自独立（查询/存储无统一）
- 方案二：Thanos（最主流）
  - 多 Prometheus + Sidecar 上传对象存储（S3）+ Querier 统一查询
  - 优点：数据统一/长期留存/跨集群查询、Prometheus 可随意扩缩
  - 组成：Sidecar、Querier、Store、Compactor、Ruler
- 方案三：VictoriaMetrics（vmcluster/vmsingle）
  - 兼容 Prometheus API 的时序库，支持 -replicationFactor 复制、集群（vminsert/vmselect/vmstorage）
  - 更适合作为"后端存储"（remote_write），比 Thanos 部署简单、存储压缩好
- 方案四：Mimir / Cortex（云原生多租户）
  - 多租户 Prometheus 兼容方案（Grafana 的 Mimir、原 Cortex）
  - 适合"多团队/多集群统一监控平台"（数据统一、多租户隔离）
- 方案五：联邦（Federation）
  - 上级 Prometheus 从下级拉聚合指标（分层）
  - 作用：聚合/分级，不完全等于高可用（也有冗余作用）
- 选型考虑
  - 小规模/只需告警不重复：原生多副本
  - 需要统一查询/长期存储：Thanos
  - 追求简单高效/存储优：VictoriaMetrics
  - 多租户/云原生：Mimir/Cortex
协助记忆
- 高可用口诀：“原生多副本（告警去重）、Thanos（统一查询+长期）、VictoriaMetrics（简单高效）、Mimir（多租户）"。
- 核心：“数据冗余 + 告警去重 + 统一查询”。
进阶思考
- 为什么"多副本 + Alertmanager 去重"只是最小高可用？
  - 它解决了"告警不丢/不重复”（两个 Prometheus 都挂了才丢告警），但数据是两套独立存储：查询各自查、无统一视图、无长期留存。真正"数据高可用"需要 Thanos/Victoria 统一存储层。
- Thanos 和 VictoriaMetrics 怎么选？
  - Thanos：用对象存储（S3）+ 组件多（Sidecar/Querier/Store），功能全（跨集群/长期/降采样），适合需要统一查询和长期留存的中大型。VictoriaMetrics：单二进制/集群简单、压缩优、部署运维轻，适合中小型或当后端存储。
- 高可用和"可扩展/长期存储"是一回事吗？
  - 不完全是：高可用=数据不丢/查询可用（多副本）；扩展/长期=容量和留存（对象存储/外部库）。Thanos/Victoria 两者都解决（副本+扩展+长期），原生多副本只解决告警不重复。
扩展信息
- Thanos 组成：Sidecar（上传数据）、Querier（统一查询）、Store（对象存储读取）、Compactor（压缩/降采样）、Ruler（独立告警）
- VictoriaMetrics 集群：vminsert（写入）、vmselect（查询）、vmstorage（存储）
- Mimir：Grafana 的多租户时序平台（Cortex 继承者）

🤔 Thanos 实现高可用的核心原理是什么？

Thanos 实现高可用的核心原理：①多副本 Prometheus（各自采集，告警去重）②Sidecar 把每个 Prometheus 的本地时序数据上传到对象存储（S3），实现数据统一/长期留存 ③Querier 聚合查询多个 Prometheus + 对象存储，实现统一查询/跨集群 ④Compactor 压缩+降采样，Ruler 独立告警。核心：“多副本数据冗余 + 对象存储长期留存 + 统一查询层”。
- 核心原理拆解
  - 数据冗余（HA）：多个 Prometheus 副本拉同一批目标（各自有完整数据）——任一挂掉，另副本数据仍在
  - 统一存储（长期）：Sidecar 把各 Prometheus 的数据上传到对象存储（S3/GCS）——数据脱离单机，容量近无限 + 长期留存
  - 统一查询（全局视图）：Querier 对多副本 + 对象存储做聚合查询（去重、合并），一个 PromQL 查全部数据
  - 告警去重：多副本的 Alertmanager 集群（gossip 同步）通过 alert fingerprint 去重（同告警只通知一次）
- 高可用实现方式
  1 2 3 4 5
  Prom A(1副本) + Sidecar → 上传 S3 Prom B(2副本) + Sidecar → 上传 S3 ↓ Thanos Querier（统一查询：合并 A/B/S3）→ Grafana Alertmanager（集群去重）
  - 多副本：任何一个 Prometheus 挂了，历史数据/查询不受影响（由其他副本 + S3 兜底）；注：最近约 2 小时未上传的本地 block 若本机故障会丢失（Sidecar 上传有周期）
- 相比原生多副本的优势
  - 原生多副本：只解决"告警不重复"，数据各查各的
  - Thanos：数据统一（一个查询看全部）、长期留存（S3）、跨集群/跨机房聚合、Prometheus 可无损扩缩（新实例上传 S3）
协助记忆
- Thanos 高可用 = “副本（数据冗余）+ S3（长期留存）+ Querier（统一查询）+ 去重（告警不重复）"。
- 口诀：“Sidecar 上传、Querier 查询、Compactor 压缩、Ruler 告警”。
进阶思考
- 为什么"Prometheus + Sidecar + S3"能实现"无限扩展”？
  - 数据落 S3 后，本地 Prometheus 只是"采集器 + 短缓存"：磁盘/数据量不再限制（S3 承受），新加 Prometheus 实例只需上传 S3 即可被 Querier 查询到——解耦了"采集"和"存储"。
- Querier 查询会不会比原生慢？
  - 会稍慢（要拉多副本 + S3 Store，且做去重/合并），尤其全查 S3 时。优化：S3 数据做压缩/降采样（Compactor）、查询加限定时间/标签、Store/Querier 加缓存。
- Thanos 的告警去重和原生 Alertmanager 去重一样吗？
  - 机制相同（Alertmanager 分组去重），但 Thanos 有独立 Ruler 组件可统一管理告警规则（不依赖各 Prometheus 本地 rules）。
扩展信息
- Thanos 架构图：Sidecar（数据上传）、Querier（查询聚合）、Store（对象存储读取）、Compactor（压缩降采样）、Ruler（独立告警规则）、Receiver（可选，替代 Sidecar 的 Push）
- 部署：Thanos 组件各自独立可水平扩展；对象存储（S3/OSS/GCS/MinIO）作共享数据层

🤔 Thanos 有哪些核心组件及其作用？

Thanos 核心组件：①Sidecar（每个 Prometheus 旁的边车：上传本地数据到对象存储 + 查询本地数据）②Querier（统一查询：聚合多个 Prometheus/Store，去重）③Store（读取对象存储数据供查询）④Compactor（对象存储数据压缩/降采样/删除）⑤Ruler（独立告警规则评估）⑥Receiver（可选：接收 Push 数据再上传）。核心：Sidecar 上传 + Store/Querier 读取查询 + Compactor 压缩。

各组件职责
- Sidecar（边车）：部署在 Prometheus 旁，①把 Prometheus 本地 block 上传到对象存储（长期留存）②提供查询本地数据的接口给 Querier。无 Sidecar = 数据只在本机
- Querier（查询器）：统一查询入口，聚合多个 Prometheus/Store 的数据（去重、合并），对 Grafana/PromQL 提供全局视图。无状态、可水平扩展
- Store（存储网关）：从对象存储读取历史数据供 Querier 查询（缓存加速）。让对象存储的数据"可查询"
- Compactor（压缩器）：对对象存储中的 block 做压缩合并 + 降采样（downsampling）、删除过期/损坏数据。控制存储成本和查询速度
- Ruler（规则器）：独立的规则评估组件（告警规则/记录规则），不依赖各 Prometheus 本地 rules，集中管理。可选（也可用 Prometheus 本地 rules）
- Receiver（接收器）：可选，接收 remote_write 推送（替代 Sidecar 的 Pull 上传），适合不想让 Prometheus 挂 Sidecar 的场景

数据流

1
2
3
4
Prometheus + Sidecar → 上传 → 对象存储(S3)
                             ↓
Querier ← Store(读S3) + 各Sidecar(读本地) → 统一查询 → Grafana
Compactor（后台压缩/降采样 S3 数据）

部署形态
- 最小：每个 Prometheus + Sidecar + 单 Querier + Store + Compactor
- 大规模：Querier/Store 多副本、对象存储（S3/OSS/MinIO）、Ruler 独立集群

协助记忆
- Thanos 组件口诀：“Sidecar 上传、Querier 查询、Store 读存储、Compactor 压缩、Ruler 告警”。
- 记忆：“一个边车（Sidecar）传数据，四个中心（Querier/Store/Compactor/Ruler）各司其职”。
进阶思考
- Sidecar 和 Receiver 的区别（什么时候用哪个）？
  - Sidecar：Prometheus Pull 数据后由 Sidecar 主动上传（默认，Prometheus 本地必须有数据）；Receiver：接受 remote_write 推送（Prometheus 不存本地，直接推给 Receiver 转发到 S3）——适合不想 Prometheus 带磁盘或统一接收场景。
- Store 为什么需要？Sidecar 不是也能查本地吗？
  - Sidecar 只能查"本 Prometheus 的本地数据"；历史数据已上传 S3 的不在本机（或本机 retention 删了），Store 负责从 S3 读出这些历史数据供 Querier 聚合——“S3 数据可被查询"靠 Store。
- Compactor 的"降采样"有什么用？
  - 对象存储数据长期保留后体量大、查询慢。降采样把旧数据按粗粒度重采样（如 5m 间隔），查询长周期更快且存储减少——保留"趋势"而非"原始精度”，ExHalf 查询优化。
扩展信息
- 官方导航：thanos tools bucket ls（列出对象存储数据）、其余工具（thanos query/thanos store 等）

🤔 VictoriaMetrics 实现高可用的核心原理是什么？

VictoriaMetrics（VM）实现高可用的核心原理：①兼容 Prometheus API（Prometheus 通过 remote_write 把数据推给 VM）②vmcluster 集群三组件（vminsert 写入/vmselect 查询/vmstorage 存储，各自可水平扩展）③-replicationFactor 数据副本（多副本写入，单节点故障不丢）④存储引擎压缩优（长期留存成本低）。核心：“集群水平扩展 + 数据副本 + 兼容即插即用”。
- 核心原理
  - Prometheus 兼容：Prometheus 配 remote_write 把数据推给 VM（VM 是后端存储/查询）
  - 数据副本（replicationFactor）：写入时按副本数复制到多个 vmstorage 节点——单节点故障数据不丢
  - 读写分离/水平扩展：vminsert（写）/vmselect（查）/vmstorage（存）分离，各自可扩——容量/并发可扩展
  - 高效存储：压缩比高、快照、长期留存成本低
- 架构（vmcluster）
  1 2 3
  Prometheus → remote_write → vminsert（写多副本）→ vmstorage x N ↓ vmselect（查询）→ Grafana
  - vminsert：接收写入，按副本分发到多个 vmstorage（写路径高可用）
  - vmstorage：数据节点（多副本 = 冗余）
  - vmselect：查询聚合（可扩展、无状态）
- 单机模式（vmsingle）
  - 单二进制（vmsingle）也可用（简单、部署零组件）
  - 注意：vmsingle 单机版不支持数据复制（-replicationFactor 仅集群模式参数）；多份 vmsingle + LB 只做故障切换、不产生数据冗余。要存储层高可用需用 vmcluster
- 高可用落点
  - 存储高可用：replicationFactor 副本（数据不因单节点故障丢失）
  - 写入高可用：vminsert 多实例 + 前端（写入失败自动切换）
  - 查询高可用：vmselect 多实例（无状态）
  - 对接 Prometheus：Prometheus 是采集端（可多副本），数据统一在 VM
协助记忆
- VictoriaMetrics = “兼容 Prometheus 的高效时序库 + 集群 + 副本”：remote_write 推入、vminsert/vmselect/vmstorage 三件套、replicationFactor 副本。
- 对比 Thanos：“VM 简单高效（单二进制/压缩好），Thanos 对象存储（S3 无限/跨集群）"。
进阶思考
- VictoriaMetrics 和 Thanos 高可用思路有什么区别？
  - Thanos：Prometheus 自采 + Sidecar 上传 S3（对象存储为数据层，Prometheus 本地只是采集）；VM：remote_write 推送 + 自身集群（vmstorage 副本，数据在 VM 集群）。Thanos 强在"对象存储无限/跨集群”，VM 强在"部署简单/压缩好/一体"。
- 为什么 VM 存储压缩好对"高可用/长期"重要？
  - 长期留存 = 存储成本；VM 高压缩（比 Prometheus 原生小很多）→ 长期留存成本低 + 副本空间小。这也是 VM 在"长期存储场景"优于 Prometheus 原生的原因之一。
- replicationFactor 副本和"抓取两份"（多 Prometheus）相比？
  - VM 副本：数据在存储层冗余（Prometheus 一份推给 VM，VM 内部复制）——简单、存储层保证。多 Prometheus 采集：采集层冗余（两个 Prometheus 各采一份）——适合要"采集也高可用"的场景。两者可叠加（多采集 + VM 副本）。
扩展信息
- 组件：vminsert（8480 写入）、vmselect（8481 查询）、vmstorage（8482，内部 8400/8401）；vmsingle（8428 单机）
- 参数：-replicationFactor=2（副本数，集群模式）、-dedup.minScrapeInterval（RF>1 时去重）、-storageDataPath、-retentionPeriod（保留期）
- 部署：二进制/容器/K8s operator（VictoriaMetrics Operator）

🤔 Alertmanager 通过哪些机制减少无效告警？

Alertmanager 减少无效告警的机制：①grouping（分组：同组告警合并为一条通知）②inhibition（抑制：上级/根因告警存在时抑制下级告警）③slience（静默：预定时间段/条件静默）④去重（相同告警去重）⑤路由/分级别（按严重程度路由，低危不扰人）⑥repeat_interval（重复通知间隔）。核心：“合并同类、抑制从属、静默已知、控制噪音”。
- 分组（Grouping）
  - 同一分组（按 alertname/instance 等）的多条告警合并成一条通知
  - 例：同一主机 10 条告警 → 一条"包含 10 条"的通知
  - 配置：group_by: ['alertname', 'instance']、group_wait（等待期）/group_interval（组内间隔）
- 抑制（Inhibition）
  - 存在"更高级/根因"告警时，抑制"从属"告警（避免告警风暴）
  - 例：主机挂了（instance down）→ 抑制其上的所有服务告警（服务不可用是必然）
  - 配置：inhibit_rules（源/目标告警匹配）
- 静默（Silence）
  - 预定时间段/条件的告警静默（已知问题/维护窗口不打扰）
  - 配置：Alertmanager UI 创建 silence、matchers 匹配
  - 用于：计划维护、已知问题处理中
- 去重（Deduplication）
  - 多 Prometheus 副本产生的相同告警只发一次
  - 高可用部署时的去重（HA 基础设施）
- 重复通知控制
  - repeat_interval：重复发送间隔（如告警持续未恢复，每 4h 再提醒一次，不是一直轰炸）
  - 路由分级别：routes 按严重程度（critical/warning）路由，低危走轻通知（如仅 Email）
协助记忆
- 减噪四机制：“分组（合并）、抑制（从属）、静默（已知）、去重（副本）"。
- 口诀：“合并同类（分组）、压住从属（抑制）、静默已知、去重副本、控制重复间隔”。
进阶思考
- 分组和抑制有什么区别（何时用哪个）？
  - 分组：把多个告警合并成一条通知（减少通知条数）。抑制：有根因告警时不发送从属告警（避免内容噪音）。分组减少"条数”，抑制减少"无意义内容"。
- 静默（Silence）和抑制（Inhibition）的区别？
  - 静默：人工预定（主动静默某条件告警，如维护窗口）；抑制：规则自动（根因在→自动压住从属）。静默是人为管控，抑制是规则自动化。
- 为什么高可用部署要"去重"？
  - 两个 Prometheus 副本都报警 → Alertmanager 收到两条相同告警，不去重会发两次。Alertmanager 按分组/内容去掉重复（一条即可），避免用户收到 N 条相同告警。
扩展信息
- 配置结构：route（路由树）、group_by/group_wait/group_interval，inhibit_rules、silences（API/UI 管理）、receivers（通知渠道）
- 通知渠道：Email/Webhook/钉钉/企业微信/Slack/PagerDuty 等 receiver

🤔 Prometheus 如何调整，可以缩短告警延迟？

缩短告警延迟主要调三个时间维度：①scrape_interval（抓取间隔：数据多久采一次）②evaluation_interval（规则评估间隔：多久检查一次告警条件）③Alertmanager 的 group_wait（分组等待）。默认延迟 ≈ scrape_interval + evaluation_interval + 分组等待。缩短 = 调小这些间隔（但要平衡资源开销）。

告警延迟链路（延迟从哪来）
1
指标产生 → 被抓取（scrape_interval）→ 规则评估（evaluation_interval）→ 分组等待（group_wait）→ 通知
- 最大延迟 ≈ 抓取间隔 + 评估间隔 + 分组等待 + 通知耗时（最坏上限，非确定值）；配了 for: N 需再加 N（可能成为主导项）
可调的参数
- scrape_interval（抓取间隔）：Prometheus 抓取目标的频率（默认 15s→ 调小如 5s = 更快发现指标变化）
- evaluation_interval（评估间隔）：规则（告警/记录）评估频率（默认 15s → 调小如 5s = 更快触发告警）
- Alertmanager group_wait：分组等待时间（默认 30s → 调小 = 告警更快发送）
- group_interval/repeat_interval：组内/重复通知间隔（调小可加快后续通知）
- for 时长：告警持续时间（规则里 for: 5m 需持续才告警，调短 = 更快触发但可能误报）

配置示例

1
2
3
4
5
6
7
# prometheus.yml
global:
  scrape_interval: 5s        # 调小抓取间隔
  evaluation_interval: 5s    # 调小评估间隔
# alertmanager.yml
route:
  group_wait: 5s             # 调小分组等待

平衡（权衡）
- 间隔越小 → 告警越快，但抓取/评估/存储/资源开销越大
- for 调短 → 触发快但可能误报（瞬时抖动触发）
- 关键链路（核心服务）调小，一般服务保留默认

协助记忆
- 缩短告警：“抓取间隔（scrape）、评估间隔（evaluate）、分组等待（group_wait）三处调小”。
- 延迟公式：“scrape + evaluation + group_wait”。
进阶思考
- 告警延迟能极限压到多短？
  - 理论：scrape(最小几秒) + evaluation(几秒) + group_wait(0_{几秒) ≈ 10}30s。再短受限于采集/评估开销和 Prometheus 设计（非实时事件系统）。真需要秒级告警用其他方案（如日志实时告警）。
- for 参数对告警延迟的影响？
  - for: 5m 要求条件持续 5 分钟才告警——故意延迟（排除瞬时抖动）。要更快告警可调短/去掉 for，但要接受误报风险。
- 缩短告警延迟的"代价"是什么？
  - 资源开销（更频繁抓取/评估）、存储增长（更多样本）、告警噪音（for 调短误报）。所以"核心告警调快，非核心保持默认"是平衡策略。
扩展信息
- 全局配置：global.scrape_interval、global.evaluation_interval、job 级可覆盖
- Alertmanager 时间：group_wait、group_interval、repeat_interval

🤔 Alertmanager 高可用如何实现？

Alertmanager 高可用：①多实例部署（多个 Alertmanager 副本）②--cluster 集群模式（实例间 gossip 同步告警状态）③前端负载均衡分发（Prometheus 配多个 Alertmanager）。核心：多个 Alertmanager 组成集群（相互同步），Prometheus 把告警发给多个（去重由集群内协调，不会重复发送）。

实现方式
- 多副本部署：跑多个 Alertmanager 实例（至少 2 个）
- 集群模式：实例间 --cluster（gossip 协议）同步"已通知/静默"状态
- Prometheus 侧：配置多个 Alertmanager 地址（alertmanager: [a1, a2]），Prometheus 把告警发给全部实例（fan-out 全量发送，任一实例在都能处理；官方建议不设 LB，直接配完整地址列表）
为什么不会重复告警
- Alertmanager 集群内通过 gossip 同步"谁已通知过"——同一告警在集群内只通知一次（谁来处理由集群协调；正常情况下不重复，网络分区时官方 fail-open——宁可重复不漏报）
- 静默（silence）也在集群内同步——任一实例创建的静默对所有实例生效

架构示意

1
2
3
Prometheus → Alertmanager A ├→ 通知（集群内只发一次）
          → Alertmanager B ┘
            （A/B 通过 gossip 同步状态）

配置要点

1
2
3
4
5
6
7
# prometheus.yml 配置多个 alertmanager
alerting:
  alertmanagers:
    - static_configs:
        - targets: ['am1:9093', 'am2:9093']
# 启动参数（每个 Alertmanager；--cluster.peer 填对端地址）
alertmanager --cluster.listen-address=0.0.0.0:9094 --cluster.peer=am2:9094,am3:9094

协助记忆
- Alertmanager 高可用：“多副本 + 集群（gossip 同步）+ Prometheus 配多地址”。
- 关键：“集群内状态同步 → 去重/静默一致，不重复通知”。
进阶思考
- Alertmanager 集群用什么协议同步？
  - gossip 协议（--cluster 端口 9094）：实例间交换告警处理状态、静默、通知记录。无主（AP），即使部分实例挂活集群仍工作（Prometheus 发到任一活实例即可）。
- 没有集群（独立多实例）会重复告警吗？
  - 会：两个独立 Alertmanager 各自处理 → 相同告警各发一次（重复）。所以高可用必须"集群模式"让它们协作去重，而非简单多实例。
- Alertmanager 挂了会怎样？
  - 告警无法通知（但 Prometheus 本身正常、数据继续采集）。所以多副本 + 集群保证任一实例存活即可通知。
扩展信息
- 参数：--cluster.listen-address（监听 9094）、--cluster.peer（对端）、--cluster.peer-timeout 等
- 部署：容器（kube-prometheus 里默认多副本）、系统服务
- 注意：集群建议奇数实例（如 3）也不严格（gossip 非 Raft 无选主）

🤔 简述 Exporter 开发思路和核心细节？

Exporter 开发思路：①用官方 client library（prometheus/client_golang/Python/Java）②定义指标（名称/类型/标签）③采集数据（从被监控对象 API/命令/文件读取）④暴露 /metrics 端点 ⑤注意指标命名规范、标签基数和采集性能。核心：把被监控对象的信息"翻译"成 Prometheus 指标格式，被动等待抓取。
- 开发思路（步骤）
  - ① 选语言/库：Go（client_golang，标准）、Python（prometheus_client）、Java（simpleclient）
  - ② 定义指标：明确采集什么（Counter/Gauge/Histogram/Summary）、命名、标签
  - ③ 采集数据：从被监控对象获取数据（调用 API、执行命令、读文件、订阅事件）
  - ④ 更新指标：采集到的值 set 到定义的指标
  - ⑤ 暴露 HTTP：提供 /metrics 端点（标准 Text 格式，含 # HELP/# TYPE 元数据行）
  - ⑥ 测试/优化：curl /metrics 验证格式、promtool 校验、控制采集开销
- 核心细节（写对的关键）
  - 并发安全：指标更新要考虑并发（多 goroutine 安全）
  - 采集性能：采集开销别太大（目标 API 慢、查询重）——设采集超时/缓存
  - 标签基数控制：不要用高基数标签（URL/用户 ID）——会导致 series 爆炸
  - 命名规范：_total 后缀（Counter）、单位前缀（node_/mysqld_）、_seconds/_bytes 单位
  - HELP/TYPE：提供指标说明（HELP）和类型（TYPE），符合格式规范
  - 错误处理：采集失败返回部分数据 + 暴露采集状态指标（各 exporter 惯例用 *_up，如 mysql_up）
  - 自动发现嵌入：支持 Prometheus 直接抓取（HTTP），地址/路径可配置
- Go 示例（client_golang）
  1 2 3 4 5 6
  cache := prometheus.NewGauge(prometheus.GaugeOpts{ Name: "myapp_cache_used_bytes", Help: "Cache used bytes", }) // /metrics handler http.Handle("/metrics", promhttp.Handler())
- 规范要点（对 Go/官方库）
  - Counter 用 _total 后缀、提供 rate 用
  - promhttp.Handler() 暴露标准格式
  - prometheus.NewXxx 定义 + Registerer 注册
协助记忆
- 开发五步：“选库（client_library）→ 定义指标 → 采集数据 → 更新值 → 暴露 /metrics”。
- 核心：“命名规范（_total/单位）、控基数、并发安全、采集别太重”。
进阶思考
- 怎么保证 exporter 采集"不拖垮被监控对象"？
  - 控制采集频率（scrape_interval）、采集超时、批量查询（一次 SQL/API 取多个指标）、缓存（低频变化的指标缓存）、异步采集（后台刷新指标，抓取只读缓存）。
- 从零写一个 exporter 和用现成的怎么权衡？
  - 先找现成（exporterhub.io）；没有现成且对象有 API/命令行 → 自写（client library 很简单）；只是探活 → blackbox。自写成本低但维护要跟上。
- exporter 暴露的指标怎么确保格式正确？
  - 用官方库（格式自动正确）、curl /metrics + promtool check metrics 校验、对照 Prometheus 文档的指标命名/类型规范。
扩展信息
- 官方库：prometheus/client_golang、prometheus/client_python、prometheus/client_java（+ simpleclient）
- 指标格式：# HELP/# TYPE + <metric>{<label>=<value>} <value>
- 最佳实践：http 超时控制、采集性能、Gatherer 并发安全（抓取时全量输出）

🤔 监控一个 MySQL 是怎么样的流程？

监控 MySQL 的流程：①部署 mysqld_exporter（连 MySQL 采集指标）②创建专用监控账号（最小权限 PROCESS/REPLICATION 等）③配置 Prometheus 抓取（job + 认证）④配置 Grafana 面板 ⑤设置告警规则（连接数/慢查询/主从/性能）⑥监控验证与优化。核心：exporter 采集 → 抓取存储 → 面板展示 + 告警。

第一步：部署 mysqld_exporter
- 下载/部署 mysqld_exporter（二进制/容器）
- 配置数据源：DATA_SOURCE_NAME（连接字符串）或配置文件
- 启动后暴露 :9104/metrics

第二步：创建监控账号（最小权限）

1
2
CREATE USER 'exporter'@'localhost' IDENTIFIED BY 'xxx' WITH MAX_USER_CONNECTIONS 3;
GRANT PROCESS, REPLICATION CLIENT, SELECT ON *.* TO 'exporter'@'localhost';

权限最小化（只读监控所需权限，不用 root）；MAX_USER_CONNECTIONS 限制连接数防监控挤占业务连接

第三步：Prometheus 配置抓取

1
2
3
4
scrape_configs:
  - job_name: mysql
    static_configs:
      - targets: ['db1:9104']

多实例：每个 MySQL 一个 exporter（或共享）

第四步：Grafana 面板
- 使用官方 dashboards（mysqld_exporter 面板：ID 7362 等）导入
- 或自建面板（连接数/查询/缓冲池/主从状态）

第五步：告警规则

1
2
3
4
5
6
# 连接数过高
mysql_global_status_threads_connected / mysql_global_variables_max_connections > 0.8
# 主从延迟
mysql_slave_status_seconds_behind_master > 30
# 慢查询增长
rate(mysql_global_status_slow_queries[5m]) > 10

第六步：验证与优化
- curl localhost:9104/metrics 看指标是否采集
- Grafana 看面板数据，Prometheus 查 up{job="mysql"} 确认抓取
- 优化：采集频率、指标数量（不需要的 relabel 掉）、告警阈值调优

协助记忆
- MySQL 监控流程：“装 exporter → 建账号（最小权限）→ 配抓取 → 面板 → 告警 → 验证”。
- 口令：“exporter 采、Prometheus 存、Grafana 看、Alert 告”。
进阶思考
- 监控账号为什么不用 root？
  - 最小权限原则：只用监控所需权限（READ PROCESS/REPLICATION CLIENT/SELECT），即使账号泄露也不能改库——降低风险。
- 主从复制监控重点看什么？
  - mysql_slave_status_seconds_behind_master（延迟秒数）、Slave_IO_Running/Slave_SQL_Running（IO/SQL 线程状态，变成 NO 说明主从断了）。主从异常是最常见的 MySQL 故障。
- 哪些 MySQL 指标最重要（监控优先级）？
  - 可用性（up）、连接数（vs max_connections）、慢查询速率、主从状态/延迟、Buffer Pool 命中率、InnoDB 状态、磁盘/存储（表空间）、QPS/TPS。先保"可用性 + 连接 + 主从 + 慢查询"。
扩展信息
- 常用指标：mysql_global_status_threads_connected、mysql_global_variables_max_connections、mysql_global_status_slow_queries、mysql_slave_status_seconds_behind_master、mysql_global_status_innodb_buffer_pool*
- 高可用监控：mysqld_exporter 支持多实例（不同 data-source）、主从一键接入

🤔 新上 100 台服务器，Prometheus 如何快速接入监控？

新上 100 台服务器快速接入 Prometheus 监控的思路：①批量部署 node_exporter（Ansible/Puppet/云镜像）②统一目标清单（file_sd 文件服务发现/consul_sd 接入 CMDB）③Prometheus 自动加载（reload/热加载）④Grafana 用模板面板 ⑤基础告警规则覆盖。核心：“批量部署 exporter + 服务发现自动纳管 + 模板化展示”。
- 第一步：批量部署 node_exporter
  - 用 Ansible playbook 批量在 100 台装 node_exporter（二进制/包/容器）
  - 或：云镜像预装（imTemplate）、容器化（K8s DaemonSet）
  - 开机自启（systemd）、监听统一端口（9100）
- 第二步：目标自动发现（不用手工加 100 台）
  - file_sd：脚本/CMDB 生成主机清单 JSON → Prometheus 自动加载（推荐简单场景）
  1 2 3 4
  scrape_configs: - job_name: node file_sd_configs: - files: ['/etc/prometheus/targets/node/*.json']
  - consul_sd：主机注册到 Consul → 自动发现
  - 静态 + reload：遇到手工配置（少临时，100 台不建议）
- 第三步：Prometheus 热加载
  - kill -HUP <pid> 或 POST /-/reload（配 --web.enable-lifecycle）
  - 或周期性 reload（--web.enable-lifecycle + systemctl reload）
  - file_sd 自动检测文件变化无需手动 reload
- 第四步：Grafana 模板
  - 导入官方 Node Exporter Full 面板（ID 1860）——一组面板覆盖所有主机
  - 用变量（instance）切换主机，一个面板看 100 台
- 第五步：基础告警
  - 集群基础告警规则：up == 0（主机挂）、CPU 高、磁盘高（node_filesystem_avail_bytes / size < 0.1）、内存高、负载高
  - 规则文件批量应用（rule files）
协助记忆
- 快速接入：“Ansible 批量装 exporter → file_sd/consul 自动发现 → reload → 模板面板 → 基础告警”。
- 核心：“别手工加目标（100 台要自动化），用服务发现”。
进阶思考
- 为什么 100 台不能用"手工加 static_configs"？
  - 100 台手写目标容易错、维护成本高、且新机/下机无法自动更新。
  - 服务发现（file_sd/consul）让"目标列表"自动化（从 CMDB/脚本生成），新增机器自动纳入。
- file_sd 和 consul_sd 怎么选？
  - 有 CMDB/清单文件 → file_sd（简单，脚本输出 json）；已有 Consul 注册中心 → consul_sd（统一注册发现）；云环境主机 → 云 SD（ec2_sd 等）。按现有基础设施选。
- 批量部署 node_exporter 有什么坑？
  - 端口冲突（都用 9100 需确认）、认证（exporter 无认证需网络隔离）、防火墙放行 9100、版本一致、systemd 自启。用配置管理工具（Ansible）统一处理。
扩展信息
- Ansible 批量部署示例思路：hosts（新 100 台）→ role: node_exporter（下载/安装/systemd/启动）
- file_sd JSON 格式：[{"targets": ["ip:9100"], "labels": {"env":"prod"}}]
- Grafana 变量：面板加 instance 变量下拉切换主机

🤔 Prometheus 性能调优的核心手段有哪些？

Prometheus 性能调优核心：①控制标签基数（series 数量）②优化抓取（频率/指标过滤）③预聚合（recording rule）④查询优化（标签过滤/时间范围）⑤存储调优（retention/压缩）⑥分片/分布式（联邦/Thanos）⑦资源分配（内存/磁盘 IO）。核心：减 series、减抓取量、预聚合、分布式。
- ① 控制基数（最大头）
  - 避免高基数标签（URL/用户 ID/随机串）——用 metric_relabel_configs 删除高基数标签/丢弃样本（不能聚合，聚合用 recording rule）
  - 控制标签数（标签多了 series 组合爆炸）
  - 定期 promtool tsdb analyze 检查
- ② 优化抓取
  - 调大 scrape_interval（如 15s→30s/60s，非关键指标）
  - metric_relabel_configs 过滤不需要的指标（少采）
  - 减少 target 数（合并/用服务发现收敛）
- ③ 预聚合（recording rule）
  - 高频查询的表达式预先算好存指标（recording rules）——查询快，减少重复计算
  - 例：job:request_rate:sum = sum(rate(http_requests[5m])) 预计算存储
- ④ 查询优化
  - 查询加标签过滤（{job="x"}）、限时间范围（少扫历史）
  - 避免大范围 sum 无过滤、避免高基数子查询
  - --query.max-concurrency/--query.timeout 控制
- ⑤ 存储/资源调优
  - retention 合理（时间/大小上限）
  - 磁盘 IO（SSD）、内存分配（GOMEMLIMIT/容器限制）
  - WAL 压缩（--storage.tsdb.wal-compression）
- ⑥ 架构扩展（治本）
  - 分片：多 Prometheus 按职责/区域分（各管一部分目标）
  - 联邦：层级聚合
  - 远端：Thanos/VictoriaMetrics（数据/查询分担）
协助记忆
- 调优口诀：“控基数、限抓取、预聚合（recording）、优查询、扩架构（分片/外部）"。
- 优先级：“基数 > 抓取 > 预聚合 > 查询 > 架构”。
进阶思考
- 什么情况下"加内存/加磁盘"就能解决性能问题？
  - 中小规模、数据增长率一般时，加资源立竿见影。但高基数/海量数据时加资源只是拖延——必须控基数/分片。判断：promtool tsdb analyze 看 series 数，基数爆炸就要架构调整。
- recording rule 为什么能大幅提速？
  - 把耗时的复杂表达式（多次聚合）预先算好存指标，查询直接读结果——避免每次查询重新计算。适合"高频且重复"的查询（如 dashboard 常用的聚合）。
- 什么时候分片（多 Prometheus）？
  - 单 Prometheus 扛不住（采集量大/查询慢/资源紧张）时：按业务/区域/职责拆多实例，每台管一部分（数据隔离+资源分摊）；配合联邦/Thanos 统一查询。
扩展信息
- 参数：--query.max-concurrency、--storage.tsdb.retention.*、--storage.tsdb.wal-compression、GOMEMLIMIT、GOGC
- 工具：promtool tsdb analyze（基数/块分析）、Grafana Prometheus 自查面板、curl /metrics 体积检查

🤔 监控上千台服务器，如何保障 Prometheus 稳定运行？

监控上千台服务器保障 Prometheus 稳定：①合理容量规划（内存/磁盘/采集量）②控制基数与采集量（relabel 过滤/降频）③分片/多 Prometheus 分摊（按区域/职责）④Thanos 统一查询/长期存储（数据/查询解耦）⑤监控 Prometheus 自身（自监控：up/内存/查询延迟）⑥告警/参数优化（慢查询、超时）。核心：“减数据（基数/采集）+ 分摊（分片/外部）+ 自监控”。
- ① 容量规划（先知容量）
  - 估算：target 数 × 指标数 × 采样频率 × 保留期 = 数据量
  - 内存 ≈ series 数相关（每系列常驻内存）、磁盘随保留增长
  - 预留余量（建议只用到约 50% 容量，超水位告警）
- ② 控制采集与基数
  - relabel/metric_relabel 过滤高基数标签、减少无用指标
  - scrape_interval 合理（非关键 30s/60s）
  - promtool tsdb analyze 定期检查基数/爆炸
- ③ 分片（多 Prometheus）
  - 按区域/业务/职责拆多实例（每台管几百台目标，数据分摊）
  - 数据隔离 + 资源分摊（单机不超载）
- ④ Thanos/Victoria 统一视图
  - 多 Prometheus 通过 Thanos（S3 + Querier）统一查询/长期存储
  - 或 VictoriaMetrics 收 remote_write
  - 上层只用一套查询（Grafana 连 Querier/VM），Prometheus 只管采集
- ⑤ 自监控（监控 Prometheus）
  - Prometheus 监控自己（up/内存/系列数/抓取失败/查询延迟）
  - 关键自监控告警：Prometheus 挂了、抓取失败率高、内存高、查询慢
  - Prometheus Operator（K8s）或手工配置
- ⑥ 参数/稳定性优化
  - --storage.tsdb.wal-compression（WAL 压缩省磁盘）
  - 限制查询（--query.max-concurrency、timeout）防查询拖垮
  - 磁盘 SSD + 充足内存
  - 告警规则别过多（rule 评估开销）
协助记忆
- 千台稳定：“容量规划、控基数、分片分摊、Thanos 统一、自监控、参数优”。
- 核心：“数据减不下来就分片，统一查询靠 Thanos，别忘了监控监控自己”。
进阶思考
- 上千台为什么要分片而不是一个大 Prometheus？
  - 单实例内存/磁盘/查询有天花板，上千台 target + 海量 series 会把单 Prometheus 压垮（OOM/查询慢）。分片把负载分散到多个实例（资源分摊+故障隔离），这是规模化的必经之路。
- 多 Prometheus 后"查询分散"怎么办？
  - Thanos Querier 统一查询（跨实例聚合）；VictoriaMetrics 收 remote_write 统一存储；上层 Grafana 连统一查询层即可，用户只有一个视图。
- 怎么发现 Prometheus 自己出问题？
  - 自监控：Prometheus 抓自己的 /metrics（up/process_resident_memory_bytes/tsdb_head_series/prometheus_tsdb_*），配告警（进程挂/内存高/抓取失败率高/查询慢）。用 Grafana 自带 Prometheus 自检面板。
扩展信息
- 规模参考：单 Prometheus 常见可管数百万 series（内存主导：16GB 内存跑数百万 series 为社区共识），具体用 promtool tsdb analyze 评估
- 模式：采集层（多 Prometheus）+ 查询层（Thanos/VM）解耦——标准规模化架构

🤔 Prometheus 的 Pull 模型相比 Push 模型优缺点？

Prometheus 的 Pull（拉取）模型：Prometheus 主动按间隔从目标（exporter）拉指标；对比 Push（推送，如 Pushgateway/InfluxDB 风格）：Pull 优点——①控制权在监控端（知道目标、可调频率/超时）②故障发现（目标挂了 up=0，延迟一个抓取周期）③调试直观（curl /metrics）④安全（监控端发起、目标只暴露只读端点）；缺点——①目标需在线暴露端点（否则 up=0）②防火墙/NAT 场景难③短任务无法拉（配 Pushgateway）。核心：Pull 更可靠可探活，Push 适合短任务/网络受限。

Pull 模型特点（Prometheus 默认）
- Prometheus 主动按 scrape_interval 从目标拉取
- 监控端控制：知道有哪些目标、间隔、超时
Pull 优点
- 探活信息：抓不到目标 → up == 0（自动发现目标挂了）
- 控制权在监控端：频率/超时/重试可控
- 调试直观：curl http://target:9100/metrics 直接看
- 安全：目标只需开放 /metrics（只读、无状态），监控端发起到目标
- 目标简化：exporter 无状态、无推送逻辑
Pull 缺点
- 目标需暴露端点：必须开放 /metrics 端口（网络可达）
- 网络受限/NAT/防火墙：监控端到目标不通则无法拉（跨网段/公网难）
- 短任务无法拉：批处理/定时任务瞬间结束，来不及被拉（需 Pushgateway 补）
- 目标量大时拉取开销（监控端发起大量连接）
Push 模型特点（对比）
- 目标主动把指标推送到监控端/网关（Pushgateway/InfluxDB 风格）
- 适合：短任务、防火墙后目标、需要目标主动上报（IoT 设备）
- 缺点：监控端不知道目标（探活难）、无统一控制、push 无认证风险、目标可能乱发

对照

维度	Pull（Prometheus）	Push
控制	监控端控制	目标主动
探活	拉不到=挂了（up=0）	难（不知道谁来）
网络	需目标暴露端点	目标能连即可
短任务	不支持（靠 Pushgateway）	适合
调试	curl /metrics 方便	需看网关

协助记忆
- Pull 口诀：“监控端拉（可控/可探活/可调）、目标暴露端点、短任务靠 Pushgateway”。
- 定位：“Pull 是 Prometheus 的设计正统，Push 是短任务/受限网络的补丁”。
进阶思考
- 为什么 Prometheus 坚持 Pull 而不是全用 Push？
  - Pull 让监控端"掌控全局”：目标列表（谁在监控）、间隔、超时、探活（up=0 立即发现故障）都归一监控端。Push 这些都没有（不知道目标、无法探活、无法统一控制）。这也是 Prometheus 设计哲学（黑盒从拉取探测）。
- Pull 模型遇到"防火墙后/公网目标"怎么解决？
  - 目标不支持被拉时：①Pushgateway（目标推给它，Prometheus 拉它）②exporter 背后加"反向拉取"代理③网络打通（VPN/隧道）④云 SD 走内网。实际多为内网目标（Pull 都通），公网目标少。
- Pull 和 Push 能混用吗？
  - 能：Prometheus 以 Pull 为主（标准 exporter 被拉）+ 短任务用 Pushgateway Push；也可 remote_write 推给后端（那是"Prometheus 对外推"）。核心目标是拉，Push 是补充。
扩展信息
- 相关场景：blackbox_exporter（Pull 探测）、Pushgateway（Push 短任务）、remote_write（Prometheus 推送后端）
- 对比系统：InfluxDB（Push 风格）、Zabbix（Agent 主动/被动）

🤔 Prometheus 如何实现对 Kubernetes 集群自动发现监控？

Prometheus 对 K8s 自动发现的核心：kubernetes_sd_configs 按角色（node/pod/service/endpoints/ingress）发现监控目标，配合 relabel_configs 从 __meta_kubernetes_* 元标签筛选/打业务标签。典型：node 角色监控节点（node_exporter）、pod 角色监控应用容器、endpoints 监控 Service。

服务发现（kubernetes_sd）
- Prometheus 通过 K8s API 自动发现集群对象（不用手工配置目标）
- 角色（role）：
  - node：发现所有节点（配 node_exporter 监控主机）
  - pod：发现所有 Pod（监控容器/应用指标）
  - service：发现 Service（监控服务端点）
  - endpoints/endpointslices：发现 Service 的端点（细粒度）
  - ingress：发现 Ingress
- 每个角色产生 __meta_kubernetes_* 元标签（命名空间/名称/标签等）

结合 relabel（筛选/打标）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
scrape_configs:
  - job_name: kubernetes-pods
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      # 只采打了 prometheus.io/scrape=true 的 Pod
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        regex: "true"
        action: keep
      # 元标签转业务标签
      - source_labels: [__meta_kubernetes_pod_label_app]
        target_label: app

典型监控场景
- 节点监控：role: node + node_exporter（:9100/metrics）
- 应用/容器监控：role: pod + 应用暴露 /metrics（按注解 prometheus.io/scrape=true 筛选）
- Service 监控：role: service/endpoints（按 Service 端口采集）
- K8s 自身：kube-state-metrics（对象状态）、cadvisor/Kubelet /metrics

监控矩阵（常用组合）

监控对象	role	采集源
节点指标	node	node_exporter
容器资源	node/endpoints+kubelet	Kubelet `/metrics/cadvisor`
应用指标	pod/endpoints	应用 `/metrics`
K8s 对象状态	（kube-state-metrics 暴露）	ksm `/metrics`
集群组件	endpoints 角色（kubelet 等）	Kubelet/组件 `/metrics`（etcd 通常独立直连）

协助记忆
- K8s 发现口诀："kubernetes_sd + role（node/pod/service/endpoints）+ relabel 打标筛选"。
- 场景：节点用 node+node_exporter，应用用 pod+注解筛选，K8s 状态用 kube-state-metrics。
进阶思考
- 为什么要用"注解筛选"（prometheus.io/scrape=true）？
  - 不是所有 Pod 都要被监控（有的无 /metrics）。约定：打上 prometheus.io/scrape=true 注解的 Pod 才被采集（keep 筛选）——避免给所有 Pod 抓取（浪费/噪音），也便于开发者自助开放监控。
- role: pod 和 role: endpoints 有什么区别？
  - pod：发现每个 Pod（适合直接抓 Pod）；endpoints：发现 Service 的端点（适合抓 Service 对应的 Pod，可带 Service 语义）。Service 监控通常用 endpoints（拿 Service 名称作为分组）。
- Prometheus 权限怎么配（RBAC）？
  - Prometheus 需 RBAC：ServiceAccount + ClusterRole（list/watch nodes/pods/services/endpoints）+ ClusterRoleBinding（kube-prometheus 已内置）。否则无法调 K8s API 做服务发现。
扩展信息
- 元标签示例：__meta_kubernetes_pod_label_app、__meta_kubernetes_namespace、__meta_kubernetes_pod_annotation_prometheus_io_scrape
- 部署：kube-prometheus stack（Prometheus Operator 全套）、Helm chart

🤔 Prometheus 查询突然变慢，可能的原因与排查思路？

Prometheus 查询突然变慢的原因：①数据量增大（target/指标/基数上升）②高基数查询（大量 series 扫描）③无过滤大范围查询（全量 sum/长时段）④资源不足（内存/CPU 被采集挤压）⑤规则（recording/alert）过重拖累。排查：分场景看（全变慢 vs 单查询变慢），用查询日志/top 定位，控基数/限范围/预聚合解决。
- 常见原因分类
  - 数据量增长：target 增加、指标增加、采集频率调小（数据量↑）
  - 基数膨胀：高基数标签引入（新版本加了 URL/用户 ID 标签）→ series 暴涨 → 查询扫描多
  - 查询本身重：无过滤的 sum、大时间范围（扫全部历史 block）、* 全选（如 {__name__=~...}）
  - 资源被挤占：采集/写入占内存/CPU，查询被饿
  - 规则重：recording/alert 规则多且重（评估占资源）
  - 并发查询多：Grafana 面板同时多查询
- 排查思路（分场景）
  - 全查询变慢：看资源（内存/CPU/磁盘 IO）是否吃紧 → 数据量/资源问题
  - 部分查询变慢：看查询表达式（是否高基数/大范围）→ 查询问题
  - 新增查询变慢：新规则/新面板引入的重查询 → 预聚合
- 定位手段
  - Prometheus 开启查询日志（--query.log-file）看慢查询；--query.max-samples 超限报错
  - curl /api/v1/query 手动测各表达式耗时
  - promtool tsdb analyze（基数/块分析）
  - Grafana 面板逐个查（定位是哪条查询慢）
  - 监控 Prometheus 自身：prometheus_engine_queries、rate(prometheus_tsdb_head_series)
- 解决方案
  - 控基数：relabel 删高基数标签（治本）
  - 限查询：加标签过滤、限时间范围、避免 * 全选
  - 预聚合：慢查询改 recording rule（预先算好）
  - 加资源：内存/CPU/SSD（数据量正常但资源不足时）
  - 缩范围：查询页/面板默认只查近期（而非全部保留期）
协助记忆
- 查询慢排查：“数据涨？基数涨？查询重？资源紧？规则重？——用查询日志/tsdb analyze 定位，控基数/预聚合解决”。
- 口诀：“先分场景（全慢 vs 单慢），再看数据/查询/资源，最后控基数/预聚合”。
进阶思考
- “突然变慢"通常是哪些原因（怎么快断）？
  - 突然变慢（而非渐进）：①新发布引入了高基数标签（series 暴涨）②新面板/规则加了重查询 ③采集量突增（新 target/改频率）④资源被其他进程挤压。优先查：series 数趋势、新增查询/规则、资源占用。
- 为什么"无过滤 sum"会慢？
  - sum(rate(metric[5m])) 不带标签过滤 = 扫全部该指标的 series（全量）。series 多时扫描量大（且要加载到内存）。加过滤（{job=...}）或按维度聚合（sum by）大幅减少扫描。
- 查询慢和 OOM 有关系吗？
  - 有关：重查询会临时加载大量 series 到内存（--query.max-samples 超限或内存峰值），并发重查询可能引发 OOM。所以限制查询并发/样本是稳定性的重要一环。
扩展信息
- 相关参数：--query.max-concurrency（并发查询数）、--query.timeout（查询超时）、--query.max-samples（样本上限）
- 自查指标：prometheus_engine_queries、prometheus_tsdb_head_series、process_resident_memory_bytes

🤔 如何评估 Prometheus 集群的容量？

Prometheus 容量评估核心看四维：①series 数（内存主导，promtool tsdb analyze）②摄入速率（每秒样本数 = target×指标×频率，决定 CPU/写入）③磁盘（样本数×保留期×压缩比）④查询负载（并发/复杂度）。估算法：每秒样本数 × 保留秒数 × 每样本字节 等，再按目标/指标/频率核算。

四维评估（核心）
- ① Series 数（最重要，内存主导）：唯一"指标+标签组合"数。用 promtool tsdb analyze/count(series) 实测。内存 ≈ series 数 × 每系列开销（常见每百万 series 需数 GB 内存经验值）
- ② 摄入速率（CPU/写入）：每秒抓取的样本数 = target 数 × 每 target 指标数 × （1/抓取间隔）。决定 CPU 和写入吞吐
- ③ 磁盘（存储）：总样本数 = 摄入速率 × 保留时间；磁盘 = 样本数 × 每样本大小（压缩后 ₁2 字节，经验）。高基数则磁盘暴涨
- ④ 查询负载：并发查询、复杂 PromQL（影响 CPU/内存）

估算公式（经验）

1
2
3
4
每秒样本 = Σ(target 数 × 每 target 序列数) / scrape_interval
总序列 = target 数 × 每 target 序列数（≈ series 数）
磁盘 ≈ 每秒样本 × 保留秒数 × ~1.5 字节（压缩后经验值）
内存 ≈ series 数 × 每系列内存（微量级，百万 series 约数 GB 经验）

评估步骤
- ① 实测当前：promtool tsdb analyze（series 数/块）、Prometheus 自指标（tsdb_head_series、tsdb_head_samples_appended_total）
- ② 预测增长：目标增加数 × 每目标指标数（新业务/扩机器）
- ③ 按保留期算磁盘、按 series 算内存
- ④ 对比硬件（内存/磁盘/CPU），留余量（>50%）
优化容量
- 控基数（最多减 series）
- 调 scrape_interval（降摄入）
- 缩短保留期/降采样（外部存储）
- 分片/Thanos（分摊）

协助记忆
- 容量四维：“series（内存）、摄入（CPU）、磁盘（保留）、查询（负载）"。
- 估法：“每 target 序列 × target 数 = series；series × 压缩大小 × 保留 = 磁盘；series × 每系列内存 = 内存”。
进阶思考
- 为什么 series 数是"第一指标”（决定内存/存储）？
  - 每个 series 都要在内存建索引 + 存储序列，series 数直接线性决定内存和磁盘（基数爆炸是最快撑爆容量的）。所以容量评估先测 series、控制基数。
- 怎么预测"未来容量”（新业务上线前）？
  - 预估：新 target 数 × 平均每 target 序列数（参考现有）+ 抓取频率 → 新增 series/摄入 → 折合内存/磁盘增量。最好在小环境压测验证。
- “余量 50%“实践指什么？
  - 容量要留缓冲（突发流量/查询峰值/新业务）：评估容量建议只用到 50% 左右（如内存目标 50% 水位），超过即告警/扩容/优化。
扩展信息
- 工具：promtool tsdb analyze、Grafana Prometheus 自身容量面板、prometheus_tsdb_* 指标
- 经验值：每 target 通常几十~几百序列（node_exporter ~数百、应用依实现）；压缩后每样本 ₁2 字节（经验）

🤔 Grafana 图表不显示数据，怎么排查？

Grafana 图表不显示数据的排查：①先看数据源（Prometheus 通不通）②Panel 查询是否返回数据（query inspector 测试）③时间范围/标签匹配是否对 ④指标名/单位/min step 是否对 ⑤权限/数据源变量。排查链路：“数据源 → 查询 → 时间 → 标签 → 面板配置"逐层验证。
- 第一步：数据源是否正常
  - Grafana → 数据源（Prometheus）→ Test（能否连通）
  - Prometheus 数据源 URL/认证是否正确、版本兼容
  - Prometheus 自身 up 是否正常（Grafana 能连但 Prometheus 没数据）
- 第二步：查询是否返回数据
  - 面板编辑 → Query → 手动执行查询看返回（无数据 = 查询问题）
  - 用 Inspect（快捷键 i）→ Query 标签看原始请求/响应
  - 直接到 Prometheus 的 Graph/curl /api/v1/query 验证表达式
- 第三步：时间范围
  - 时间范围太短/太久（数据不在范围内）
  - 时区/时间手选（now-1h vs 固定日期）
  - Panel 的 min step（步长太大跨掉数据）
- 第四步：标签/指标匹配
  - 指标名拼错（node_cpu vs node_cpu_seconds_total）
  - 标签选择器不匹配（{job="x"} 实际 job 不同）
  - 用了 {__name__=~"x|y"} 语法错
  - PromQL 语法错误（Grafana 报错）
- 第五步：其他
  - 数据源变量（模板变量选的值无数据）
  - 面板权限（只读仪表盘但无查询权限）
  - Prometheus 数据未采集（目标挂了 up=0）
  - 浏览器缓存/时区
协助记忆
- Grafana 排查口诀：“数据源先测、查询验证（Query Inspector）、时间范围、标签匹配、面板配置”。
- 链路：“数据源 → 查询语句 → 时间 → 标签 → 配置”。
进阶思考
- 怎么用 Query Inspector 快速定位？
  - 面板 Edit → Inspect（Query）→ 看实际执行的请求（指标/标签/时间/原始响应）——直接在浏览器看 Prometheus 返回了什么（空/错误/数据），一步定位是"查询错"还是"数据源/时间"问题。
- Prometheus 有数据但 Grafana 不显示，常见坑？
  - ①查询里变量引用错（$var 未定义/选空）②时间范围未覆盖数据（数据是旧的，面板默认 now-6h）③min step 太大（采样间隔长且步长大）④数据源 URL 配错（Grafana 连到另一个 Prometheus）⑤PromQL 语法错（如括号/引号、标签选择器语法）。
- 数据源 “No data” 和 “Query error” 区别？
  - No data：查询正常执行但无匹配数据（时间/标签/指标名问题）；Query error：查询本身报错（语法/超时/数据源问题）。先看报错类型再定位。
扩展信息
- 排查工具：Prometheus Graph（原生查）、curl 'http://prom:9090/api/v1/query?query=xxx'、Grafana Query Inspector
- 变量：数据源变量（$datasource）、模板变量（$instance 等）—面板多选/筛选

🤔 Prometheus Operator 是什么？解决了什么问题？

Prometheus Operator 是"用 K8s 原生方式（CRD/Controller）管理 Prometheus 生态"的工具：通过自定义资源（Prometheus/ServiceMonitor/PodMonitor/Alertmanager/PrometheusRule）声明式地管理监控栈，解决"K8s 里监控配置复杂、手工管理难"的问题——自动部署、自动发现目标（ServiceMonitor 声明式）、自动注入告警规则、自动配置 Alertmanager。

是什么（定义）
- Operator 模式：用 K8s Controller + CRD 管理应用（运维逻辑代码化）
- Prometheus Operator：管理 Prometheus/Alertmanager 生命周期 + 监控配置（目标/规则）
- 部署后：创建 Prometheus CR → Operator 自动起 Prometheus 集群
核心 CRD（自定义资源）
- Prometheus：声明 Prometheus 实例（版本/存储/资源/保留期）——Operator 自动部署/管理
- ServiceMonitor：声明"监控哪些 Service”（选择器 + 端点 + 间隔）——自动生成抓取配置（替代手写 static_configs）
- PodMonitor：声明"监控哪些 Pod”（类似 ServiceMonitor 但按 Pod）
- PrometheusRule：声明告警/记录规则（替代手写 rule files）
- Alertmanager：声明 Alertmanager 实例（高可用/配置）
- Probe：blackbox 探活目标声明
- 补充：ScrapeConfig（v0.68+，直接声明抓取配置，逐步主推）、AlertmanagerConfig（告警路由配置）、ThanosRuler（Thanos 规则）
解决了什么问题
- 配置声明化：监控目标（ServiceMonitor）、规则（PrometheusRule）用 YAML CR 声明，GitOps 可管理
- 自动部署：Prometheus/Alertmanager 生命周期（扩缩容/升级/高可用）由 Operator 管理
- 自动发现目标：新的 ServiceMonitor 创建 → 自动抓取（无需手工改 Prometheus 配置）
- K8s 原生集成：与 K8s 服务发现/RBAC 天然结合
- 可观测运维简单化：一套 CR 管理监控栈（kube-prometheus stack 提供了全套）

工作流程

1
2
创建 ServiceMonitor（声明监控某 Service）→ Operator 监听 → 生成 Prometheus 抓取配置 → 自动抓取
创建 PrometheusRule → Operator → 注入告警规则 → 评估/告警

协助记忆
- Operator = “用 CRD 管理监控栈”：Prometheus（实例）、ServiceMonitor（目标）、PrometheusRule（规则）、Alertmanager（告警）。
- 价值：“声明式配置监控，自动部署 + 自动发现 + GitOps 友好”。
进阶思考
- ServiceMonitor 和直接写 scrape_configs 的区别？
  - 手写：改 Prometheus 配置文件 + reload。ServiceMonitor：创建 CR（选择器找 Service）→ Operator 自动生成抓取配置并应用——声明式、自动、可 GitOps、无需手工改配置。
- Prometheus Operator 和 kube-prometheus 是什么关系？
  - kube-prometheus 是基于 Prometheus Operator 的"全家桶 stack”：Operator + Prometheus + Alertmanager + Grafana + node-exporter + kube-state-metrics + 默认告警规则，一键部署 K8s 监控全套。
- ServiceMonitor 的"选择器"怎么工作？
  - 选择器按 label 匹配 Service/Pod（如 matchLabels: {app: myapp}）——匹配到的 Service 暴露的 metrics 端点自动被抓取。开发者只需给 Service 打 label + 暴露 /metrics。
扩展信息
- kube-prometheus stack：官方推荐的全套部署（Operator+CR 管理）
- 基础监控：默认带 node-exporter/kube-state-metrics/K8s 组件监控 + 告警规则
- 相关 CRD：Prometheus、Alertmanager、ServiceMonitor、PodMonitor、PrometheusRule、Probe

🤔 Prometheus 与 Zabbix 有什么区别？

Prometheus 与 Zabbix 的核心区别：①采集模型（Prometheus：Pull 拉取/exporter；Zabbix：Agent 主动/被动上报）②定位（Prometheus：云原生/容器/动态环境、Metrics 驱动；Zabbix：传统主机/网络、全栈监控）③存储（Prometheus：本地 TSDB；Zabbix：数据库 MySQL/PostgreSQL）④告警（Prometheus：规则+Alertmanager；Zabbix：触发器+动作）⑤适用（Prometheus 适合云原生/容器/K8s 场景；Zabbix 适合传统主机/网络/基础设施）。两者互补，按环境选型。

采集模型（最大的区别）
- Prometheus：Pull（拉取）——Prometheus 主动从 exporter 拉指标（监控端控制，容器/云原生友好）
- Zabbix：Agent（被动/主动上报）——Zabbix Server 轮询 Agent（被动），或 Agent 主动上报（主动）；有 Agent 常驻
定位与场景
- Prometheus：云原生/容器/K8s（服务发现、动态环境）、以"指标（Metrics）“为主
- Zabbix：传统基础设施（主机/网络设备/SNMP/IPMI）、全栈（指标 + 日志 + 网络发现在一个平台）
存储
- Prometheus：本地 TSDB（时序库，高效压缩，配合 Thanos/VM 扩展）
- Zabbix：关系数据库（MySQL/PostgreSQL）+ 分区（历史/趋势表），数据量大时库压力大
告警
- Prometheus：PromQL 规则 + Alertmanager（分组/抑制/静默/多渠道）
- Zabbix：触发器（trigger）+ 动作（action），内置告警升级/依赖

对比速查

维度	`Prometheus`	`Zabbix`
模型	Pull（exporter）	Agent 被动/主动
场景	云原生/K8s/容器	传统主机/网络
存储	本地 TSDB	数据库（MySQL/PG）
告警	PromQL 规则+Alertmanager	触发器+动作
动态发现	强（服务发现）	有（自动发现）
学习曲线	UI 弱（Grafana）	自带 UI（较为直观）
适用	云原生/新架构	传统基础设施

互补（如何共存）
- 传统主机/网络：Zabbix（全栈、模板丰富）；云原生/容器：Prometheus（原生态）
- 可共存：物理横用 Zabbix，K8s/应用指标用 Prometheus

协助记忆
- 区别口诀：“Prometheus 拉（Pull、K8s 原生、TSDB 存储）；Zabbix Agent 报（传统主机、数据库存储、全栈）"。
- 选型：“新架构/容器/云原生 → Prometheus；传统主机/网络 → Zabbix”。
进阶思考
- 能不能用 Zabbix 监控 K8s 容器？
  - 能但非原生：Zabbix 可监控 K8s（通过官方 K8s 模板/API 发现 + 数据采集），但不如 Prometheus 原生（kubernetes_sd + ServiceMonitor）方便。云原生场景 Prometheus 生态更完整（Operator/告警规则/指标）。
- Prometheus 能监控网络设备吗？
  - 能（snmp_exporter），但 Zabbix 的 SNMP/IPMI 网络监控更成熟（模板丰富、开箱即用）。网络/传统设备场景 Zabbix 更省事。
- 两者共存是否浪费？
  - 不浪费：各司其职（物理设备 Zabbix、应用/容器 Prometheus），监控数据可在 Grafana 统一展示（Grafana 支持 Zabbix 数据源插件的社区方案，或用 Prometheus 作为统一口径）。实际很多企业共存。
扩展信息
- Zabbix 特点：Agent（被动/主动）、SNMP/IPMI、自动发现、触发器/动作告警、模板
- Prometheus 特点：Pull/exporter、服务发现、PromQL、Alertmanager、TSDB 存储
- 融合方案：Grafana 统一展示（Zabbix 数据源插件）、或 Zabbix 数据经外部导出到 Prometheus 生态