【51CTO.com原创稿件】在高效地支撑苏宁互联网相关业务的过程中，各系统间的交互也变得如图 1 一样错综复杂，下图中的点代表各个应用系统，连线代表系统间的交互。
图 1：系统交互图
以上错综复杂的特性主要由以下两个原因导致：
- 系统和服务的复杂性：体系数量庞大：4000+ 系统，10w+ 服务；系统间调用方式复杂：大部分使用 RSF，也有其他的方式，如 HESSIAN，ESB等。
- 业务的复杂：既有线上新业务又有线下老业务，这些业务系统之间会有大量的关联。
基础环境的复杂性：多数据中心，每个数据中心会划分多个逻辑机房和部署环境；一个系统服务器规模往往会很大，例如，缓存服务器就可能有上千台。
为解决上述复杂性问题和更加有效的支撑整个业务的发展，我们提出了立体式监控解决方案。
所谓立体式监控，是由传统的单点系统监控演化而来，在复用当前监控探针的前提下，由单点发展为对业务全链路的监控。
并根据采集而来的监控数据进行多维度、甚至任意维度的分析，实现多维空间的监控，便于快速预判和定位系统或者业务故障，提升业务支撑效率。
监控体系建设
苏宁监控一体化解决方案旨在为用户提供从系统监控、问题定位、实时告警到决策分析、故障自愈的一站式解决方案。即全力为用户打造从“监”到“控”的全方位一体化 APM/CPM 解决方案。
从移动 App、PC/WAP端、网络端、服务端、调用链各个级别进行应用性能分析。
能够深入到应用、数据库自动捕获应用性能异常，自动识别有问题的应用组件和代码，利用关键业务性能剖析进行故障原因深度分析，非 IT 专家也能够快速定位问题原因所在。
采用新一代的应用监控技术，将企业数据中心基础资源监测数据、用户体验监测数据、应用代码性能分析数据、网络性能数据、系统运行日志等各类异构、海量的 IT 监测数据进行集中收集和处理，融合苏宁大数据能力，构建更加高效、更加智能的 IT 故障分析能力。
立体式监控体系整体架构图如图 2 所示：
图 2：苏宁立体式监控概览
第一个维度
从左到右，是从监控的思路进行构建的：
- 左边一块为监测产品，主要用来发现问题。
- 问题发送给智能告警平台和决策分析平台，定位问题根源，反馈给研发团队及时进行处理，以及服务治理系统进行治理。
- 右边是自动化的干预处理，最后再回到最左的流程中进行监测。
第二个维度
从上到下，从前端到后端。我们现在的监控主要面对的是苏宁一些核心应用，比如苏宁易购手机端、苏宁金融易付宝等等。
这些应用用户数量多、范围广、使用频次高，会不断地反馈应用或服务的问题。
先从用户角度，对用户体验进行监控，一旦发现问题，会立刻针对数据进行溯源，到客户端通过 SDK 或 JS 抓取一些传统标准做法采集数据，再通过多维度分析，将数据问题反馈给研发。
同时我们会对服务端进行性能监控，前面也说服务端的系统相对而言要复杂得多，因此我们往往会想办法串起前后端，做到分钟级甚至秒级调用，所以我们对调用链也进行了监控。
而调用链监控依然是在中间件层面，也可能是基础设置的波动导致了问题的产生，所以在底层对基础设施构建了监控。
第三个维度
从数据层面：
- 首先是 Metric 指标，这个指标可以是从基础设施而来的，可以是业务层面定义的，也可以来自性能监控，这是评估性能的一个重要指标。
- 还有一个是 Event 事件，日志监控承载了非常重要的能力，事件帮助系统定位问题。
- 第三个指标 Trace，来源于调用链。三个指标会产生交集，辅助定位、排查问题。
根据目前监控体系的现状，为了满足日益复杂的监控需求，打造基于 AI 的监控体系，实现面向用户体验的无人化智能服务解决方案目标，我们提出了面向现代监控的体系规划。
详细的规划如图 3 所示：
图 3：面向现代监控的体系规划
在该体系中，通过引入自然语言处理、建立知识图谱和图像识别等 AI 技术，让监控实现无人值守，用户可以更简单便利地与监控系统机器人进行交互，获取所需的监控信息。
在问题分析和决策领域，将通过建立计算模型生成不同维度的指标，实现多维度的关联分析和异常检测，并且动态计算出告警阈值，生成告警事件推送给用户。
监控技术实现
监控产品介绍
立体式监控体系由一系列的监控产品构成，每种监控产品都存在独特的特性，但同时也和其他产品有着相互协调的关联关系，从而形成一个监控生态体系。
监控主要产品如图 4 所示：
图 4：监控体系主要产品及其关系
用户体验监控(UOM)
UOM 是一个可以对用户产品端进行全方位、多种维度进行监控和分析的平台。
通过将监控采集 SDK 无侵入或者较少侵入的植入用户端中，获取用户在使用产品时对用户造成体验影响的调用链异常数据，并基于此进行分析、预测和告知该产品的相关运维人员。
通过采用无侵入和较少侵入的方式，将采集 SDK 植入用户应用，实现对用户应用的系统异常、业务异常、用户信息进行采集。
对异常数据进行建模，形成相应的异常数据趋势图和用户轨迹，实现迅速地对用户应用问题进行定位。
通过态势感知计算模型动态计算异常增长率，根据不同维度的规则配置，实现对应用异常问题进行告警。
UOM 机器人可满足用户在豆芽中，通过自然语言方式直接和机器人交流，实现快速获取问题根本原因。
图 5：UOM 系统技术架构
日志统计分析
离线日志统计分析是运用大数据技术，海量历史日志分析的一种解决方案。专注于帮助使用者发现并解决系统性能问题。
通过分析各类访问日志，得到各系统使用过程中请求量、响应时间、错误率、命中率等性能指标，可以通过分析来源 IP 判断是否遭受攻击等。
图 6：离线分析
实时日志统计分析是一个在 E(Elasticsearch)F(Flume)K(Kibana4)的基础上进行二次开发的平台。
它集成了苏宁内部的账号体系和系统基础数据，实现准实时日志的检索、统计分析。
图 7：实时分析
调用链监控
完全采用 OpenTracing 标准，对系统异常和业务异常进行全链路监控。采用字节码技术实现监控 SDK 植入，对业务系统功能不会造成影响。同时提供及时关闭、自动升级功能，节省人工、降低风险。
并可以应用于各领域应用系统服务和调用链监控，为 IT 研发人员检测系统健康、定位解决问题提供可靠依据。
根据异常栈详情，用户可以直观了解到操作的页面轨迹以及服务端系统的调用链路。
系统利用机器学习分析异常数据并做出预判，提供一站式的预警、排查、告警和问题解决策略。
图 8：调用链监控模块
监控组件介绍
通过之前的介绍，我们了解了很多目前苏宁监控体系中的产品，这些监控产品如何无侵入式的植入各个应用中，如何实现对监控数据的采集，请参考图 9。
图 9：无侵入式数据采集
具体过程如下：
- 通过字节码拦截请求，创建调用上下文、生成埋点。
- 调用上下文保存在 ThreadLocal，对应用透明。
- 调用上下文包含了 TraceId、RpcId、调用类型等数据。
- 调用上下文随着 Http 调用在网络间传输。
“源头型”：生成 TraceId，创建调用链，结束调用链。
“单项型”：仅客户端，生成日志(服务端未埋点)。
“双向型”：客户端+服务端，传输上下文，生成日志。
根据以上的实现方式，无侵入式监控数据采集的整体调用顺序如图 10 所示：
图 10：监控数据采集时序图
在时序图中，我们可以看到请求发送到前端应用时，将会调用 StartTrace 生成一个全局唯一的 TraceId，TraceId 使用了 IP + Timestamp + 顺序数 + 进程号的方式保证唯一性。
其次通过对 StartRpc 的调用生成相应的 RpcId，它标识着一次请求的顺序和嵌套关系，各个系统间传递，调用关系是同步、异步还是一对多调用。
通过使用 TraceId + RpcId 组合的方式完成整个调用链的异常数据标识和采集。
在监控数据采集过程中，也遇到过相关的难点，但是经过努力，也都一一解决，以下是我归纳的一些早前所遇到的问题和解决方法，可供大家参考。
愿景
未来，苏宁将全面打造 AI 监控生态云平台，对全生态监控体系实现无人值守的监控。
用户可通过多种方式(语音、文本、动作)与机器人进行交互，机器人将给出用户需要的分析数据，并能根据结果数据给出相应的解决方案。
以用户为导向，形成用户行为分析闭环，实现资源智能地分配与回收，让监控改变世界。
作者：汤泳
简介：苏宁易购 IT 总部数据云公司监控研发中心总监，苏宁一体化智能监控体系首席架构师。15 年从业背景，数学与计算机科学系毕业，师从中科院自然语言处理黄和燕导师，主导“云穆“立体式智能监控产品研发。这些产品服务于苏宁控股集团八大产业 4000+ 系统、10W+ 服务，保障电商平台日常和大促时段线上系统平稳运行。目前，致力于苏宁 AIOps 能力建设。
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
