2. Prometheus 指标体系：数据模型、指标类型与采集模式
在 eBPF 制品库的监控体系中，Prometheus 指标体系是连接内核观测数据与运维决策的桥梁。理解其数据模型、指标类型以及采集模式，是设计可靠接入方案和回滚策略的前提。本节将系统梳理这些核心概念，并结合 eBPF 场景给出具体映射。
2.1 Prometheus 数据模型
Prometheus 将所有采集到的数据定义为时间序列（Time Series），每个时间序列由 指标名称（Metric Name） 和一组 标签（Labels） 唯一标识。其核心结构如下：
<metric_name>{<label_name1>=<label_value1>, <label_name2>=<label_value2>, ...} <value> <timestamp>| 组件 | 说明 | eBPF 制品库示例 |
|---|---|---|
| Metric Name | 描述被监控指标的含义，遵循 [a-zA-Z_:][a-zA-Z0-9_:]* 格式 |
ebpf_probe_drops_total |
| Labels | 键值对，用于维度扩展和过滤 | {probe="tcp_connect", kernel="5.15", status="oom"} |
| Sample | 一个时间点的浮点数值 | 1287 |
| Timestamp | 毫秒级 Unix 时间戳，由服务端自动注入 | 1710000000000 |
设计原则： 标签基数（Cardinality）是 eBPF 指标接入的关键风险点。每个 eBPF 探针可能携带进程 PID、容器 ID、cgroup 路径等高频变化标签，若不加约束直接暴露，会导致 Prometheus 存储爆炸。建议在 exporter 层对高基数标签做聚合或降维处理。
2.2 指标类型详解
Prometheus 客户端库提供四种核心指标类型，每种类型在 eBPF 监控场景中有不同的适用模式。
| 类型 | 语义 | 典型 eBPF 用例 | 查询示例 |
|---|---|---|---|
| Counter | 只增不减的累计值，系统重启或重置时归零 | eBPF 程序丢包总数、系统调用次数、内存分配次数 | rate(ebpf_probe_drops_total[5m]) |
| Gauge | 可增可减的瞬时值 | 当前 eBPF map 大小、正在运行的探针数量、内核内存使用量 | ebpf_map_entries |
| Histogram | 对观测值进行分桶计数，可计算分位数 | eBPF 程序执行延迟、网络包处理耗时、IO 大小分布 | histogram_quantile(0.99, rate(ebpf_probe_duration_seconds_bucket[5m])) |
| Summary | 类似 Histogram，但由客户端预计算分位数 | 对延迟敏感且需要精确分位数的场景（如 tail latency 监控） | ebpf_probe_duration_seconds{quantile="0.99"} |
选型建议： 在 eBPF 制品库中，Counter 和 Histogram 是最常用的组合。Counter 用于监控事件总量和速率，Histogram 用于分析性能分布。Gauge 适合展示当前状态快照。Summary 在客户端计算分位数，适合对服务端资源有限制的场景，但无法跨进程聚合。
2.3 Pull 模式与 Push 模式
Prometheus 原生采用 Pull 模式，即 Prometheus Server 主动从目标端点（/metrics）抓取数据。但在 eBPF 场景中，由于探针运行在宿主机内核态，且可能存在于短期容器或 Serverless 环境中，Push 模式 作为补充方案被广泛采用。
关键区别： Pull 模式要求目标端点长期可达且状态可枚举；Push 模式通过中间网关（Pushgateway）接收数据，适合生命周期短或无法被直接抓取的作业。
2.4 eBPF 场景下的模式选择策略
在 eBPF 制品库的 Prometheus 指标接入中，Pull 与 Push 模式并非互斥，而是根据探针生命周期和部署拓扑进行组合：
- 常驻探针（DaemonSet / 系统服务）：优先使用 Pull 模式。Prometheus 通过服务发现（如 Kubernetes ServiceMonitor）直接抓取每个节点上的 eBPF Exporter 端点。
- 临时诊断探针（一次性捕获 / 故障注入）：使用 Push 模式。探针在启动时连接 Pushgateway，将采集到的内核事件指标推送后退出，避免因探针消失导致指标丢失。
- 高基数聚合场景：在 Push 模式下，可以在 Pushgateway 侧或 Exporter 侧对高基数标签（如 PID、容器 ID）进行预聚合，降低 Prometheus 存储压力。
回滚关联： 在回滚策略调优中，Push 模式下的 Pushgateway 指标过期问题需要特别关注。当回滚触发旧版 eBPF 探针下线时，Pushgateway 中残留的旧指标可能导致告警误报。建议在回滚流程中增加 Pushgateway 指标清理步骤，或为指标设置合理的
push_timeout_seconds 和过期标记。
2.5 指标接入最佳实践清单
- 命名规范：eBPF 指标统一使用
ebpf_前缀，例如ebpf_probe_duration_seconds，避免与业务指标混淆。 - 标签控制：每个指标标签数量建议不超过 10 个，避免将 PID、FD 等极高基数标签直接暴露。
- Histogram 分桶设计：根据 eBPF 探针的实际延迟分布设置桶边界，例如
[0.001, 0.005, 0.01, 0.05, 0.1, 0.5, 1.0]秒。 - Pushgateway 生命周期管理：为 Push 模式设置合理的
push_interval和指标过期 TTL，防止陈旧数据干扰回滚决策。 - 指标注册与注销：在 eBPF 探针加载时动态注册指标，在探针卸载时确保指标从 Prometheus 客户端库中正确注销，避免内存泄漏。
实战检查点： 在接入 eBPF 制品库的 Prometheus 指标后，建议使用
promtool check metrics 验证指标命名和标签合规性，并使用 /metrics 端点直接观察原始输出，确保数据模型符合预期。