prometheus数据模型以时间序列为基石，一条完整时序数据=指标名称+标签集+时间戳+浮点数值；指标定语义与类型，标签定多维区分，二者组合唯一标识时序，支撑高效查询与监控分析。
Prometheus 的数据模型围绕“时间序列”展开，每个指标由名称、一组标签、时间戳和浮点数值共同构成。它不依赖预定义 schema，而是靠 metric name + labels 唯一标识一条时序数据。理解这个结构，是写对 PromQL、配好采集、避开高基数陷阱的前提。
Metric 名称与标签设计要点
指标名应语义清晰，推荐使用 domain_subsystem_measurement_unit 格式，例如 http_server_requests_duration_seconds。后缀如 _total（Counter）、_bytes（Gauge）能直观提示类型和单位。
标签用于多维切片，但不是越多越好：
- 避免用户 ID、请求 ID、URL 路径等高基数字段——单个标签值超过 1000 就可能拖慢查询甚至压垮内存
- 优先用稳定、可枚举的维度，如
job、instance、method、status、endpoint - 双下划线开头的标签（如
__address）是 Prometheus 内部保留，不可手动设置
四类 Metrics 类型的实际用途
虽然底层都存为时间序列，但类型决定了你该怎样查询和解读：
-
Counter（计数器）：只增不减，记录累计事件数。典型如
http_requests_total。重启后归零，所以不能直接看值大小，而要用rate()或increase()算速率或增量 -
Gauge（仪表盘）：瞬时值，可升可降。适合内存、温度、队列长度等。可直接查当前值，也可用
delta()看一段时间变化量 -
Histogram（直方图）：按预设区间（
le="0.1"、le="0.2"…）统计分布，自带_bucket、_sum、_count三个子指标。延迟分析常用，分位数需用histogram_quantile() - Summary（摘要）：客户端计算分位数并上报，适合低延迟场景；但无法聚合，跨实例分位数不准，生产环境通常倾向 Histogram
数据采集机制与常见方式
Prometheus 默认采用 Pull 模式，主动向目标的 /metrics 端点发起 HTTP 请求获取指标文本：
- 目标服务需集成 Prometheus 客户端库（Go/Python/Java 等），暴露符合格式的指标
- 非原生系统（如 MySQL、Redis、硬件传感器）通过 Exporter 转换：Node Exporter 抓主机指标，Blackbox Exporter 做探针检测
- 短生命周期任务（如 CronJob）无法被 Pull，改用 Pushgateway 中转推送
- Kubernetes 环境中，常结合
kubernetes_sd_configs自动发现 Pod、Service，再配合 relabel_configs 过滤和打标
样本格式与存储本质
你在 /metrics 页面看到的是纯文本格式：
# TYPE http_requests_total counter
http_requests_total{method="GET",status="200"} 12487
而实际存入 TSDB 的每个样本包含三要素：毫秒级时间戳 + float64 数值 + metric name 和 label 集合。Prometheus 不存储原始字符串，而是将指标名和标签做内部索引，提升查询效率。
