Prometheus FAQ
内容：基础、运维、告警、性能、架构、Exporter、PromQL、生态等。
Prometheus 是一个开源监控系统和时间序列数据库，用于：
- 服务监控
- 时序数据存储
- 指标采集（metrics）
- 告警（Alertmanager）
- 可视化（Prometheus UI / Grafana）
核心能力是 通过 Pull 模式（HTTP Scrape）定期采集数据并存成时间序列。
| 组件 | 作用 |
|---|---|
| Prometheus Server | 抓取指标 + 存储 TSDB + 执行查询 |
| Exporter | 暴露 metrics（如 node_exporter） |
| Alertmanager | 接收规则并发告警 |
| Pushgateway | 临时性 Job 的数据上报 |
| PromQL | 查询语言 |
| Grafana | 可视化 |
👍 优点：
- 无需在客户端配置推送
- 服务端统一控制采集频率
- 自动发现 Targets
- 易横向扩展
- Metrics 抓取延迟低
👎 缺点：
- 不能监控无法被访问的节点（需 Pushgateway）
- 大规模 Scrape 时压力集中在 Server
核心结构：时间序列（Time Series）
MetricName{label1="a", label2="b"} => [timestamp, value]...
包括：
- metric name
- labels（维度信息）
- samples（时间戳 + 值）
Prometheus 自带一个本地 TSDB，特点：
- 采用 Block 存储，每个块 2 小时
- WAL（Write Ahead Log）
- 压缩算法：varbit encoding
- 存储目录结构：
/data/
├── wal/
├── chunks_head/
├── 01F.../
两种：
Prometheus 主动去 scrape target。
必须用 Pushgateway。
| Exporter | 用途 |
|---|---|
| node_exporter | 服务器监控 |
| blackbox_exporter | 探测 HTTP/HTTPS/TCP/ICMP |
| mysqld_exporter | MySQL |
| mongodb_exporter | MongoDB |
| redis_exporter | Redis |
| nginx/nginx-vts-exporter | Nginx |
| cadvisor | 容器指标 |
| kube-state-metrics | Kubernetes 资源状态 |
| kubelet metrics | Pod/Node 性能 |
回答要点：
- 避免动态 label（如用户 ID、IP、URL）
- 使用 label_drop 删除无必要标签
- 限制 histogram buckets
- 避免为每个实例、请求或事件生成一个 Label
通过 Service Discovery（SD） 配置：
kubernetes_sd_configs:
- role: pod
常见 role：
- node
- pod
- service
- endpoints
- ingress
组件：
- kubelet：/metrics /metrics/cadvisor
- apiserver：/metrics
- scheduler：/metrics
- controller-manager：/metrics
使用 kube-prometheus-stack 自动安装最便捷。
| 函数 | 说明 |
|---|---|
| rate(x[5m]) | 计算区间内平均增长率（推荐用于长期趋势） |
| irate(x[5m]) | 区间末两点的瞬时增长率（推荐用于监控突发） |
increase(counter[5m])
用于统计在窗口期内的总增长量，常用：
- 请求数增长量
- 错误数增长量
| 项 | Histogram | Summary |
|---|---|---|
| 百分位聚合 | 有（通过 histogram_quantile） | 有 |
| 能否跨实例聚合 | ✅ 可以 | ❌ 很难 |
| 适合场景 | 分布统计、跨实例聚合 | 单实例延迟分析 |
生产环境统一用 histogram，禁用 summary（除非明确需求）。
用于时间偏移分析：
rate(http_requests_total[5m] offset 1h)
常用于对比过去数据。
Alertmanager 将相似告警合并推送：
如按 label 分组：
group_by: ["cluster", "alertname"]
可以减少噪音。
比如一个 NodeDown，抑制：
- node CPU 警告
- 磁盘告警
- 内存告警
防止告警只发送一次：
repeat_interval: 4h
4 小时没有恢复，则重复发一次。
因为 高基数（High Cardinality）。
产生原因：
- 动态 label（UUID、IP、UserID）
- histogram buckets 过多
- label 数量太大
- target 过多
解决方案：
- 降低 label
- 启用 remote write
- 调整 scrape interval
- 增加内存
- 分片（sharding）
Prometheus 本身是单实例，但可以：
多个 Prometheus，使用 hashmod 把监控目标分片。
从多个 Prometheus 上抓取汇聚指标。
云原生分布式监控系统。
因为：
- 本地 TSDB 单机无法扩展
- 成本高
- 查询慢
- 容易 OOM
一般 15 天就够。
长期数据交给：
- Thanos
- VictoriaMetrics
- Cortex/Mimir
短生命周期任务（CronJob）
不适用：
- 服务长期 metrics（应使用 Exporter）
- 大规模监控（会 OOM）
❌ 不会
需要手动调用：
DELETE /metrics/job/<job_name>
最经典方案：
两个 Prometheus 实例
- 配置完全一致
- Alertmanager 做 HA
- Grafana 隐藏重复数据（via min step or dedup）
如果是 Kubernetes，可使用 kube-prometheus-stack。
- 从 WAL 恢复
- 从 remote storage 重新拉取（如 Thanos）
- promtool check tsdb / repair
一个 Prometheus 从另一个 Prometheus 拉取指标。
用途：
- 汇聚多数据中心
- 集中监控
- 分层架构
| 特性 | Prometheus | Zabbix/Nagios |
|---|---|---|
| 采集方式 | Pull | Push |
| 架构 | 时序数据库 | 事件驱动 |
| 适合场景 | 云原生、微服务、大规模 | 传统主机监控 |
| 告警 | 强，规则灵活 | 强 |
| 存储 | 本地/远程 | 内置 DB |
| 可扩展性 | 高 | 中等 |
因为 URL 动态变化导致高基数（Cardinality Explosion），会让 Prometheus 崩溃。
使用 blackbox exporter：
http:
prober: http
检查：
- 延迟
- 可用性
- 请求成功率
rate(http_requests_total[1m])
histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))