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