Prometheus监控的最佳实践——关于监控的3项关键指标
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Prometheus监控的最佳实践——关于监控的3项关键指标相关的知识,希望对你有一定的参考价值。
本文来自Weaveworks的工程师Anita Burhrle在Rancher Labs与Weaveworks联合举办的Online Meetup上的技术分享。在此次分享中,嘉宾们讨论了如何使用Rancher、Weave Cloud和Prometheus来轻松部署、管理与监控Kubernetes。本文将分享Weave是为何以及如何开发出RED最佳实践方法来使用Prometheus在Kubernetes中监控应用程序的。
什么是Prometheus监控?
最近有很多关于Prometheus的消息,尤其是在Kubernetes中监控应用程序这方面。深入RED方法之前,我们先了解一些背景内容。应用程序运行在容器上并由Kubernetes负责调度,在此环境中它们是高度自动化并且动态的。传统的监控工具一般是基于服务器,只监控静态的服务,所以当要在这种动态环境监控应用程序时,传统的监控工具往往很难满足这一需求。
这时就需要Prometheus出马了。
Prometheus是一个开源项目,最初由SoundCloud的工程师开发。它专门用于监控那些运行在容器中的微服务。每经过一个时间间隔,数据都会从运行的服务中流出,存储到一个时间序列数据库中,这个数据库之后可以通过PromQL语言查询。另外,因为数据是以时间序列存储的,当出现问题时,可以根据这些时间间隔进行诊断,另外还可以预测基础设施的长期监控趋势----这是Prometheus的两大功能。
在Weaveworks,我们把服务搭建在Prometheus的开源分布上,并且创建了一个可扩展、多租户的版本,这是我们软件即服务概念的一部分,称为Weave Cloud。
现在,该服务已经运行了几个月,同时也使用Weave Cloud监控自己本身,在这个过程中我们积累到了一些有关监控云本机应用程序的经验,并根据这些经验设计了一个系统来确定在检测代码前需要测量什么。
该检测什么?
在搭建Prometheus监控时,确定需要收集的指标类型十分重要,这些指标和应用程序相关。选择的指标可以简化故障发生时排除故障的流程,并且还可以在服务和基础设施上保持很高的稳定性。为帮助理解instrument的重要性,我们定义了一个称之为RED方法的系统。
RED方法遵循Four Golden Signals中提及的原则,聚焦于检测最终用户在使用web服务时关心的东西。
在RED方法中,我们通过监控三项关键指标来管理架构中的每个微服务:
(Request)Rate – 你的服务所服务的每秒的请求数
(Request)Errors – 每秒失败的请求数
(Request)Duration – 每个请求所花费的时间,用时间间隔表示
RED方法希望由Rate、Errors、Duration三项指标涵盖最典型的Web服务问题。同时这些指标还能够反映出请求的错误率。通过这三项指标,我们就能监测到通常情况下会影响客户体验的问题。
如果想要获得更细节的信息,还需要用到Saturation指标。Saturation指标用在USE(Utilization Saturation and Errors)方法中,它指的是一种带有额外作业的资源,而该资源不能够提供服务,因此必须添加到队列中以备后续处理。
USE vs. RED方法
对比两种方法,USE方法更侧重于监控的性能,并以此为出发点寻找影响性能问题的根本原因以及其他系统的瓶颈。
在理想状态下,我们可以在监控应用程序时同时使用USE和RED方法。
为什么要对每个服务衡量相同的指标
从监控的角度来看,如果能处理好每项服务,你的运营团队就可以在此基础上继续扩展服务。
扩展性对运营团队意味着什么?
我们从这个角度看待问题,一个团队可以支持多少个服务。在理想状态下,一个团队可以支持的服务数量和团队规模无关,而取决于其他因素,比如SLA协议的响应类型以及是否需要全天候覆盖等等。
如何将可支持的服务数量与团队规模去藕化?
办法是让每一个服务都变得一样。这既减少了团队针对特定的服务进行培训的数量,还减少了在高压事件响应场景或者所谓“认知负载”这些针对特定服务的特殊情况发生时,呼叫者需要记录的内容。
容量规划:
考虑QPS(每秒查询次数)和延迟
自动化任务以及发出警报:
RED方法的优点在于它可以帮助你考虑如何在仪表板中显示信息。通过这三个指标,你可以对仪表板的布局进行调整,让它更易于阅读,并在问题发生时发出警报。例如,一个布局可能意味着 --- 每个服务都有一个不同的Weave Cloud记事本,包含了PromQL查询的请求&错误,以及每个服务的延迟。
毫无疑问,如果把所有的服务都视为一样的,那么将会更加易于自动化执行重复任务。
PromQL查询
在Weave Cloud上监控RED方法中的指标
局限性
事实上,这种方法(RED)仅适用于请求驱动的服务——比如,它在处理面向批处理的服务或者流服务时会发生错误。对于请求驱动它也不是完全适用,当需要监控其他东西——比如主机CPU&内存或者缓存资源时,USE方法表现的更好。
原文来源:Rancher Labs
本文出自 “12452495” 博客,请务必保留此出处http://12462495.blog.51cto.com/12452495/1971929
以上是关于Prometheus监控的最佳实践——关于监控的3项关键指标的主要内容,如果未能解决你的问题,请参考以下文章
在微服务架构下基于 Prometheus 构建一体化监控平台的最佳实践