共计 2360 个字符，预计需要花费 6 分钟才能阅读完成。
系列文章
- 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 定位.
剖析慢申请 :
同剖析谬误申请相似套路:
- 在 Durations panel 中放大工夫范畴, 发现大略工夫是: 2023-05-09 14:52 左右
- 通过 Dashboard Links 跳转到 ElasticSearch 疾速搜寻仪表板
-
增加 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 编写.