直译是“度量”，不同的领域定义有所区别，在微服务领域中的定义：
“对微服务的某个指标给予一个可量化程度的测量”
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作为数据源，如何更好的支持在监控系统中制定报警、弹性伸缩等策略，降低运维人员的工作量，提升运维效率。