运维挑战加剧
新时代技术背景下，运维面临的挑战加剧：
1、业务数量日益增加、业务规模日益庞大
随着科技发展进步、民众生活富足，线下业务线上化、线上业务复杂化趋势愈演愈烈，各行各业投入巨大人力物力财力进行企业IT建设。随之而来的是线上业务数量的爆炸式增加与业务规模的剧烈扩张，这对企业IT运维人员提出了全局把控能力的重大挑战。
2、云原生、微服务技术应用
伴随着业务增长，IT架构领域提出了云原生、微服务的构建理念，将传统的大体量、高耦合应用系统拆分为微型化、可拆卸的分布式模块。这种高可用性、高灵活度的部署架构使得运维人员更难了解系统全貌，在日常监控和故障现场还原时难度极大。
3、容器技术的大规模实践落地
与此同时，在资源调度层面，为应对上述现状带来的业务快速迭代、运行保障维稳需求，容器技术在各企业内部快速落地推广。容器对基础资源的弱依赖、Pod/Container频繁起灭的特性都给运维工作带来了难以估量的复杂度提升，人力没有算力快的“弱势”日益凸显。
复杂业务逻辑带来的交错系统关系综上所述，在当今企业内部，运维工作越来越需要工具的协助，传统人工式的运维方案，已无法应对科技发展带来的挑战要求。
企业应用观测建设路径
面对上述挑战，企业常常会踏上构建可观测性工具体系的征途，而在融合ITIM基础监控之后，针对应用的可观测能力补充往往在中间阶段进行建设落地。
- 针对应用的可观测体系，首先需要建设狭义上的应用监控工具（APM），通过请求跟踪（Trace）标记，实现应用架构可视化、应用流量指标化、请求记录数据化；
- 在观测数据补足后，应用观测进入下一阶段建设目标——数据联动，将应用观测数据（Trace）和指标（metric）、日志（log）关联起来；通过多维度视角监控业务系统运行状况，为告警产生后的故障定位提供可追溯的现场记录。
完整可观测体系的结构与应用可观测的占位企业应用观测建设思路
总体定位
链路追踪的工具，即前面提到的APM，因为其自动化生成了一系列数据之间的关联关系，在整个可观测体系中是一个类似中枢的存在。
链路追踪工具在可观测体系中的作用这张图概括了链路追踪在整个可观测体系建设中的定位以及与其他工具的关联关系：
- 向前可关联到用户操作，链路追踪可以将用户在终端上的发起的请求和后端链路联系起来，实现前端到后端完整的时间线和因果关系呈现；
- 向后则可串联到具体日志，链路追踪可以定位到具体某个服务的某次或某一批请求，从而精确匹配到相关日志来解析问题所在；
- 向下则可以在锁定某个服务节点问题后，通过资源标签定位到具体承载这个服务节点的进程级监控和主机操作系统层级的监控，或是容器平台的监控。
另外链路追踪本身也是可以进行一些指标提取的，经典指标例如请求量、请求成功率、各种分位的时延，这些指标在配置了一定的告警规则后，也都可以直接作为告警来源。产生异常后主动触达运维人员。
由此可见，在构建全面的可观测性体系时，孤立地看待与应用性能管理（APM）工具的建设是一种偏颇的思路。不少企业曾尝试独立为APM工具设立项目并推进实施，然而最终这些工具并未能实现广泛的采纳与应用，项目所带来的实际效益远低于初始预期。究其根本，是因为单一的APM工具所能覆盖的问题场景极为有限。我们应当将APM尽可能和各类其他观测工具做串联打通，通过APM建立起基于业务实际请求流量的“桥梁”，有目标性地拉通各个观测工具和不同类型的观测数据，实现完整有效的观测效果。
接下来我们就具体的串联打通场景提出一些具体实践供各位读者参考。
前端到后端串联排障
当具备对用户终端数据进行采集的能力，那就可以结合这种前端监控工具（RUM）和链路追踪工具（APM）通过一些机制来实现前端到后端的串联排障。
前端串联后端调用链排障示意图图中可以解释这一过程的原理，用户在移动应用或者Web浏览器网页上访问时，会生成一个Session被记录，一个Session中记录了一个用户的完整操作流程，包括他依次打开了哪些页面，在每个页面上进行了怎样的操作，触发了哪些后台请求。当产生了一个具体的后台请求后，RUM工具可以按照APM工具定义的Trace标识规则（TraceID的生成规则），来对这个请求进行标记，这样在后端也可以完整跟踪到这个请求在后端系统具体经过了哪些服务，在哪个服务上处理消耗的时间过长或者出现了报错。
链路跟踪与日志关联
对于开发人员来说，直接将问题定位到代码级别是最高效的。但告警信息的有限以及指标类数据的高度抽象，使得运维人员在很多时候其实无法给出这么详细的信息，无法有效辅助开发人员进行问题定位和解决。这时，链路追踪和日志关联的方式就给出了一种有效的解决手段。
具体的实现方式如下图所示：
调用链串联日志方法可能会有工程师担心这种方式对代码侵入性很大，很难实践，但其实不然，业界有非常多好用的日志框架来帮你解决这个问题，我们只需要额外生成一份日志输出的配置文件做批量下发即可。
以下就用Logback日志框架配合Skywalking探针（一种业界流行的开源APM探针）来做个例子，其中关键的修改点在于：
1、引用skywalking官方提供的工具类
2、在Logger配置中引用这个Appender
在这个过程中，业务并不会有很大感知，只是会发现他们输出的日志中增加了Skywalking注入的TraceID等信息。接下来我们在日志解析过程中就可以提取这些Trace信息，便于后续直接根据这些Trace信息进行关联检索和分析。
链路追踪下钻到资源层监控
这里会进一步分为三种不同类型的场景：
1、下钻到组件或数据库排查问题
APM所捕获到的调用数据中，有一部分是对组件或数据库的调用。这种调用可以将系统所用到的组件和数据库直观地呈现在拓扑图和某一条具体的调用链中，如果相关的组件或数据库出现了问题，大概率会在这种可视化的形式中有所体现，例如拓扑图上的状态呈现以及调用链瀑布图中的长条。当然，这里只是解决了发现的问题，我们只能在APM中判断这些组件或者数据库的故障对上游调用者产生了影响，但至于为何产生以及这些组件及数据库的真实运行状态，我们仍然需要借助其他监控工具来呈现和分析。
此时APM可以在调用信息中提取出对应组件或数据库的资源标识，这可能是IP地址，或是域名链接，再通过这些标识信息去对应的组件监控或数据库监控中获取到这些资源的核心监控指标信息及相关日志，通过同一个平台的页面跳转或者嵌入来实现一套连贯的排障流程，提升此类场景的排障效率。
2、下钻到进程所在的主机/容器集群排查问题
当我们在系统中通过APM探针或者SDK按照规范要求上报了Trace信息，一般都会携带对应服务所在的主机或者容器集群信息，最常见的就是主机的IP地址以及容器的ContainerID，这两种信息会作为我们去寻求其他监控工具时对主机和容器监控的索引，从而能够在识别到某个服务节点故障后，对其所在的主机或者容器进行下钻，查看到主机和容器层级上更加精确的指标数据或者容器数据。
3、下钻到网络行为分析网络问题
我们知道，计算机网络其实底层有七层协议，而我们平时大多数情况会将这七层协议转化抽象成单次请求。但不排除，有时我们的故障发生在比较深的网络层面，在APM调用链中只能得知某一段span的耗时增加、返回码错误或者无响应断链，无法进一步排查深层次的网络问题。这时就可以通过这一进程将请求的span获取到内核态的 sys span ，再从sys span映射到网络监控中的具体net span，然后就可以从专业的网络监控中获取到这次网络请求在各个环节的详细信息。
一次请求调用实际的网络过程通常某次请求出现网络问题的概率还是比较小的，往往是短时间大面积出现网络问题，这个时候我们也可以从APM的某些样本请求中获取一个大致的范围，接下来按一定条件跳转到专业的网络监控，查看相应的指标趋势（例如丢包数量、丢包率、CRC校验通过率等）。
结语
以上，我们介绍了比较成熟理想的企业应用观测中枢建设方案。总的来说，应用观测领域目前尚处于快速发展、落地探索阶段，各企业在建设应用观测中枢的过程中不应操之过急。企业内部从一个试点出发，以点带面，逐渐推广是比较理想且稳妥的建设节奏。其最终实现的观测能力也将会对企业内部的系统维稳及代码调优起到极大的助力作用。
