左耳听风_025_24_分布式系统关键技术全栈监控
你好，我是陈浩网名做耳朵house子。
对于布布式系统来说呢，首先我们需要的是全栈系统监控。
它呢就像是我们的眼睛，没有它呀，我们就不知道系统到底发生了什么。
我们呢就没有办法管理或者运维整个分布式系统，所以呢这个系统啊是非常非常关键的。
而在分布式或者clounative的情况下呢，系统啊会分成多层服务，各种关联需要监控的东西啊特别多。
如果没有一个好的监控系统啊，我们就无法进行自动化运维和资源调度。
那这个监控系统啊需要完成的功能，包括全站监控、关联分析、跨系统调用的串联、实时报警和自动处置。
还有呢系统性能分析。
那所谓全站监控呢，其实就是三层监控。
那第一层呢是基础层监控主机和底层资源，比如CPU内存、网络吞吐、硬盘IO,还有硬盘使用等等。
那第三层呢是中间层啊，就是中间件层的监控，比如enginx、 REDISSTMQ、返夫卡、mysql,还有tomcat啊等等。
那第三层呢是应用层调来监控，应用层的使用，比如HTB访问的吞吐量，想用时间返回码调用链路分析性能瓶颈，还包括用户端的监控。
我在文中呢把这三层监控和它其中的技术内容啊画了一张图，那你可以打开看一看。
当然啊这里还需要一些监控的标准化。
这个标准化呢包括日志数据的结构化监控，数据格式的标准化，统一的监控平台，还有呢统一的日志分析。
那怎样才能算是一个好的监控系统呢？那这里呢我要多说一句，现在我们的很多监控系统啊都做的很不好。
他们呢主要有两个很大的问题。
那第一个问题呢在于监控数据啊是隔离开来的。
因为公司分工的问题啊，因为应用运维系统运维各管各的，所以很多公司的监控系统之间啊都有一道墙，完全串不起来。
那第二呢就是监控的数据项太多了。
有些公司的运维团队啊，甚至把监控数据项多作为一个亮点，到处讲，因如监控指标达到五万多个。
老实说啊，这太丢人了。
因为信息太多啊，等于没有信息，还不到重点的监控啊，才会做成这个样子，完全啊就是史蛮力的做法。
我认为呢一个好的监控系统啊应该有这么几个特征。
第一呢是关注整体应用的SLA,主要是从为用户服务的API来监控整个系统。
那第二点呢在于关联指标的聚合，把有关联的系统和它的指标聚合展示。
那主要呢是这三层系统的数据，包括基础层平台、中间件层和应用层。
那其中最重要的是把服务相关的中间件和主机关联在一起。
那服务呢有可能运行在docker中，也有可能运行在微服务平台上的多个JVM中，也有可能啊运行在tom cat中。
总之呢，无论运行在哪里，我们都需要把服务的具体实力和主机关联在一起。
否则对于一个分布式系统来说啊，定位问题啊就好像大海捞针一样。
那第三点呢在于故障的快速定位。
总之于现有的系统来说呢，故障总是会发生的，而且呢还会频繁发生。
故障发生啊不可怕，可怕的是故障的恢复时间过长。
所以呢快速的定位故障就相当的关键。
那快速定位问题啊，需要对整个分布式系统做一个用户请求跟踪的trace监控。
我们啊需要监控到所有的请求在分布式系统中的调用链。
那这个事儿呢最好是做成没有侵入性的那换句话说，一个好的监控系统啊，主要是为体检和急诊两个场景所设计的。
所谓体检呢，首先在于容量管理，提供一个全局的系统运行时的数据的展示，可以让工程师团队啊知道是否需要增加机器啊或者其他的资源。
那其次呢是性能管理，可以通过查看大盘找到系统的瓶颈，并用针对性的优化系统和相应的代码。
而所谓的急诊场景呢，首先在于定位问题啊，可以快速的暴露，并且找到问题的发生点，帮助技术人员啊诊断问题。
那其次呢是性能分析，当出现非预期的流量提升的时候，可以快速的找到系统的瓶颈，并且啊帮助开发人员深入代统。
那只有做到了这些关键点啊，才算是一个好的监控系统。
那我们应该怎么做出一个好的监控系统呢？啊，我认为啊一个好的监控系统啊，应该实现的功能啊有这几个。
那第一个功能呢是服务调用量的跟踪。
那这个监控系统啊应该从对外的API开始，然后呢将后台的实际服务啊给关联起来，然后再进一步将这个服务的依赖服务关联起来啊，直到最后一个服务。
那这样呢就可以把整个系统的服务啊全部都串联起来了。
那这个事情的最佳时间呢是google的demo系统啊，它对应的开源实现是是ip in.那对于java类的服务啊，我们可以使用字节码的技术进行字节码注入，啊，做到代码无侵入。
我在文中呢放了一张我做的一个APM的监控系统的截图啊，你可以看一看。
那第二个功能呢是服务调用时长的分布。
那使用zip in呢可以看到一个服务调用链上的时间分布。
那这样呢有助于我们知道最耗时的服务是什么。
那文中这里呢有一张zip的服务调调时时间，布布图供参参考。
第三三功功呢是服务的top n视图。
所谓top n视图呢，就是一个系统的请求的排名情况。
那一般来说呢，这个排名啊会有三种排名的方法，一是按调用量排名，二呢是按请求最耗时排名。
三是按热点排名，也就是在一个时间段内的请求次数的响应时间和。
那第四个功能呢是数据库操作观点。
那对于java应用呢，我们可以很方便的通过java agent字节码注入技术，拿到JBDC执行数据库操作的执行时间。
那对此呢我们可以和相关的请求啊对应起来。
那第五个功能呢是服务的资源跟踪，我们的服务啊，可能运行在物理机上，也可能运行在虚拟机里，还有可能啊运行在一个docker容器里面。
Docker容器啊就可能运行在物理机或者虚拟机上。
所以我们啊就需要把服务运行的机器节点上的数据啊关联起来。
那这样一来呢，我们就可以知道服务和基础层资源的关系了。
那如果是java应用呢，我们还要和JVM里的东西啊进行关联。
那这样呢我们才能知道服务所运行的JVM中的情况。
有了这些数据上的关联之后呢，我们啊就可以达到这样几个目标了。
那第一呢是当一台机器挂掉的原因是CPU或者IO过高的时候，我们马上就可以知道它会影响到哪些对外服务的API.那第二呢，是当一个服务响应过慢的时候，我们马上就能关联出来。
是否在做java GC,或者呢是它所在的计算节点上是否有资源不足的情况啊，或者依赖的服务啊是否出现了问题。
第三呢是当我们发现一个sql操作过慢的时候，我们啊马上就能知道它会影响哪个对外服务的API.那另外呢就是当我们发现一个消息队列拥塞的时候，我们也能很快的知道啊，它会影响哪些对外服务的API.总之呢我们就是想知道用户访问哪些请求啊会出现问题。
那这个呢对于我们了解故障的影响面啊非常有帮助。
那一旦了解了这些信息啊，我们就可以做出调度。
比如一旦发现某个服务，过慢是因为CPU使用过多了，而我们就可以做弹性伸缩。
或者呢一旦发现某个服务过慢，是因为mysql出现了一个慢查询，我们呢就无法在应用层上做弹性伸缩啊，只能做流量限制或者降级操作了。
所以呢一个分布式系统或者是一个自动化运维系统，又或者是一个cloud native云化系统。
最重要的是啊就是把监控系统做好，再把数据收集好的，同时呢更重要的是把数据关联好。
那这样呢我们才能很快的定位故障，进而才能进行自动化调度。
那文中这里呢有一张图，简单展示了一个分布式系统的服务调用链上都在报错。
那问题的根本原因啊是数据库链接过多了啊，服务不过来。
那另外一个原因呢，就是java在做复制c导致处理过慢了。
于是呢消息队列就出现了消息堆积堵塞。
那这个图呢只是一个示例，它形象的体现了在分布式系统中监控数据关联的重要性。
那这节课呢到这里就结束了，我们来回顾一下今天的要点内容。
首先呢我强调了全站系统监控的重要性，那它呢就像是我们的眼睛，没有它，我们就根本不知道系统到底发生了什么。
那随后呢我从基础层、中间层和应用层三个层面讲述了全站监控系统要监控哪些内容。
然后呢，我阐释了什么才是一个好的监控系统。
还有呢就是怎么做出一个好的监控。
最后呢欢迎你也来分享一下你在监控系统中的比较好的实践和方法。
那下节课呢我将讲一讲分布式系统的另外一个关键技术啊，也就是服务调度。
我在文末呢也列出了分布式系统架构本质的系列文章的目录，方便你啊快速找到自己感兴趣的内容。