如果去做，还有一丝希望；但是不去做，就毫无希望

技术分享

个人总结

🔇 2025年终总结

🏐 我的MBTI

🧵prometheus为代表的监控构建

type

status

date

slug

summary

背景

系统稳定性差，接口p99延时长；队列消费时间久；系统ttft久；亟需一个完整的监控系统来指导线上问题预测与排查。

相关的基础概念

时间序列（Time series）：由固定的 metric name + labels 唯一标识的一组（有时间戳的）样本点序列。

例：http_requests_total{job="api",method="GET",code="200"} 是一条时间序列。

样本（Sample）：时间序列在某个时间点的一个数值（value, timestamp）。

指标（Metric / Metric family）：同一名称的时间序列集合（可能有不同 label 组合）。

Label（标签）：键值对，用于给时间序列打维度（如 instance, job, method）。Label 是查询与聚合的基础，但也会带来 cardinality（基数）问题。

PromQL：Prometheus 的查询语言，用于选择/聚合/转换时间序列（Grafana 中的大部分面板会用到 PromQL）。

Prometheus 的生态系统由多个组成部分组成，其中许多是可选的：

prometheus Server：用于抓取和存储时间序列数据

client libraries：用于检测应用程序代码的客户端库

push gateway：用于短时任务的推送接收器

exporter：用于 HAProxy、StatsD、Graphite 等服务的专用输出程序

altermanager：处理告警的警报管理器

Prometheus架构

Prometheus 的核心职责包括：

采集数据（Scrape）

定期从各服务的 /metrics 接口抓取最新指标数据。

存储数据（TSDB）

将时间序列（time series）存储在它自己的时序数据库中。

提供查询（PromQL）

Prometheus 内置查询引擎，可通过 PromQL 查询任意时间序列数据。

触发告警（Alerting）

结合 Alertmanager 可以发出告警。

Grafana架构

Grafana 不存储指标数据，它的核心工作是：

从 Prometheus（或其他数据源）读取 Metrics

Grafana 只是对 Prometheus 发起 PromQL 查询。

渲染可视化面板

把 PromQL 返回的数据绘制成折线图、柱状图、仪表盘等。

构建仪表盘（Dashboard）

让运营人员、研发、SRE 可以快速浏览服务状态。

提供权限系统、变量、模版

用于团队协作与面板复用。

指标分类

Counter（计数器）

含义：单调递增的数值（只能加，不能减，除了重启会重置为 0）。用于记录次数、累计字节等。

PromQL 常用：

rate(http_requests_total[5m]) — 返回每秒速率（用在图上是最常用的）。
increase(http_requests_total[1h]) — 返回区间内的增长量（适合展示“过去 1 小时新增多少请求”）。

适用场景：请求数、错误数、处理的字节数、任务完成次数等。

Go（client_golang）示例：

Gauge（仪表）

含义：可以任意增减的数值（会记录当前值）。适合瞬时值或可上/下浮动的量。

适用场景：当前并发数、内存使用量、队列长度、温度等。

Go 示例：

Histogram（直方图）

含义：将观测值按预定义的 buckets（桶）统计成分布，同时导出 _bucket（每个桶的累计计数）、_sum（总和）、_count（观测次数）。

重要点：

Prometheus 本身不直接存储分位数；要通过 histogram_quantile() 在查询端近似计算分位点（基于桶的累积计数）。
直方图更适合服务端对延迟/大小分布的观测（尤其适用于高 QPS 环境）。

PromQL 典型用法：

histogram_quantile(0.99, sum(rate(request_duration_seconds_bucket[5m])) by (le)) — 估算 99% 响应时间。
注意 by (le)：le 是桶的上限标签。

Go 示例（可选用 Summary）：

桶设计注意：桶是固定的、离散的。应该根据你的延迟分布定制（对数/倍数型通常合适）。太多桶影响性能；太少桶影响精度。

Summary（摘要）

含义：直接在客户端（instrumentation）计算分位数（滑动窗口/流式算法）并导出；同时也导出 _sum 和 _count。

特性与区别：

Summary 会在 client 侧计算 quantiles（所以每个实例可能不同，不易合并），不适合在 Prometheus 服务端进行跨实例的精确分位计算。
如果你要跨实例计算整体的 p99，不要只用 Summary；用 Histogram + histogram_quantile 更可合并（推荐后端服务使用 Histogram）。