腾讯云TVP吴晟：如何监控大规模分布式服务

11月24日，腾讯云开发者社区开发者大会（苏州站）圆满落幕。本次开发者大会的主题为“姑苏城外论技术：物联网·小程序·微服务”，邀请了腾讯内部及业内行业大咖就物联网、小程序、微服务等当前互联网领域的热点技术的落地实践问题进行了深度探讨。同时，各位技术专家也与到场的开发者们展开了开放式对话，精彩不断。下边是吴晟老师关于SkyWalking如何实现强大的监控能力的分享。

讲师介绍：吴晟，腾讯云TVP，Tetrate.io Founding Engineer，开源技术和开源社区爱好者，Apache和CNCF基金会多个开源项目核心团队成员。Apache SkyWalking创始人，VP和PMC成员；Apache孵化器PMC成员；Apache ShardingSphere(incubating) 联合创始人，PMC成员；Apache Zipkin(incubating) 贡献者和孵化器导师。CNCF KubeCon + CloudNativeCon 2019 Program Committee 成员，CNCF OpenTracing标准化委员会成员。关注和推进云计算、服务化、云原生和服务网格技术的技术发展。并积极为中国开源项目提供帮助。

我很久没在国内讲项目了，所以有很多都是跟开源或其他方面有关系。我们今天会先回到项目里面，如果我想去讲企业的一些案例我们可以在下面聊。

可能大家现在也听到在新闻上说的事情，我具体现在在做一个企业级的Service Mesh如果大家熟悉的话大家知道有一个，大家知道绝大多数企业它是一个很棒的东西，很激进，中国企业很激进，中国企业把一两年内把所有国外企业给吓掉换成国内，包括云厂商也在推国内大量的绿色服务，或者国内的这种Service Mesh，但是依然很多需要私有云需要这种环境，所以我们需要帮助更多企业做一半的Service，或者在跨云，你的服务在不同的方面怎么去做这些。

有来自于Google、脸书很多核心的工程师，我们再把这些构成完成的产品体系，他们会去做你技术管理，通讯，还有监控闭环，这是企业要做的事情，我们今天要做的事情，比较集中第一是谷歌还有CF还有阿尔法，都是开元，所以给大家提供商业级整合，商业式方式。

再讲tracing是在五年之前开源，大家了解这个都来自与tracing，了解运行情况，实际上在两三年之前加入的时候，做了非常大的变化，他再去tracing，tracing依然是被支持的，但是做其他的时候知道tracing是成本很高的地方，如果你做纯电路的时候tracing是100%电路采集存储，实践什么都没有问题，但是需要足够的钱，需要后端的技术可以抗住这么大的写入量，需要大量的网需要后台去做支持，我们经常说这个方面metrics、还有tracing、logging这是国外的三张图，其实大家可以看到，其实大家做好的时候想好最大的一个问题，当然你通过tracing拿到所有的指标，去采集日志，拿到关联、关系，甚至有人聊到刚才说业务和tracing关联都没问题，只要觉得这部分消耗你可以承受，因为用下来你会发现，你去做这个东西是很大的一个成本，因为你去做这个队伍网络开销和开发上，因为开发和开销上对于网络CPU会很大因为本身就是虚拟网，因为大家知道物理机等等需要经过多层虚拟网这些消耗总体算下来很大。

大家说tracing实际上从逻辑是很了解的东西，所以从这里面了解下来从外面怎么走？那它只有ING，除非有一个机制可以串联起来，但是串联起来从逻辑上来就是一个tracing只是它走的是一个格式输出，如果你是单一的一个点，比如说这个服务多少人请求，请求情况是什么样子。

我们再讲tracing，如果大家熟悉还有open tracing这个项目，大家在相同的领域，大家以后可能会在tracing里面都可以看到，但是在三年以前我是这个总监，它定义很好，它是API，但是它跟刚才大家听到的API是两个层面的东西，它们之间最大区别是没有逻辑，没有数据结构，没有逻辑，如果按照大家写的话是很明确，它是什么？是头文件，就是里面是什么样子都可以，所以是open在生产环境应用最大的挑战，所以谁提供实现谁说的算，大家可以发现一个非常有意思的结论，定API的人说的都不算，你选了哪个实现你说了算，有一天你选系统的时候追踪出来是什么样子你说算，做了这些数据模型完全不一样。

这时候可以发现API是非常虚的概念，不管覆盖什么范围，效果不会来。所以而且大家要注意绝大部分厂家大家现在把tracing当APM原始数据在进行，但是你如果熟悉APM厂商特别是国外全球化的国际厂商，基本上没有人做手工tracing，因为这是一种非常不精细的做法，几乎没有人做，不管你有open tracing也好，还是没有opne tracing也好，除了像不太好写动的东西会用手动，但是这种一般是处于中间的位置或者是交换，不会拿来写业务，我知道中国厂商在拿这个写业务，但是开发效率是很难，跟做业务去做，如果做从同程业务来说的话，你要手工的话，那程序员要多很多，这是没有办法的事情。

在两年之前成立SkyWalking的这个项目这是非常常见的一个图，就是你兼顾后面所有系统，你看第一个东西就是这个，这是很有意思的讨论，虽然都喜欢买，都是很喜欢做，但是每次下来我们其实也会聊这个话题，这个东西到底有多大的用处，但是有一项作用是所有团队都需要回答，这个东西喜欢，也要像你的CTO，向你CEO汇报架构的时候，你没这个，老板肯定觉得这个系统肯定做得不对，因为老板就只看这个，就看这个，其他都不会，而且老板喜欢在墙上画一个这个，我去过所有金融公司都有这个东西，不管是谁做的其实没人看的。

这是和其他的包括阿里、蚂蚁金服一起写的一本书里面有财务的内容但是很少，我之所以放在这里是因为它讲到一半东西，比如说发布器容器化。如果你想知道这些涵盖的领域这是你可以了解的渠道，如果你觉得这个对你来说太陌生，我可以告诉大家CNCF是很值钱的东西，有大量厂商花了很多钱想进CNCF想做很多活动，因为2019年全厂有三场CNCF的Commiter。我在做其中一位的，干什么？全球有无数人在申请一级，我们要评估这个一级上台去讲，这个量有多大呢？这里面的成员要选择，但是每个会议我们需要有将近三百个来自于不同厂商的人写的，就针对这一个话题针对一场会议一场话题。

今天刚刚在北美结束的，在北美这么人少的地方有一万两千人参加了这个会议，大家可以感受一下CNCF在这个层面上给大家吸引人非常非常夸张，所以大家需要了解这个东西，然后实际上我们在做很多推动工作的时候，我们在国内绝大部分用户，在国内大家可以涵盖的所有用户.

做任何一个，电脑是所有里面最重要，因为在四年前，我们在培训公司员工的时候去写的一个代码拿来玩的，这个数据应该在主库有一百八十四个，它的存库将近两百人参加了这个项目，所以能想到国内厂商都在里面主流APM里面也有人参与，开放大概有180多家，但是我知道还有一半数量是不允许宣传这个事情，特别是金融公司，我们只收到两家银行确认，是招商银行和农商银行，我知道还有其他，但是他们不愿意去泄露，这个没有办法。

有29位官方，如果你有兴趣给项目贡献代码你会面对其中有一些人，他们会浏览你的代码还有文档这种人会确定项目发展方向还有核心的功能，有不同的研究像这样，每个月都会有这样的，也许在国外，上个月我们在上海，之前在乌克兰还有北美都会有，还有不同的主题会发一些东西。

综合比喻，它涵盖两个方向，一是你需要的语音试配，不论是挂参数还是代码都需要跟语言有关系，当然因为公司关系，还有因为我个人的偏好，我们个人也会放在这里，如果大家去问国外那一套可能不会来支持，但是你是作为生态，可能我们明年在公开尝试会说一个案例，在跟谷歌的一项目会根据它进行一个结合，因为在今年谷歌，我们同事其实跟顾客的PM提这个主题但是没有去做，因为那时候条件还不是很熟悉，在明年会真正实现这个模板，以及大家去尝试的方式给大家。

不管是使用哪一种方式，唯一的区别可能是代码级的分数最多，那目前可能是你唯一选择，但是你需要，其实两种方式一样没有什么区别。其实大家很多人喜欢研究这个东西，甚至高大尚东西，很简单其实无论程序员改代码的区别，其实自动在你代码里面强行插入两个代码，代码是有问题，知道代码是干什么用，所以这你就发现所有的拦截是什么都是这种或者是框架，或者是你拦截的框架是什么，因为它需要明确知道，那一个代码具体干什么用，或者你自己可以写，但是逻辑上都是一样的。

你在用的时候或者开发的时候可以看见得有一些基本的概念就是Service，Service是被用坏的概念，就什么东西都可以改，但是有主有次，那么在这里面什么是Service，只是一个逻辑概念，你可以指音乐的东西一套结合，或一个集群，这个集群具有相同功能单元，那你可以认为它是Service。

如果我们讲语言，你每一个装的API进程是一个Service，但是你讲Service是一个service instanse，还有endpoint这是一个端口，但是大家有没有办法形容，但是很多东西不知道，比如说大家最常见的中国，它是一类或者国外层面GRPC也是一个内容，这让人讨厌，虽然我们最后不情愿还是选了这个公司，基于这个概念，你做这个是最上面的relation，这是Service的关系，哪个服务依赖你的服务，在以后版本上大家会知道一个Service relation的关系，还有一个最后可以实现，什么概念当你A服务经过一系列逻辑到B服务的可以检测出这两个有一个的关系，再业务结合各业务定位的一个关系。

最后一个章节我们会说性能监控指数解读，为什么讲这个事情呢？因为在过程中他们会看书，但是实际上不想看这个。我们讲一下道理是什么？这是两个最常见Service最常用，也是程序员不喜欢用的图，所有人都知道区间和次数，但是这个不是热力图和百分位数，其实这两个图都不太愿意给大家出，造成很多程序员在误解，我一定要用才能定位到系统新的问题，为什么呢？因为所有人都在跟大家讲一个概念我服务的平均数，平均时间会被磨掉，日常点会被磨掉，但是看热力图，还有百分位数的时候发现不会被磨掉，什么是百分位数有一九九的百分位数，有99%的访问在这里面，同样P75、P7490、P50都一样，可以看百分位数在一个图而不是开除，因为单独看任何一个线都没有意义，百分位数告诉大家差，间隔，如果间隔越大访问规模越明显，举一个例子超过现在流量95%，剩下95%慢了可能要慢到3秒，就一定要在两秒以上，这就是什么P90等于2130毫秒，剩下都在这个2130毫米以上，所以大家可以看到整个系统平均值，因为P50可以当多平均值在1060以下才一秒你觉得不做这个互联网系统还可以，但是实际上这个很惨，有大约10%的用户是两秒延伸这是后台没有算网络，没有算渲染，所以很惨。

热力图从另外一个方面告诉你这个故事，这个格子越深，落在轴上的请求越多，大家可以看到请求是非常不均衡的，为什么会这样？它卡住了，到某个点一竞争就两秒，竞争再激烈就三秒，这是这个图告诉你，剩下的就可能很少的，可能不需要看到哪里有锁，得到这个比你去做100%的，去找哪个点慢，这个比系统压力要小，我们在做很多监控系统的时候要做一个点，后端需要多少机器，大家都在讲多少功能，大家在说PM系统或者任何交流系统，你顶多做一个二级系统，或者是三线系统，按道理说不存在对公司没有任何影响，如果不出故障的话，那么正常的APM系统正常要做多少？I：20，如果落差没有来源一台服务器，后面监控系统不应该超过10台机器正常，如果做到全球顶尖什么概念？1：100，两台机器你只能用100台，这不是知识性问题而是能做到的问题，发现的一个异常点在万之一可能性会出现问题，但是你花的钱不值那万分之一，这是监控系统为什么可以用这个而不能用全局的，虽然这是最简单的方式，所以我们跟很多人聊的时候如果你是小公司或者种型公司，但是如果你规模越来越大，还那么依赖，如果你跟用户玩数据，我可以告诉大家每天都有大量用户，每天监控着上百亿的，消耗着几十T上百亿的ISSE，都可以运用到是不是你要的，有50个节点组成的集群后面有一二十个节点组成的东西，跑这个没有问题，但是问题是你前面是不是有那么多。

这里还有一个是平均相应时间还有成功率，还有再加上容量，这其实是很正常的图，内部有一些不太好拿出去，这三个指标是什么？你看他们捱在一起。因为成功率和相应时间波动是都有关系，所以要看他们有没有这些关系，如果有可能是你系统在流量的时候有一些比例，拉时候还是挺安全，对这些系统有时候我们站在角度来说，优化不是那么重要，如果可以做好其实就可以，代码就不需要，写它干什么，找两个程序员来就是帮你改一个代码，说不定哪一天就改过来，所以想说的是值不值得而不是你做不做得到。

那潜在的性能这实际上面是605，刚刚发布的版本我们先看这个，你可以比较不同实体不同指标在什么节点上怎么样？包括什么，道理很简单，这个访问，整个访问量是很平均的，最上面的访问量，最上面的是时间，也挺好，看了都挺正常，但是你会发现那个地方有一个问题，那个地方抖的很厉害，然后上面都在上面，也就是说当你流量在上去的时候，可能整个到P网状上有一个曲线你要读懂这个图，这个东西没有解，也不会告诉你只是告诉你潜在风险，当你这个乘以2的时候那个可能是你系统要崩掉的地方，所以往往这时候监控系统给大家的预警实际上你要读懂实际上发生了什么。

这是衍生出来的两个界面，一个是客户端一个是服务端，有两次采集，都是服务A要不是服务B，它来自于两端，来自于不同的方面，这个图模式上看起来很明确，但是这是在一个很稳定的测数上进行，如果在生产线上大家可以发现这两个没有那么好的饱和，中间是网络交叉如果配发的更明显，它可以产生这个网络，如果用的东西不好，比如说你自己的不是用云上或者刚好云上设备出了问题，你会发现这两个出现完全不同的组合，这时候要知道问题出在网上，如果客户看得出来客户端报警，但是你要看看网络下游服务对不对？如果都一样模式都对，而且下游都一样，那你要看内部是不是不对？但是联合报警提供给大家思考问题，这种问题是可以做到系统可以自动查这个东西。

包括我们在商业上面也做这些事情，但是做在开元上会有很大的不同，比如说什么？太复杂的，大家用开元很难理解你在干什么，就像分享这个不可能给每个用户客户这个事情发生了什么为什么报警，用户肯定吐槽，突然报警一个完全不相关的东西，明明这个系统不好但是就说好。

最后一个是你需要找到你的慢链路，我们知道很多人有做是没有这个问题。为什么？因为我认为不需要。frace只有两大类型，就是你看到某一个东西最近的情况最近的东西，这种提供给了一些能力，所有的东西少都有这个IT，可以拿这个直接扫，第二个，你的服务很慢你想知道为什么，那就是你站的视角是逐级排查慢这个事情，很多人想借这个事情去干所谓的业务，但是我告诉你这个东西干业务成本太高，不要拿这些干业务，你拿一个IT全世界传一下好多，你觉得它跟你很相近的其实并没有，吐槽一点给大家，介绍很好，如果你去看介绍的很好，但是有一点里面叫，你可以传，所以的厂商都当这个不存在，绝不传，因为传了挂了，你说你支持了，但是你一旦开发这个所有业务资料传进去，你想随着这个传无非就几种方法要传过去。

所以这个消耗很快，整个会给你找慢链路的机会，但是不希望你拿来做别的事情。拿这个举例，这有三个不同的图，就像右下角最常见的大家认为可能看起来比较明白一些，但是还有其他的原因，你像这种会找比较慢的，会直接找比较慢，这比你眼睛找快多了。

另外还有频次，这是非常常见的东西就是访频次多在哪里？访问频次，这是很简单的事情，但是很难，因为在中国很难的，有时候控制不了开发人员的水平，有的可能很高的水平，但是有的跟学生差不多的水平，所以没有办法会写出奇奇怪怪的水平。

还有最常见的是深度，你到底跳了多少次RPC，所有东西这事跟我没关系，所有设计团队都说这个我没关系，因为不同系统是不同人负责的，但是总要有人买单这就是第一个人，所以这是很隐藏的一个问题，所以这就是为什么有一个横着的图，所以屏幕很大需要缩放这个地方可能就已经出问题了。