prometheus面试题
3586 字
18 分钟
prometheus面试题
一、 Prometheus 基础与架构
- Prometheus 的核心架构由哪些组件组成？各自职责是什么？
参考答案：
- Prometheus Server：核心，负责指标抓取（scrape）、存储（TSDB）、PromQL 查询与告警规则评估。
- Exporters：暴露监控指标的采集端（node-exporter、mysql-exporter 等）。
- Pushgateway：临时任务的指标推送入口（短期 Job 场景）。
- Alertmanager：处理告警（去重、分组、路由、抑制、静默、通知）。
- Web UI / Grafana：可视化查询界面。
- 工作流：
Exporter 暴露指标 → Prometheus 定时 pull → 存储 TSDB → 规则评估触发告警 → Alertmanager 通知。
- Prometheus 的数据模型是什么？时间序列由什么组成？
参考答案：
- 数据模型：基于标签的多维时间序列数据模型。
- 一条时间序列 = 指标名（metric name）+ 标签集（labels）+ 时间戳与样本值。
- 唯一标识：
指标名 + 标签键值对集合（相同标识的多次采集构成时间序列）。 - 示例：
http_requests_total{method="GET", code="200"}。 - 标签作用：维度筛选、聚合、告警分组。
- Prometheus 的四种指标类型是什么？各自适用什么场景？
参考答案：
- Counter：只增不减的计数器（请求总数、错误总数），用
rate()计算速率。 - Gauge：可增可减的瞬时值（CPU 使用率、内存占用、在线人数）。
- Histogram：直方图，统计分布（请求延迟分位数），支持
histogram_quantile计算 P99。 - Summary：摘要，客户端直接计算分位数（延迟 P50/P99），无法跨实例聚合。
- 选型：计数用 Counter、瞬时值用 Gauge、延迟分布优先 Histogram（可聚合）。
二、 数据采集
- Prometheus 为什么采用 pull 模式？Pushgateway 的适用场景和缺点？
参考答案：
- pull 模式：Prometheus 主动从目标抓取，优势：采集端更易发现故障（目标挂了直接抓不到）、配置集中管理、天然避免指标重复。
- Pushgateway 适用场景：短期任务（批处理 Job）在运行结束时推指标，因为任务生命周期太短 pull 来不及抓取。
- 缺点：Pushgateway 是单点、无法感知任务实例是否存活、指标可能长期残留（需主动清理）、多实例指标聚合困难。
- 建议：能 pull 就 pull，Pushgateway 只用于必要的短生命周期任务。
- Prometheus 支持哪些服务发现方式？K8s 场景如何配置？
参考答案：
- 常见方式：file_sd（文件列表）、consul_sd、dns_sd、ec2_sd 等云平台发现、kubernetes_sd（K8s 原生发现）。
- K8s 发现：通过
kubernetes_sd_configs的 role（node、pod、service、endpoints、ingress）动态发现目标。 - 优势：Pod 弹性扩缩容时自动增减采集目标，无需手工维护 target 列表。
- 配合：
relabel_configs对发现的目标进行标签改写与过滤（如只采集带特定注解的 Pod）。
- scrape_configs 中常见的采集参数有哪些？分别什么作用？
参考答案：
- job_name：采集任务名（一组目标的逻辑集合）。
- scrape_interval / scrape_timeout：抓取间隔与超时（默认 15s / 10s）。
- metrics_path：指标路径（默认 /metrics）。
- static_configs / kubernetes_sd_configs：目标列表或服务发现配置。
- relabel_configs：目标标签的增删改（过滤、合并、从元数据提取标签）。
- metric_relabel_configs：采集后对指标本身的标签过滤（常用于降低基数）。
三、 PromQL 查询
- PromQL 的查询类型有哪些？有什么区别？
参考答案：
- 瞬时向量（Instant Vector）：查询某一时刻的指标值（如
up），用于告警规则、仪表盘瞬时值。 - 范围向量（Range Vector）：查询一段时间内的指标序列（如
up[5m]），配合 rate 等函数计算速率。 - 标量（Scalar）：单一数值（如
10）。 - 字符串：查询语句中的常量。
- 核心区别：范围向量带时间窗口，是计算速率/趋势的前提。
- rate、irate、increase、count_over_time 等常用函数的作用与区别？
参考答案：
- rate()：计算区间内每秒平均增长率（
rate(counter[5m])），对 Counter 使用，平滑抗抖动。 - irate()：区间内最后两个样本的瞬时增长率，更敏感但曲线波动大，适合突增告警。
- increase()：区间内的增量（
increase(counter[1h])）。 - count_over_time()：区间内样本数量统计（如判断指标是否一直存在）。
- 选型：趋势分析用 rate，突增检测用 irate；Counter 必须用 rate/increase 换算成速率才有意义。
- PromQL 的聚合操作有哪些？二元运算注意什么？
参考答案：
- 聚合函数：sum、avg、min、max、count、quantile（分位数）、topk/bottomk 等，配合
by/without按标签分组。 - 示例：
sum(rate(http_requests_total[5m])) by (instance)。 - 二元运算：算术（+ - * / %）、比较（> < ==）、逻辑（and or unless）。
- 注意：向量匹配（一对一、一对多、多对一，用 on/ignoring 指定匹配标签）、标签一致性、以及除法时防止除零。
四、 存储
- Prometheus 本地存储的架构与写入流程？
参考答案：
- 基于自研 TSDB，数据按**块（Block）**组织（2 小时一个块），块内按指标分片。
- 写入流程：样本先写入 WAL（预写日志） → 定期压缩成块 → 块合并/压缩（compaction）→ 定期删除过期块（retention）。
- 查询时按块读取并合并。
- 特点：本地存储简单高效，但单机容量有限、不可水平扩展、节点故障数据即丢失。
- 数据保留（retention）与压缩策略如何配置？
参考答案：
- —storage.tsdb.retention.time：保留时长（如 15d、30d），超过自动删除旧块。
- —storage.tsdb.retention.size：按磁盘容量限制（如 50GB）。
- —storage.tsdb.wal-compression：WAL 压缩（默认开启）。
- 注意：本地存储上限受磁盘限制，规划容量 = 样本数 × 时间跨度 × 样本大小；长期保留建议上远程存储。
- Prometheus 远程存储方案有哪些？Thanos 和 VictoriaMetrics 的区别？
参考答案：
- 方案：Thanos（Prometheus 官方生态）、VictoriaMetrics、Mimir/Cortex、云厂商托管（云监控）。
- Thanos：Sidecar 上传块到对象存储（S3），支持全局查询、压缩去重、长期存储；保留 Prometheus 原生查询语义。
- VictoriaMetrics：高性能、低资源占用，兼容 PromQL，支持集群模式与降采样，运维更简单。
- 选型：已有生态选 Thanos；追求性能与省资源选 VictoriaMetrics。
五、 告警
- 告警的完整流程是怎样的？Alertmanager 在其中扮演什么角色？
参考答案：
- 流程：规则评估 → 告警产生 → 发送给 Alertmanager → 分组/去重/抑制 → 路由 → 通知。
- Prometheus 侧：
rules文件定义告警规则（expr 表达式 + for 持续时间 + labels/annotations），评估后进入 Pending → Firing。 - Alertmanager：负责告警分组（同类合并）、去重（同一告警不重复通知）、抑制（严重告警压制次要告警）、静默（临时屏蔽）、路由（按标签分发到不同接收器）。
- 高可用：多实例 Alertmanager 组成集群（Gossip 同步去重状态）。
- 告警规则中的 for（持续时间）参数有什么作用？如何避免告警风暴？
参考答案：
- for：指标持续满足条件多久才触发告警（如
for: 5m），避免瞬时抖动误报。 - 避免告警风暴：设置合理的 for、Alertmanager 分组聚合、抑制规则（父告警压制子告警）、静默窗口、通知限流（repeat_interval）。
- 实践：故障升级时先告警核心指标，避免每个节点每个指标都发一条。
- Alertmanager 的路由树（route）如何配置？静默与抑制的区别？
参考答案：
- route：树形路由，按告警标签（severity、team、instance）匹配分发到不同 receiver（邮件、钉钉、Webhook）。
- 静默（Silence）：主动屏蔽指定告警（按标签匹配），常用于已知维护窗口（如发版、维护）。
- 抑制（Inhibit）：当严重告警存在时，自动抑制相关联的次要告警（如节点挂了就抑制该节点所有 Pod 告警）。
- 区别：静默是”手工/计划”屏蔽，抑制是”规则自动”压制。
六、 监控对象
- node-exporter 监控宿主机，常用的核心指标有哪些？
参考答案：
- CPU：
node_cpu_seconds_total（rate 计算使用率）。 - 内存：
node_memory_MemTotal_bytes/MemAvailable_bytes。 - 磁盘：
node_filesystem_avail_bytes/node_filesystem_size_bytes（使用率、inode）。 - 磁盘 IO：
node_disk_read_bytes_total/node_disk_writes_completed_total。 - 网络：
node_network_receive_bytes_total/node_network_transmit_bytes_total。 - 系统负载：
node_load1/5/15。 - 配合 Blackbox Exporter（探活）、Process Exporter（进程监控）。
- K8s 场景监控容器与工作负载，核心指标来源有哪些？
参考答案：
- cAdvisor（内置 kubelet）：容器 CPU/内存/网络指标（
container_cpu_usage_seconds_total、container_memory_usage_bytes）。 - kube-state-metrics：集群对象状态指标（Pod 重启次数
kube_pod_container_status_restarts_total、Deployment 副本kube_deployment_status_replicas）。 - kubelet 指标：节点资源。
- 关键告警：Pod 频繁重启、容器 OOMKilled、节点磁盘/内存压力、Deployment 副本不可用。
- 数据库与中间件监控常见的 Exporter 有哪些？
参考答案：
- MySQL：mysqld_exporter（连接数、慢查询、主从延迟）。
- Redis：redis_exporter（命中率、内存、阻塞客户端）。
- PostgreSQL：postgres_exporter。
- Kafka：kafka_exporter / JMX Exporter（消费延迟）。
- 消息队列、ES、Nginx（nginx_exporter）等均有对应 exporter；统一通过 Prometheus pull 采集。
七、 可视化
- Grafana 如何与 Prometheus 集成？数据源配置要点？
参考答案：
- 添加数据源：类型选 Prometheus，填 Prometheus 地址（如
http://prometheus:9090），测试连通。 - 配置要点：URL、Access（Server 模式代理或 Browser 直连）、时间范围、TLS/认证（token）、版本。
- 使用：面板用 PromQL 查询、变量（模板）联动（如按集群/命名空间切换）、告警面板与 Alertmanager 联动。
- 生产：多集群用 Grafana 数据源变量 + Thanos 全局查询统一展示。
- 如何设计一套好的监控面板与告警规则？
参考答案：
- USE / RED 方法论：
- 基础设施：USE（Utilization 使用率、Saturation 饱和度、Errors 错误）。
- 业务/服务：RED（Rate 速率、Errors 错误、Duration 延迟）。
- 面板分层：总览（集群/服务健康）→ 明细（单节点/单服务）→ 排障（日志/追踪联动）。
- 告警规则要点：明确阈值与 for、区分 Warning/Critical、annotations 写清处理指引（runbook）。
- 避免”仪表盘堆砌”：每个面板有明确目的，定期 review 无用面板。
- 告警通知如何对接钉钉、企业微信、邮件？
参考答案：
- 统一经 Alertmanager Webhook 对接：钉钉机器人、企业微信机器人、飞书机器人（自定义 Webhook URL + 签名）。
- 邮件：Alertmanager 内置 email receiver（SMTP 配置）。
- 自定义渠道：
webhook_configs发送 JSON 到自建网关，再分发到 IM。 - 实践：通知内容模板化（告警名、级别、值、触发时间、处理链接）、按团队路由、避免通知轰炸（repeat_interval 控制）。
八、 性能与优化
- 什么是高基数（High Cardinality）问题？如何优化？
参考答案：
- 高基数：标签取值组合过多导致时间序列数量爆炸（如把请求 URL、用户 ID、容器 ID 作为标签）。
- 危害：内存/磁盘暴涨、查询变慢、TSDB 写放大。
- 优化：
- 避免高变化值做标签（动态值用 Label 而非常量，禁止业务维度入库）。
metric_relabel_configs丢弃高基数标签。- 降低采集频率、聚合再存储（recording rule 预聚合）。
- 容量评估：序列数 = 指标数 × 标签组合数 × 实例数。
- Prometheus 查询慢、资源占用高，如何排查与优化？
参考答案：
- 排查：
/api/v1/status/tsdb看序列数与块大小、查看高 CPU/内存进程、慢查询（Grafana 面板逐个试）。 - 优化：
- Recording Rule 预聚合高频查询，减少实时计算。
- 控制查询时间范围与步长（step）。
- 降低采集频率、限制指标数量（drop 无用指标）。
- 升级硬件/用远程存储（VictoriaMetrics 更省资源）。
- Prometheus 的分片（Sharding）与联邦（Federation）是什么？
参考答案：
- 分片：把采集目标按 job/区域分散到多个 Prometheus 实例（如按命名空间或区域），每个实例只采集一部分，缓解单机压力。
- 联邦：分层架构——叶子 Prometheus 采集明细，上层 Prometheus 通过
/federate聚合或按需拉取（match[]过滤指标）。 - 场景：多机房/多集群统一监控视图、全局告警。
- 注意：联邦本身也有规模上限，超大规模建议 Thanos/Mimir 全局视图。
九、 故障排查
- 采集目标显示 DOWN 或数据缺失，排查思路是什么？
参考答案：
- 查看 target 状态：
/targets页面 → 看 Scrape Duration、Last Scrape、错误信息。 - 逐层排查：网络连通（curl 目标 /metrics）→ 端口与路径 → 防火墙/网络策略 → exporter 进程是否存活 → 认证/证书（TLS、Basic Auth）→ 服务发现是否正确（relabel 后 target 地址）。
- 注意：
up指标为 0 表示抓取失败，先看抓取错误的具体文本。
- 指标查询结果为空（no data），可能的原因有哪些？
参考答案：
- 指标名拼写错误或标签筛选条件不存在。
- 时间范围问题：查询时间点超出数据保留期（retention）。
- 采集目标 DOWN（数据源没有新样本）。
- 指标被 relabel 丢弃（
metric_relabel_configs）。 - 范围查询窗口与抓取间隔不匹配（如
[5m]内样本太少）。 - 标签匹配大小写/引号问题。
- 收到告警但实际没问题（误报），如何排查？
参考答案：
- 检查 PromQL 表达式是否合理（阈值单位、rate 窗口）。
- 检查 for 持续时间（是否过短导致瞬时抖动触发）。
- 检查数据源本身（exporter 采集值是否异常、是否跨时区/单位换算错误）。
- 检查告警标签（多实例聚合是否把正常实例误并）。
- 检查 Alertmanager 抑制/分组是否失效。
- 用 Query 页面回看触发时刻的实际值曲线。
十、 生产实践
- Kubernetes 集群的 Prometheus 监控方案如何搭建？
参考答案：
- 部署方式：kube-prometheus-stack（Helm 一键：Prometheus + Alertmanager + Grafana + node-exporter + kube-state-metrics + 默认告警规则）。
- 采集面：节点（node-exporter）、容器（cAdvisor）、集群对象（kube-state-metrics）、APIServer/etcd（control-plane 指标）、业务应用（自定义 exporter + ServiceMonitor）。
- 持久化：PVC 挂载 TSDB、长期数据接远程存储。
- 认证：K8s 的 RBAC + Prometheus ServiceAccount 授权访问 kubelet/APIServer 指标。
- Prometheus 版本升级与迁移需要注意什么？
参考答案：
- 升级前：备份配置（prometheus.yml、rules）、记录版本与参数、检查兼容性（PromQL/存储格式跨大版本可能有变化）。
- 升级：替换二进制 → 校验配置（
promtool check config）→ 平滑重启（SIGHUP 重载配置）。 - 迁移：停写 → 拷贝 TSDB 数据目录 → 新实例启动 → 校验数据连续性；或通过 remote_write/读重建。
- 告警规则迁移：
promtool check rules校验语法，注意新版废弃的 PromQL 函数。
- 如何设计一套完整的监控体系（指标分层）？
参考答案：
- 四层指标体系：
- 基础设施层：CPU、内存、磁盘、网络（node-exporter）。
- 容器/云原生层：容器资源、Pod 状态、集群对象（cAdvisor、kube-state-metrics）。
- 中间件/数据库层：MySQL、Redis、Kafka 等 exporter。
- 业务应用层：RED（速率、错误、延迟）、业务埋点（Prometheus 客户端库）。
- 配套：统一标签规范（集群/环境/应用）、告警分级（P1-P4）、值班与 Runbook、定期容量规划与规则 review。
- 目标：从”能监控”到”能告警、能定位、能预防”。
文章分享
如果这篇文章对你有帮助，欢迎分享给更多人！
ylxs的个人博客
文章
14
分类
2
标签
12
总字数
34,324
运行时长
0 天
最后活动
0 天前
站点域名blog.cnylxs.xyz
ylxsv1.0.0
Astrov7.1.3
Nodev22.21.1
pnpmv9.14.4
构建时间2026年8月26日 10:33:04
系统信息Linux / x86_64