标签：latency seconds 标签 request 累计 Prometheus 事件 精要

关于可观测性

记录所有事件的所有上下文，对调试或者了解当前系统的状况，于技术、于业务而言，都是非常有益的，但是需要处理和存储海量的数据，这是不现实的。

大概有四种方式来减少数据量，让处理和存储这些数据变得可实现：

• Profiling（性能剖析）

  特点：只采样短期内发生的事件，包含完整上下文

  例子：tcpdump

• Tracing（追踪）

  特点：按比例采样所有事件的一部分（N%），关注调用链

  例子：jaeger

• Logging（日志）

  特点：只记录特定事件，上下文丰富，大致分为：

  • 事务日志（例如涉及钱，不能丢失）
  • 请求日志（尽量不丢失，丢失了问题也不大）
  • 应用日志（例如启动消息、后台任务，主要是给人阅读，不会有很多）
  • 调试日志（量多，只应用在调试情景，可以随意丢失）

  各种日志的处理方式不能一概而论

• Metrics（监控指标）

  特点：关注计数，上下文几乎没有

指标类型

Counter

累计值，只增不减。通常用来记录事件累计发生的次数，用于表现事件在时间轴上发生（次数）：

例：rate(user_logins_total[1m])

Gauge

快照值。通常用来直接表现状态在时间轴上的变化：

例如：temperature

Summary

对应两个累计值，只增不减。一个记录事件累计发生的次数，一个记录事件属性的累计和，主要用于表现事件在时间轴上发生（与否），以及事件发生时的属性均值：

例如：rate(request_latency_seconds_sum)/rate(request_latency_seconds_count)

如果使用了 quantile，还会有若干个 Gauge 值对应事件属性百分位值的快照：

50%的请求延迟小于这个值：request_latency_seconds{le="0.5"}

75%的请求延迟小于这个值：request_latency_seconds{le="0.75"}

95%的请求延迟小于这个值：request_latency_seconds{le="0.9"}

注意：百分位值在客户端计算，需要消耗客户端资源。

Histogram

对应 2 + N 个累计值，只增不减。一个记录事件累计发生的次数，一个记录事件属性的累计和，其余N个记录事件在N个属性值区间上累计发生的次数：

前2个累计值的使用和 Summary 类似。

剩余N个累计值：

请求延迟值（秒）命中 [0, 0.1] 区间的累计次数：

​ request_latency_seconds_bucket{quantile="0.1"}

请求延迟值（秒）命中 [0, 0.5] 区间的累计次数：

​ request_latency_seconds_bucket{quantile="0.5"}

请求延迟值（秒）命中 [0, +Inf] 区间的累计次数 = 请求累计次数：

​ request_latency_seconds_bucket{quantile="+Inf"}

90%的请求延迟小于这个值（百分位值）：

​ histogram_quantile(0.9, rate(request_latency_seconds_bucket[1m]))

注意：计算发生在服务端，计算结果的精度和 bucket 区间个数、每个区间的大小有关。

指标命名

• snake case
• 使用（无前缀）基本单位的复数作后缀，例如seconds、bytes，而不是 milliseconds、kilobytes
• counter 再带上 total 后缀

监测的对象

服务

• 在线服务

  监测要点：request rate, latency, error rate

• 离线服务

  监测要点：queued work, in-progress work, work process speed, error

  可以类比为水池，需要关注水位、水位变化速度（水流入速度 - 水流出速度）

• 批处理作业

  通常是定时作业，并非24小时运行

  监测要点：和离线服务类似，但是需要 push gateway 辅助收集指标

库

关注报错以及打日志的地方

何时使用标签

指标使用了某标签K=V以后，如果无视标签K进行聚合，得到的结果还有意义，说明可以使用这个标签。

容量规划

可以简单地认为 prometheus 最多能处理 1000 万个时间序列

再预设最多有 1000 个被监控的实例，每个实例平均能占用 10000 个时间序列

1 个 Gauge/Counter 占用的时间序列数 = 1 x （标签1的的值个数） x （标签2的的值个数）x（标签3的的值个数）x ... x （标签N的的值个数）

注意：要排除 instance 标签，已经被当成 1000 个值计算过了

1 个 Summary 占用的时间序列数 = （同 Gauge/Counter） x （2 + quantile 数）

1 个 Histogram 占用的时间序列数 = （同 Gauge/Counter） x （2 + bucket 区间数）

大部分指标占用的时间序列应该少于10个

少部分指标占用的时间序允许在100个左右

如果把某个标签的值展开，变成多个指标（标签值移入到指标名），例如 http_requests_total => http_get_requests_total, http_post_requests_total, http_put_requests_total ... 占用的时间序总数并没有发生变化，还加大了聚合的难度

标签：latency,seconds,标签,request,累计,Prometheus,事件,精要
来源： https://www.cnblogs.com/roy2220/p/14839051.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。