全链路监控是这些年比较热门的话题，这个话题也带动了APM/NPM产品的发展，甚至顺带也带动了3D可视化产品的销售。随着微服务架构在传统企业中越来越普及，全链路监控的需求也日渐旺盛。一提到全链路监控，运维专家就会以google dapper为样板，介绍APM于全链路监控的关系。确实，dapper在前些年甚至已经成为全链路监控于APM的代名词，很多国内的APM解决方案都参考了dapper以及基于dapper思路的开源APM产品zipkin。
老白常年服务于传统企业，也曾经在一些传统行业企业里推荐类似dapper的APM解决方案，比如zipkin,不过似乎收效甚微，不少企业都不太愿意在自己的PAAS平台中集成zipkin这样的APM产品。这是因为传统企业运维和研发脱节的十分严重，运维人员的需求的并不一定是开发部门所关心的。
这些年传统行业企业也存在大量的全链路监控的需求，由于大多数传统企业没有在云平台中集成APM，因此大多数的全链路监控环节还是要借助于外部的工具，无法和应用深度集成。在运行环境中集成一些APM/NPM工具成为这些企业的首选。
上面这个全链路监控的逻辑图，是在传统行业企业中比较典型的实现模式。利用外部的监控工具，包括外挂的APM/NPM工具，我们可以获得到一个系统中端到端的应用调用逻辑，但是这些都是粗粒度的，无法深入到应用的内部。比如如果我们需要了解应用服务器中应用调用的逻辑，就必须在应用服务器上部署探针，而这种探针的部署是侵入式的，一旦探针存在问题，会影响应用服务器的可靠性，因此很多客户是不愿意部署探针的。
2015年我曾经在一个大型国企利用APM做白盒优化，不过遇到了很多阻力，一些用户怕JVM探针影响应用服务器的稳定性，不敢安装，胆子大点的客户同意在做系统优化分析的时候启用探针采集。实际上，这种探针确实还是存在一定的风险的，在一些负载比较高的环境下部署JVM采集探针后，确实出现过JVM故障的问题。虽然如此，APM在信息系统优化中的作用还是表现的十分突出，白盒优化也比黑盒优化更能够契合客户的优化需求。
除了APM对应用的监控外，对于其他的IT运维对象，比如网络设备，数据库，中间件、存储的监控是要依赖一些专用的运维监控工具来完成指标数据的采集的。通过这种集成方案，我们可以完成对一个应用系统的端到端的全链路监控。
虽然这个方案可以把全链路监控做起来，不过这种方案并不完美，对于某些由于基础设施引起的系统问题，这个方案可以很好的进行定位分析，对于微服务的监控跟踪能力几乎没有，对于应用模块的调用关系之间的跟踪也很难落地。另外一点就是，这种全链路监控下要关注到IDC的基础设施，基础网络，上要关注到应用逻辑，甚至业务管理方面的需求。整个工作贯穿了业务管理与IT管理两大领域。虽然从理论上，是可以做的，但是在实际工程实践中往往发现，这种方案里考虑的问题太理想化了，大多数传统企业采集的数据都不能很好的提供支撑。想要用这种方式做好企业的全链路监控，难度太大了。
那么是不是只有互联网企业的解决方案，像DAPPER，ZIPKIN的应用全链路追踪方案才是解决传统企业全链路监控的正确方向呢？虽然我一直觉得这里面不那么简单，不过从目前的实践来看，我们以前做的全链路监控解决方案存在两个缺点，其中之一是前面讨论的无法深入应用内部；第二个是在每个企业实施的时候，因为基础设施和监控工具之间存在的差异，实施落地的成本比较高。而DAPPER这样的全链路监控方案，只需要在云平台和应用中做好埋点，后续就可以完成十分细粒度的分布式全链路跟踪了，其后期的实施成本是完全可控的。
这两年，类似DAPPER这样的APM解决方案似乎越来越流行，在传统企业中的应用也越来越广。有一段时间，老白甚至觉得以前我们做的全链路监控的方向完全错误了。直到前两天和一个做APM的项目负责人交流后，才豁然开朗，终于把这一问题想清楚了。
他说最近这两年做APM实施时候遇到了一些瓶颈，APM可以发现应用全链路中的一些问题，并及时告警。但是现在用户已经不满足于能够告警了，而是希望能够定位原因。比如说他们多次把问题定位到数据库上，但是往往DBA会回复说数据库本身没发现问题，而是你们的SQL语句写的不好导致了数据库的一些问题。于是在这种反复的扯皮中，同样的问题多次发生也无法最终定位，甚至有些项目因此而影响了客户全面推广APM的信心。
为了解决这个问题，他们也在APM产品中做一些对数据库和中间件进行监控分析的功能，不过由于专业能力不足，这些功能在实际应用中对故障分享的帮助十分有限，很难发挥作用。
经过这次交流后，我仔细把相关的问题思考了一遍，为什么在互联网企业效果十分好的APM，到了传统行业就遇到了问题呢？在思考这个问题的时候，我又分析了一遍互联网企业与传统企业IT的最大差异。互联网企业的IT系统是严密规划后分层实施的，具有整体性与标准化两个重要的特征。在标准化的架构下十分清晰的分为IDC、IAAS、PAAS等层次。每个层次之间是解耦的，因此每层只要管好自己的层次就行了，其依赖的下层资源是能够稳定高效的为上层资源提供所需的资源的。如果下层出现问题，那么下层有自己的监控与优化手段，可以在不影响上层应用的前提下自我修复，因此应用只需要管理好应用本身就可以了，DAPPER之类的应用全链路追踪手段就能够在互联网企业很好的发挥应有的作用。而传统企业并不具备互联网企业这种IT系统自下而上的全面统筹设计，各层之间相互影响的问题十分严重。因此传统企业照葫芦画瓢的方式，完全照抄互联网企业的APM经验，都会产生落地的困难。
想明白了这一点，那么在做传统企业的全链路监控的时候就有了方向了。由于传统企业在IT系统全面监控管理方面存在大量的缺陷，因此互联网企业的应用全链路追踪技术肯定是会遇到瓶颈的。我们在传统行业构建全链路监控的时候，就应该把这些缺陷填补上，才能让全链路监控真正的在传统行业落地。
最下面的基础设施层和网络链路层在一些企业里都是IDC管理的，与上面的逻辑架构层完全可以解耦。IDC只需要提供稳定与健康的网络链路。让上层的云基础设施等能够稳定运行就可以了。
而逻辑架构层在企业里是由运维部门的各个专业团队运维管理的。基于这些运维组件的全链路监控就是以前我们在一些传统企业里做的全链路监控，不过如果下层的基础设施层与网络链路层以及上层的APM这些分层的全链路监控都已经完成建设后，逻辑架构层的全链路监控也会变得简单多了。对于网络而言，我们不需要了解某个网络设备或者某个链路是否存在问题，我们只需要关注端到端的网络IO流量与IO延时就可以了。我们也不需要去了解具体应用的问题了，只需要关注主要的基础设施的健康情况就可以了。
而应用链路层的APM也不用纠结了，APM只需要关注应用调用全链路的监控就可以了，而不需要下沉到数据库、中间件等领域了。目前很多APM产品都做了不少数据库、中间件监控的功能，不过由于不专业，这些监控功能基本上都是鸡肋。
最上面的业务管理层属于BPM的范畴。如果下面各层都已经建设的很好，BPM就只需要从业务管理的角度去考虑问题了。现在做BPM是够累的，下探到APM还不算，还要下沉到IT基础设施去，这样的BPM能做好才怪呢。
如果传统企业可以完整的借鉴互联网企业的模式，分层次构建全链路监控的体系，有效的通过各层协同来实现跨层的综合性分析，而不是非得把所有东西都放到一张图上来分析，那么就可以大大简化全链路监控工作的难度，也可以让全链路监控工作真正能够落地发挥作用。
从今天老白讨论的一些案例与分享的经验可以看出，全链路监控是一个企业级的工作，绝对不是购买某个软件或者采用某个技术路线就可以完成的。需要企业决策者把它当成一个战略工程来投入，可以总体规划，分阶段实施，但是绝对不能一哄而上。如果把这种战略级的项目当成一个普通项目，随随便便就开展起来了，最终的结果往往会无疾而终。
