开源监控系统prometheus最佳实践(代码片段)

腾讯技术工程 腾讯技术工程     2023-02-02     159

关键词:

作者:jimmiehan(韩金明) , 腾讯PCG后台开发工程师, Prometheus/Thanos contributor

Prometheus 是目前最流行的开源监控系统之一, 这里以我在基于 Prometheus 构建天机阁 2.0Metrics 子系统的实践谈一谈 Prometheus 的一些最佳实践, 最佳实践的理念是 Prometheus 系统简单稳定高效运行的关键。(注: 天机阁 2.0 是新一代云原生可观测性系统)

埋点思路

最好将原始指标暴露给 Prometheus, 而不是在应用程序端进行计算. 如不需要在应用程序端计算错误率, 而应该埋点总量和错误量两个 counter, 查询时用 PromQL 处理原始数据, 相除得到错误率。

  1. 在线服务: RED 方法, Requests(请求量), Errors(错误量), Duration(耗时);

  2. 离线服务: USE 方法, Utilisation(使用率, 如满载程度), Saturation(饱和度, 如排队任务数), Errors 错误量。

开源项目例子:

内部代码例子:

  • 天机阁 Go SDK tps-sdk-go

  • Opentelemetry Oteam Go 生态 SDK opentelemetry-go-ecosystem

  • 卡片服务 we-feed-card

指标名字

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

name:

  1. name 要做到望文生义, 类似变量名, 应具有良好的可读性. 如 http_requests_total, process_resident_memory_bytes, queue_size, queue_limit. 可参考 k8s/etcd/prometheus/grafana/tidb 等开源项目;

  2. 指标名称是全局的, 携带命名空间可以有效避免命名冲突. 如 process_xxx 表示进程指标, rpc_xxx 表示 RPC 指标, followsys_xxx 表示关注系统业务指标;

  3. 指标名称不要带环境名/应用名, 这些元信息适合用 label 承载, Prometheus 在抓取指标时自动附加, 不需要在埋点代码中定义. 在接入天机阁时会自动给指标附加 app/server/env_name/container_name/namespace 这些元信息;

  4. Prometheus 自定义指标如果要携带中文指标名, 我们约定放在名字为_name 的 label 中。

unit:

  1. 指标名可以带上单位, 如 request_bytes_total , request_latency_seconds;

  2. 值总是使用基本单位, 如 秒/米/字节, 单位展示可读性的事情则交给 Grafana 等展示 UI 来处理。

suffix:

  1. counter 必须以_total 为后缀,OpenMetrics 规范定义

  2. 信息类指标以_info 为后缀, 类型为 gauge,值为 1;

  3. 指标名称不要带 _sum _count _bucket 后缀,以免与 histogram/summary 类型生成的指标名混淆。

指标 label

label 对于多维监控非常有用,一个指标的基数是指标中所有 label 枚举值组合的笛卡尔乘积. 一个进程中一个指标一千的基数是合理的上限。一个进程的总基数是所有指标的基数之和, 一个进程一万总基数是合理的上限,因此:

  1. label 中不适合放 用户 ID/设备 ID/URL 参数 等高基数的值. 单个 label 值不超过 128 个字符;

  2. 避免一个指标过多的 label 组合, 不必要的组合 label 可以拆解为多个指标, 以便降低指标基数, 提高该指标的查询性能. 参考: https://www.robustperception.io/cardinality-is-ke

  3. Metrics 更关注系统级别的高效指标而不是单个请求级别, 不要在 Metrics 中放过多的细节 label, 单独 Metrics 无法解决所有的可观测性问题, 详细的信息应记录 Logs 和 Traces 中, 或者在 Exemplar 带上 traceID, 充分利用三大信号 Metrics/Logs/Traces 关联 一起来观测系统

PromQL

  1. 对于 counter, 要先 rate 后 sum, 因为rate/irate/increase 函数才有 counter 跳变检测

  2. 聚合语句模式中 <aggr-op>([parameter,] <vector expression>) [without|by (<label list>)] without 是移除特定标签, by 则是保留某些标签. without 能在聚合移除高基数标签的同时保留更多的上下文信息;

  3. 向量匹配 on 语句 join info 类型的指标可以达到在查询结果中附加元信息的效果. 例如下面的 promQL 在查询服务内存占用的同时附加实例的 Go 版本。

process_resident_memory_bytesapp="xx", server="xxx",namespace="Production"
* on(instance) group_left(version)
go_infoapp="xx", server="xxx",namespace="Production"

relabel_configs

relabel_configs是很通用很有用的 metrics label processor:

  1. relabel_configs 发生在抓取之前, 可以对目标的每条时间序列附加元数据;

  2. metrics_relabel_configs 发生在抓取之后, 可以对 label 进行重命名/drop 等操作;

  3. alert_relabel_configs 发生在执行规则后发送 alert 至 alertmanager 之前, 如 drop 掉 replica 这个 label 用于 alertmanager 去重;

  4. write_relabel_configs 发生在 remote write 时, 用于 drop 掉 replica label 、drop 某些指标。

查询性能

  1. Prometheus 查询性能与查询语句计算所命中的时间序列数量、样本数以及返回的数据大小 强相关. 正常小查询响应是毫秒级的. 界面展示的大查询(涉及时间序列超过 10k 以上的), 如租户内的所有请求量/server 级别的 CPU 使用列表 这些大查询需要用 recording_rule 定时计算好, 将查询所需的时间序列数降低;

  2. 展示单个信息或表格使用 instantQuery 即时查询, 只返回最新时刻计算的数据即可. 展示时间图形才需要使用 rangeQuery 范围查询, 返回时间区间内计算的所有数据。

图表

  1. 自定义 Dashboard 需要避免一个面板图形中太多的线条, 5 条以内比较合理, 以免图表看不清及卡顿. 对于容器实例级别的指标可以用 topk 函数限制曲线数量;

  2. 对于模板变量下拉, 其语句每次打开 Dashboard之前都会查询 series 接口, 若因为返回结果太大而加载 Dashboard 太慢, 则需要使用 recording_rule 优化;

  3. Grafana 官网面板中心有大量面板可以导入及参考。

recording_rule

对于页面上展示的热查询, 如果涉及时间序列太多, 则会变得缓慢. 一般涉及时间序列大于 10K 的 InstantQuery 和时间序列大于 1K 的 RangeQuery, 是比较昂贵的。

Prometheus 提供了recording_rule功能, 其会定时如 1 分钟对 promQL 表达式定时执行 instantQuery, 执行结果形成新的时间序列, 数据来自内存 TSDB, 完全内存操作, 性能很高。

  1. 例子 1 Istio 可观测性最佳实践

  2. 例子 2 prometheus-kubernetes

  3. 命名 维度:指标名:聚合方式 , 如 server:rpc_request_started_total:rate5m. 参见:

https://prometheus.io/docs/practices/rules/#naming-and-aggregation

alert rule

  1. Awesome Prometheus alerts 包含各种 exporter 导出的指标的告警规则例子;

  2. rule 也遵循 label based 机制, 触发告警时, label 集合是 rule 中自定义的静态 label 加上语句查询结果的 label 组合. 在 alertmanager 中根据 label 进行去重、分组、通知路由、静默、抑制;

  3. 一些告警语句与流量周期相关, 可以在 alertmanager 的配置 route 级别的周期性屏蔽, 也可以在 rule 表达式中使用 on hour/day/month 函数周期屏蔽, 如以下 rule 会在每天 23 点~9 点总是不触发。

expr: |
 xxx < 100
  # 增加条件每天23点~9点总是不触发, 转换为UTC则 hour 15点~1点
  and on() (hour() <= 15 and hour()>= 1)
  1. annotation 中支持 go template 语法, 内置query 函数可以执行额外的查询语句, 这是丰富告警信息的利器, 比如下方配置的语句可以在异常率告警中带上错误码、数量和错误码描述.

annotations:
 description: |
  - with printf "sum(increase(rpc_server_handled_totaltenant_id='%s', app='%s', server='%s',namespace='%s', callee_service='%s', callee_method='%s',code_type='exception'[1m])) by (code_type, code, code_desc)> 0" $labels.teannt_id $labels.app $labels.server $labels.namespace $labels.callee_service $labels.callee_method | query -
          - range $i,$v := . -
          错误码: $v.Labels.code ,数量: printf "%.0f" $v.Value -,描述: $v.Labels.code_desc 
          - end -
          - end -
  1. 可以使用promtool 对 alert rule 进行单元测试, 用于验证告警规则有效性及 template 渲染。

存储

Prometheus tsdb的压缩算法基于Facebook Gorilla 论文, 可以将每个样本点 time+value 16 字节压缩至平均 1.3~2 字节, time 采用 delta-of-delta 方式压缩率比较稳定, value 采用 XOR 方式压缩率跟真实数据相关, 可通过自身指标计算得到实际的样本点大小值。

(rate(prometheus_tsdb_compaction_chunk_size_bytes_sum[2h]) / rate(prometheus_tsdb_compaction_chunk_samples_sum[2h]))

Thanos

  1. 集群中的 Prometheus 需要设置不同的 external-label, 其分片机制依赖 external-label relabel 进行垂直分片. 历史数据基于时间分片

  2. 性能优化: Thanos Query 执行 promQL 时通过 gRPC 双向流方法流式获取样本数据, 如果涉及 Store 节点还需 Range 请求对象存储, 而 Prometheus 直接通过内存或磁盘。由于多次网络调用,Thanos Query 性能会比直接查询 Prometheus 要慢一些, 优化手段主要有:

    1. Query-Frontend 组件对 RangeQuery 按时间分解并行查询和查询缓存;

    2. Store 节点基于 external-label relabel 分片和基于时间范围的分片;

    3. Store 节点开启 index cache, bucket cache;

    4. Compact 节点压缩合并 block 和降采样。

参考:

  1. https://prometheus.io/docs/practices/naming/

  2. https://github.com/OpenObservability/OpenMetrics/blob/main/specification/OpenMetrics.md

  3. 《Prometheus: Up & Running》Brian Brazil

  4. https://www.robustperception.io/blog

  5. https://prometheus.io/blog/

  6. https://github.com/cncf/tag-observability/blob/main/whitepaper.md

  7. https://github.com/timescale/tsbs

最近热文:

开发常用的缩写 你能看懂几个?

TencentOCR 斩获 ICDAR 2021 三项冠军

腾讯程序员视频号最新视频

7.prometheus监控技术与实践---可视化(代码片段)

第7章 可视化7.1 概述 Grafana是一款比较流行的开源时间序列分析与可视化工具。7.2 Grafana安装 7.2.1 在CentOS上安装 1.yum方式安装vim/etc/yum.repos.d/grafana.repo[grafana]name=grafanabaseurl=https://packagecloud.io/grafana/stable/el/7/$b 查看详情

grafana+prometheus监控体系实践(代码片段)

...个单独的仪表板上。1.2、Prometheus介绍Prometheus是一个开源监控系统,集数据采集、存储与展示为一体,功能十分强大,官网架构图如下架构图中各模块功能解析:PrometheusServer:PrometheusSever是Prometheus组件中的核心部分,负责实现... 查看详情

统一观测丨使用prometheus监控nginxingress网关最佳实践(代码片段)

在Kubernetes集群中,我们通常使用“NginxIngress”实现集群南北向流量的代理转发,NginxIngress基于集群内Ingress资源配置生成具体的路由规则。作者:凌竹01NginxIngress网关简介在Kubernetes集群中,我们通常使用“NginxIngress”实现集群南... 查看详情

prometheus监控的最佳实践——关于监控的3项关键指标

...在此次分享中,嘉宾们讨论了如何使用Rancher、WeaveCloud和Prometheus来轻松部署、管理与监控Kubernetes。本文将分享Weave是为何以及如何开发出RED最佳实践方法来使用Prometheus在Kubernetes中监 查看详情

prometheus监控的最佳实践——关于监控的3项关键指标

...在此次分享中,嘉宾们讨论了如何使用Rancher、WeaveCloud和Prometheus来轻松部署、管理与监控Kubernetes。本文将分享Weave是为何以及如何开发出RED最佳实践方法来使用Prometheus在Kubernetes中监 查看详情

在微服务架构下基于prometheus构建一体化监控平台的最佳实践

随着Prometheus逐渐成为云原生时代的可观测事实标准,那么今天为大家带来在微服务架构下基于Prometheus构建一体化监控平台的最佳实践和一些相关的思考,内容主要包括以下几个部分:微服务、容器化技术演进的监控之痛云原生... 查看详情

最佳实践|从producer到consumer,如何有效监控kafka

对于运维人而言,如何安装维护一套监控系统,或如何进行技术选型,从来不是工作重点。如何借助工具对所需的应用、组件进行监控,发现并解决问题才是重中之重。随着Prometheus逐渐成为云原生时代可观测标准,为了帮助更... 查看详情

最佳实践|springboot应用如何快速接入prometheus监控

...行持续地观测,面向SpringBoot应用我们该如何快速实现Prometheus监控接入。本文为大家详细讲解完整接入流程与接入事项!作者࿱ 查看详情

2.prometheus监控技术与实践---prometheus基本概念及部署(代码片段)

2.1 Prometheus架构 关键工作流程可以总结如下: 1.Prometheus服务器周期性的或者在设定的时间段内,可以通过下面的方式获取内容。 a)从配置好的job或者exporter中拉取metric b)接收从Pushgateway推送过来的metric c)从其他的Pro... 查看详情

kubernetes第七篇:使用kubernetes部署prometheus+grafana监控系统(kubernetes工作实践类)(代码片段)

文章目录一、前言二、K8s监控系统架构2.1Prometheus简介2.2Prometheus架构2.3Prometheus知识普及三、K8s监控系统搭建3.1三类数据采集metrics3.2Prometheus+Grafana3.3实践一下:将prometheus+grafana搭建起来3.3.1搭建3.3.2分步测试3.3.2.1安装nodee... 查看详情

[系统性能优化实践]jvm进阶实战之监控工具(prometheus)(代码片段)

0Prometheus概述0.1简介Prometheus是一个开源的系统监控和报警系统;现在已加入到CNCF基金会,成为继k8s之后第二个在CNCF托管的项目在kubernetes容器管理系统中,通常会搭配prometheus进行监控,同时也支持多种exporter采集数据,还支持pus... 查看详情

elasticsearchelasticsearch日志场景最佳实践(代码片段)

...场景,大幅度降低维护多套专用系统的成本,在开源社区非常受欢迎。然而Elasticsearch为满足多种 查看详情

3.prometheus监控技术与实践---exporter(代码片段)

第3章 Exporter 在prometheus中,Exporter是重要的组成部分,在实际监控样本数据的收集是由Exporter完成的,prometheus服务器只需要定时从这些Exporter提供的http服务获取监控数据即可。3.1 概述 Exporter本质上是将收集的数据... 查看详情

深入浅出开源监控系统prometheus(上)(代码片段)

本文首发于vivo互联网技术微信公众号?链接:https://mp.weixin.qq.com/s/4NC4spF6cEvXuIBKVbIU7A作者:ZhangShuoPrometheus是继Kubernetes(k8s)之后,CNCF毕业的第二个开源项目,其来源于Google的Borgmon。本文从“监控”这件事说起,深入浅出Prometheus... 查看详情

深入浅出开源监控系统prometheus(上)(代码片段)

本文首发于vivo互联网技术微信公众号?链接:https://mp.weixin.qq.com/s/4NC4spF6cEvXuIBKVbIU7A作者:ZhangShuoPrometheus是继Kubernetes(k8s)之后,CNCF毕业的第二个开源项目,其来源于Google的Borgmon。本文从“监控”这件事说起,深入浅出Prometheus... 查看详情

在微服务架构下基于prometheus构建一体化监控平台的最佳实践

...书",获取后台回复“k8s”,可领取k8s资料随着Prometheus逐渐成为云原生时代的可观测事实标准,那么今天为大家带来在微服务架构下基于Prometheus构建一体化监控平台的最佳实践和一些相关的思考,内容主要包括... 查看详情

4.prometheus监控技术与实践---服务发现(代码片段)

第4章 服务发现 prometheus服务发现能够自动化检测分类,并且能够识别新目标和变更目标。也就是说,可以在容器平台或者云平台中,自动发现并监控新目标或变更目标,动态进行数据采集和处理。目前prometheus版... 查看详情

redis最佳实践(代码片段)

...概念与最佳实践。架构与概念Redis是一个使用ANSIC编写的开源、支持网络、基于内存、可选持久性的键值对存储数据库。从2015年6月开始,Redis的开发由RedisLabs赞助,而2013年 查看详情