Prometheus最佳实践

小豹子的技术笔记

于 2024-09-26 11:47:56 发布

阅读量394

点赞数 18

文章标签： prometheus

本文链接：https://blog.csdn.net/weixin_38687619/article/details/142552212

版权

一、埋点思路（上报什么数据）

在线服务: RED 方法, Requests(请求量), Errors(错误量), Duration(耗时)；
最好将原始指标暴露给 Prometheus, 比如不需要在进程中计算错误率, 上报总量和错误量两个 counter, 查询时用 PromQL 处理原始数据, 相除得到错误率

二、指标命名（如何定义指标）

指标命名的整体结构建议使用 name_unit_suffix , 指标名符合正则 [a-zA-Z*][a-zA-Z0-9_]\*

name:

name 要做到望文生义, 类似变量名, 应具有良好的可读性. 如 http_requests_total, process_resident_memory_bytes, queue_size, queue_limit. ；
指标名称是全局的, 携带命名空间可以有效避免命名冲突. 如 process_xxx 表示进程指标, rpc_xxx 表示 RPC 指标, followsys_xxx 表示关注系统业务指标；
指标名称不要带环境名/应用名, 这些元信息适合用 label 承载, Prometheus 在抓取指标时自动附加, 不需要在埋点代码中定义；

unit:

指标名可以带上单位, 如 request_bytes_total , request_latency_seconds；
值总是使用基本单位, 如秒/米/字节, 单位展示可读性的事情则交给 Grafana 等展示 UI 来处理。

suffix:

counter 必须以_total 为后缀，OpenMetrics 规范定义；
信息类指标以_info 为后缀；
指标名称不要带 _sum _count _bucket 后缀，以免与 histogram/summary 类型生成的指标名混淆。

三、label命名（如何定义维度）

label 对于多维监控非常有用，一个指标的基数是指标中所有 label 枚举值组合的笛卡尔乘积 (比如一个指标有三个label，每个label都有10个可能的值，最终的基数就是10*10*10 = 1000)。 一般一个指标一千的基数是合理的上限。一个进程的总基数是所有指标的基数之和, 一个进程一万总基数是合理的上限，因此:

label 中不适合放用户 ID/设备 ID/URL 参数/时间戳等高基数的值. 单个 label 值不超过 128 个字符；
避免一个指标过多的 label 组合, 不必要的组合 label 可以拆解为多个指标, 以便降低指标基数, 提高该指标的查询性能.
Metrics 更关注系统级别的高效指标而不是单个请求级别, 不要在 Metrics 中放过多的细节 label, 单独 Metrics 无法解决所有的可观测性问题, 详细的信息应记录 Logs 和Trace中，或者使用ck，mysql等存储详细情况

四、查询性能

Prometheus 查询性能与查询语句计算所命中的时间序列数量、样本数以及返回的数据大小强相关. 正常小查询响应是毫秒级的. 界面展示的大查询(涉及时间序列超过 10k 以上的), 这些大查询需要用 recording_rule 定时计算好, 将查询所需的时间序列数降低；
展示单个信息或表格使用 instantQuery 即时查询, 只返回最新时刻计算的数据即可. 展示时间图形才需要使用 rangeQuery 范围查询, 返回时间区间内计算的所有数据。