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作为数据源,如何更好的支持在监控系统中制定报警、弹性伸缩等策略,降低运维人员的工作量,提升运维效率。

如何参与到ServiceComb社区

官网:http://servicecomb.incubator.apache.org/cn/

通过订阅邮件列表参与讨论:

1、发送任意内容至邮箱:dev-subscribe@servicecomb.incubator.apache.org

2、收到来自dev-help的邮件后,再回复任意内容来确认订阅邮件列表

在Apache JIRA(https://issues.apache.org/jira/browse/SCB)上提issue或查看最新的开发任务及进展;

原文发布于微信公众号 - IT大咖说(itdakashuo)

原文发表时间:2018-01-24

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Android机动车

Android模块化开发方案

随着业务的不断发展壮大,移动端所承担的功能也越来越重,特别是代码几易其主之后开始变得杂乱无章,牵一发而动全局的事情时常发生。为了应对团队壮大之后的开发模式,我们...

1612
来自专栏Java架构师学习

多研究些架构,少谈些框架——一名阿里架构师的笔记

微服务架构和SOA区别 微服务现在辣么火,业界流行的对比的却都是所谓的Monolithic单体应用,而大量的系统在十几年前都是已经是分布式系统了,那么微服务作为...

3848
来自专栏程序你好

为什么应该使用RESTful Web服务设计

你可能负责一个API。也许你正准备投入制作一个,并且很期待开始。但是要小心,因为好的API设计可能很难。

3653
来自专栏CSDN技术头条

《英雄联盟》支撑最高750万同时在线用户的聊天服务打造

【编者按】在2013年初马化腾被问及“过去两年腾讯在海外投资中最成功的案例是什么”时,他毫无疑问的回答:“投资美国的Riot Games,做出《英雄联盟》。”在...

27710
来自专栏北京马哥教育

sqlserver、Mysql、Oracle三种数据库的优缺点总结

? 一、sqlserver 优点: 易用性、适合分布式组织的可伸缩性、用于决策支持的数据仓库功能、与许多其他服务器软件紧密关联的集成性、良好的性价比等; 为...

4676
来自专栏北京马哥教育

正确评估SQL数据库性能,你必须知道的原理和方法!

作者:阿特 来源: http://blog.csdn.net/capsicum29/article/details/71480799 数据库是一个很重要的模块...

49311
来自专栏玉树芝兰

安装 Python 软件包遇错误,怎么办?

本文通过一个命令行转换 pdf 为词云的例子,给你讲讲 Python 软件包安装遇挫折时,怎么处理才更高效?

1582
来自专栏云计算教程系列

什么是不可变的基础设施?

在传统的可变服务器基础架构中,服务器会不断更新和修改。使用此类基础架构的工程师和管理员可以通过SSH连接到他们的服务器,手动升级或降级软件包,逐个服务器地调整配...

1940
来自专栏刘笑江的专栏

iOS App 启动必 crash 监控

2273
来自专栏刘君君

Rest Notes-基于网络应用的架构

1968

扫码关注云+社区

领取腾讯云代金券