其他分享
首页 > 其他分享> > Metrics:让微服务运行更透明

Metrics:让微服务运行更透明

作者:互联网

Metrics是什么

直译是“度量”,不同的领域定义有所区别,在微服务领域中的定义:


“对微服务的某个指标给予一个可量化程度的测量”


Metrics应该具备的特性:


Comparative(可对比):指标能够在不同的微服务或同一个微服务的多个实例之间比较;


Understandable(易理解):指标所衡量的对象、计算方法和输出的结果值都是容易理解的;


Ratio(理想的比例):理想结果可预见,可以立即用于比较。

如何判定Metrics实现的优劣?

衡量Metrics实现优劣的标准有:


1、关键指标覆盖全,这是能够快速定位问题的基础;


2、计量准确,错误的计量和算法只会帮倒忙;


3、高性能低资源占用,毕竟Metrics是可选模块,要保证资源占用不超过10%;


4、无侵入或低侵入,同样,由于Metrics是可选模块,让用户修改代码是不可取的。


Metrics的分类

Metrics有很多种分类方式,在技术实现上我们偏向以取值方式区分为两种。


1、直接取值。任何时候都能够立刻获取到最新值,例如资源使用率,包括CPU使用率,线程数,Heap使用数据等等,还有调用累加次数,当前队列长度等等。


2、统计取值。经过一个特定的时间周期才能够统计出值,这个时间间隔我们可以称为窗口周期(Window Time)或统计周期,例如:


a) 多值取其一的,比如Max、Min、Median(中位值);


b) 与时间相关的,比如TPS(transaction per second);


c) 与个数相关的,比如累加平均值、方差等等;


获取此类Metrics的值,返回的是上一个周期的统计结果,具有一定的延后性。


为什么需要Metrics

上图是传统的单体应用,多模块紧耦合,Client Application调用API,然后模块在内部相互调用,还会涉及操作数据库的一大堆逻辑,随着功能的不断增加,它的体积会越来越大,这样的系统开发人员维护起来会头晕脑胀,到某个阶段重构几乎是不可避免的。


但是这种单体应用却很受系统运维人员欢迎,维护它的工作很简单。

进入微服务时代之后,我们会将单体应用切分成很多微服务,还会使用负载均衡,这样一个单体应用最终可能转化为成百上千的微服务实例。


所以微服务化后,问题没有消失,只是转移了,开发人员把这个“锅”甩给了运维人员。因此微服务平台化或上云成为趋势,通过自动化程度很高的平台工具降低运维人员的负担。要使这些平台工具发挥作用,例如制定报警策略、弹性伸缩策略等等,必须提供丰富的Metrics数据作为支撑。


开源领域的Metrics比较

由于Metrics的重要性日渐凸显,开源领域已有较多实现,热门的包括Netflix Servo、Dropwizard Metrics和Spring Boot Actuator等,比较如下:

我们结合ServiceComb Java Chassis的优势,更进一步开发了包含关键指标无侵入自动打点,丰富的统计维度和极低的资源占用等诸多优点的Metrics系统。


ServiceComb Java Chassis

中的Metrics

ServiceCombJava Chassis是一个包含了服务注册,服务发现,服务配置以及管理功能的微服务框架,因此我们决定提供内置的更强大的Metrics功能:


1、开箱即用,不写一行代码输出关键Metrics,全面覆盖调用数、TPS、Latency等;


2、基于Netflix Servo,使用固定统计周期(稍后会详细介绍);


3、多维度统计,帮助用户抽丝剥茧快速定位问题,支持的维度包括:


a) 微服务实例(Instance)级和操作(Operation)级;


b) 操作结果成功(Success)和失败(Failed)(开发中);


c) Transport区分Rest和Highway(评估中)。


依赖关系

Metrics-Core是我们的核心功能模块,之上的Metrics-Extension模块用于扩展。在Metrics Extension里面,我们实现了Prometheus的集成,它依赖于Prometheus Java Client和Metrics-Core。

Metrics默认输出列表

其中对于时延类的Metrics,都包含max、min、average三个指标。


使用多周期适应不同的场景需求

为了具备高性能的同时又能保持极低的开销,我们使用固定周期的方式实现Metrics统计,同时支持多周期以适应不同的场景需求,多周期的原理可以看下面的例子:

图片

例如统计报告中的日报、周报、月报、季报、年报就是使用了多周期满足不同的统计需求。


支持Health Check

微服务很可能依赖数据库、其它微服务或中间件,这些组件状态正常是微服务能够正常提供服务的前提,通过Health Check使得微服务支持检查依赖组件的状态并返回,可以用于制定策略,也可以用于Dashboard展现。


相比使用Metrics返回一个状态值,Health Check的返回更丰富,可以附带额外信息,例如详细的错误Trace。


未来的开发计划

未来Java Chassis Metrics将强化如下几个方面的内容:


1、我们需要实现或对接一个更优秀的可视化界面用于展示Metrics的更多特性,仅仅是集成Prometheus是不够的(SCB-252);


2、我们将研究如何与主流的监控系统例如Zabbix、Nagios、Cacti等更简单高效的集成,以及提出通用的集成第三方监控系统的方案;


3、我们将强化Metrics作为数据源,如何更好的支持在监控系统中制定报警、弹性伸缩等策略,降低运维人员的工作量,提升运维效率。



标签:透明,服务,周期,运维,Metrics,Chassis,统计,运行
来源: https://blog.51cto.com/u_15127602/2757312