标签：透明 服务 周期 运维 Metrics Chassis 统计 运行
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
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。