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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值