乐趣区

关于运维:Grafana系列统一展示12RED-Method-Dashboard

jiezi

系列文章

  • Grafana 系列文章

概述

目前对于监控指标, 支流的有 3 个办法 (Method):

  • RED : Rate（拜访速率）, Errors（谬误）, Duration（响应时长）– 由 @tom_wilkie 引入
  • USE : Utilization（利用率）, Saturation（饱和度）, and Errors（谬误）– 由 @brendangregg 引入
  • Four Golden Signals:Latency (响应提早, 和 Duration 相似), Traffic (对你的零碎有多大的需要, 和 Rate 相似), Errors, Saturation. 基本上就是 RED + Saturation.

倡议同时应用 RED 和 USE Method, 其中:

  • RED Method 关怀你的用户以及他们有多高兴
  • 而 USE Method 则是关怀你的机器以及它们有多高兴

典型 RED Method 监控指标

如果是通过 Prometheus 监控实现, 那么典型的指标示例如下:

Rate:

sum(rate(request_duration_seconds_count{job="…"}[1m]))

Errors:

sum(rate(request_duration_seconds_count{job="…", status_code!~"2.."}[1m]))

Duration:

histogram_quantile(0.99, sum(rate(request_duration_seconds_bucket{job="…"}[1m])) by (le))

在这里, Duration 举荐应用 50th/90th/99th percentile, 这些会更准确地反映用户真正关怀的问题, 同时能够联合 Average Duration 来作为参考.

典型的仪表板示例如下:

实战 – 基于 ES Access Log 的 RED Method Dashboard

这也是无奈之举, 开发并未基于 Prometheus Client 实现 Requests 的相干指标. 而是只记录了 Access 日志, 并将日志吐到 ES 中, 那么咱们只能 workaround, 通过 ES 统计日志和关键词、Terms 以实现相似的成果。实现都是能够实现的，然而在理论应用中，也的确发现基于 ES 的监控，性能会差很多。

具体成果如下：

Rate（只能实现每分钟申请数）：

以 2xx 举例, Query:

request_path.keyword:(-"/actuator/health" -"/metrics" -"*info*" -"*Eureka*") AND status_code:[200 TO 299]

如上, 排除微服务中场景的监控检查和监控类 url.

下方的 Metric:

Errors:

就是 5xx:

request_path.keyword:(-"/actuator/health" -"/metrics" -"*info*" -"*Eureka*") AND status_code:[500 TO 599]

Duration:

Query 不在辨别 status code:

origin_path.keyword:(-"/actuator/health" -"/metrics" -"*info*" -"*Eureka*")

Percentiles 配置如下:

  • Metric: Percentiles
  • Terms 抉择 latency (在我这边的实战中, latency 记录的是 Duration)
  • Values 抉择 50,99 即计算 50th, 99th percentiles

Average 配置如下:

  • Metric: Average
  • Terms 抉择 latency

最终的成果就是如下:

RED Method 的应用

为了更不便基于 RED Method 的应用, 能够进行下钻排查, 还基于 Grafana Dashboard Links 做了个简略的关联, 不便跳转.

📝Notes:

对于 Grafana Dashboard Links, 应该会在后续文章中具体介绍. 😜😜😜

咱们来基于上图, 做一下实战剖析.

在过来 7 天里, 发现最大并发 Error 数有 8 个, 最慢 p99 duration 有 6.29s(高于阈值 5s). 咱们心愿找到对应的 Error 和慢的申请的具体日志.

剖析 Errors

对于 Errors, 点击 Rate & Errors Panel 的 5xx legend, 会显示如下:

在该 panel 中框选, 放大时间段, 如下:

发现产生工夫为: 2023-05-11 15:58 左右, 点击右上角的 Dashboard Link, 会跳转到 ElasticSearch 疾速搜寻仪表板 (跳转时会带上同样的工夫范畴).

因为是剖析谬误日志, 所以能够 status_code varible 中, 抉择: 500 TO 599, 间接找到相干日志, 如下:

并能够进一步通过 Logs to Trace 定位.

剖析慢申请 :

同剖析谬误申请相似套路:

  1. 在 Durations panel 中放大工夫范畴, 发现大略工夫是: 2023-05-09 14:52 左右
  2. 通过 Dashboard Links 跳转到 ElasticSearch 疾速搜寻仪表板

  3. 增加 ad hoc filter: latency>5000, 找到具体日志:

🎉🎉🎉

总结

本文介绍了 3 种罕用的监控办法:

  • USE Method(面向机器)
  • RED Method(面向用户)
  • Google SRE Four Golden Signals(RED + Saturation)

并重点基于 RED Method 介绍:

  • 基于 Prometheus + Grafana 的指标获取和展现
  • 基于 ElasticSearch + Grafana 的指标获取和展现

以及理论基于 RED Method 剖析用例.

心愿对各位读者有所帮忙.😄😄😄

参考文档

  • The RED Method: How to Instrument Your Services | Grafana Labs

三人行, 必有我师; 常识共享, 天下为公. 本文由东风微鸣技术博客 EWhisper.cn 编写.

退出移动版