简介： 通过基于IoT的全链路实时质量，业务使用狄仁杰进行全链路埋点后，可一键接入魔洛哥平台，实现终端问题的实时感知和链路分析，以及智能终端系统业务场景的全链路实时质量。整体方案接入成本低（分钟级别接入），可实现全链路的实时质量分析，以及精准的终端预警能力。帮助开发运维同学实时发现问题，快速问题的定位分析。
1 背景
伴随着物联网(IoT)的快速发展，软硬件交互场景越来越普及，在自用和商用的空间场域中，我们智慧园区、未来酒店的智能化场景也得到了极大的丰富，打造出多款智能有科技感的产品，如人脸门禁、云前台、入住自助机、无线AP、云打印等等。空间域中围绕“人”、“设备”、“空间”打造的“智能化场景”有着特殊的物理空间上的分散和连接，硬件终端的异地分散部署、终端与云端（或边缘端）的连接通信，服务端-云端-硬件终端的远程指令控制等。物理空间上的分散和连接，增加了监控运维的难度，时常出现用户的各种问题反馈：
- 设备离线
- 固件升级后服务不可用
- 终端应用升级后服务不可用
- 卡死、白屏、样式错乱
- 业务功能异常、服务异常
- 上游依赖应用系统服务异常
基于阿里巴巴最佳实践打造的智慧园区和未来酒店产品，已逐步走向商业化输出，问题也从内部用户反馈扩大到外部客户反馈，如果问题总是通过客户反馈才能被动感知到，必然会导致客户对我们的产品逐渐失去信心。如何才能变被动为主动，使得运维、开发和测试同学具备感知线上问题、诊断定位根因、快速应急止血的能力，是一件很必要的事情。
附拓扑结构图
2 核心问题&挑战
基于IoT打造的交互场景，从部署架构看，除了长链路的特性外，还有大规模分散部署的硬件终端，以及跑在终端上的软件系统。通常来说，智能终端软硬件交互系统是交付和长期运维的重难点，一方面存在硬件的不同厂商、不同型号、物理性损耗、ROM升级、摩尔定律等引发的五花八门的偶现问题，另一方面存在软件升级、依赖不可用等引发的重大问题。
我们从日常具体问题中抽象提炼出2大核心问题：
- 终端问题难感知：终端日志缺失、偶发难发现、质量度量视图缺失
- 长链路问题难定位：质量分析模型不准确、端到端的日志断连
全链路日志和质量度量视图，是解决问题的关键所在。但要在智能终端软硬件交互系统中建设全链路日志和通用质量度量视图有一定的挑战，具体挑战如下：
3 解决方案
基于IoT的智能终端交互系统，设备终端一般由交付同学来运维和升级，终端软件由客户端开发同学运维和升级，服务端由后端开发运维和升级。系统问题可能发生在硬件终端上、可能发生在终端应用软件上、也可能发生在服务端依赖上。多职能角色的协同，长链路的调用，导致问题“发现-定位-止血”的耗时远高于纯软件系统。
结合日常问题的分析经验，我们期待的问题发现定位方式是：首先能够实现终端问题的快速准确感知，其次基于业务场景指标呈现质量概览，并通过不同维度的质量分析模型进行下钻，最终通过全链路的调用日志明细确定根因。这样从业务场景出发，发现异常问题，串联全链路，任何职能角色都可以方便易懂的感知，关注和分析系统质量情况。同时我们的解决方案要满足以下要求才能真正的解决用户的难度和痛点。
针对上述的问题解决方式和要求，通过调研分析发现集团内普遍存在服务端应用的长链路监控预警和分析诊断工具，但串联终端应用在内的端到端的长链路诊断分析工具比较少。终端应用和服务端应用使用的技术栈差别很大，即使在同一个业务场景的逻辑实现中，日志也是独立埋点的，调用链路也是断开的。要建设一套各种技术栈兼容的通用埋点工具成本很高，经过内外部的多方调研，我们选择在自有业务中引入“狄仁杰”——它是专注于业务场景的全链路日志分析，轻量级的sdk接入，通过一行代码即可将系统中基于slf4j接口的业务日志全部用鹰眼traceId串起来，还支持“业务场景”语义的标识传递，可实现从终端到服务端的全链路染色。
使用狄仁杰将日志进行全链路串联后，一键接入基于IoT的实时质量工具魔洛哥，可实现基于专家经验设计的业务质量大盘等质量视图，以及自动配置的终端异常感知预警模版，整个方案采用魔洛哥产品化接入和数据服务（参考5.2 数据服务）的能力实现不同产品通用质量视图的分钟级创建，同时根据质量大盘指标自动配置预警规则和模版，做到终端异常的实时准确感知和问题的快速定位分析，整体方案如下：
整体方案
以上2个核心问题的解决方案，已在“魔洛哥”承载的多个业务产品中应用实践，详见4.1和4.2。为了支撑不同IoT产品的实时质量建设的差异化诉求，“魔洛哥”平台本身的基础能力也在持续打磨中。
4 “魔洛哥”中的落地策略&最佳实践
4.1 终端异常感知
智能终端系统由于其特殊性有很多偶现性的"疑难杂症"，同时"疑难杂症"难发现难定位。经过分析发现导致这一问题的两个因素：
- 基于终端的质量度量视图缺失（终端链路质量，终端设备质量等）
- 智能终端多职能角色的协同（客户端开发、前端开发，算法开发，硬件开发，硬件供应商，硬件部署运维团队等）
因此我们需要一种工具能够像服务端的Sunfire、云监控、eagleeye工具平台一样，能够快速感知智能终端异常，同时精准定位出异常的链路模块，使得异常模块的负责人可快速的进行问题的接手和处理。通过调研我们开发了基于IoT的实时质量工具-魔洛哥，针对智能终端异常难感知采用了以下策略：
智能终端监控预警
通过基于专家经验定义终端系统的异常指标来实时监控异常并触发预警。首先将种类繁多且分散的智能终端系统日志进行SLS云化存储，其次借助魔洛哥平台的数据服务能力，直接通过SLS编写指标查询SQL来生成HSF/HTTP服务，最后使用魔洛哥平台配置基于专家经验且通用的终端预警模版和规则，最终实时匹配预警规则产生告警。
魔洛哥平台详细实践操作流程如下：
智能终端实时质量
首先智能终端系统存在多角色的协调，一旦发现了终端异常后，需要多角色参与进行分析，导致问题的止血时间较长，因此我们需要一种工具除了能够反馈终端异常外，还能返回终端链路的过程质量，使得问题发生后，通过链路模块实时质量，能够精准的感知到异常链路模块，以此来提升异常的感知能力。其次智能终端系统还存在很多偶发性问题，而偶发性问题很难触发预警，但确非常影响用户使用体验（例如一台门禁设备人脸识别成功率低，导致高峰通行时段极差的通行体验），因此也需要一种工具能够及时透出偶发的设备异常问题，通知运维或者开发同学进行优化，提升终端用户的体验。
综上分析，我们需要提供一种标准化的运维工具，将终端硬件和系统的质量情况实时透出，帮助开发和运维同学快速感知问题，首先将种类繁多且分散的智能终端系统日志进行SLS云化存储，然后定义出基于硬件智能终端的链路质量度量模型，借助魔洛哥平台的数据服务能力，直接生成基于智能终端系统的实时质量。
详细方案如下：
魔洛哥平台详细实践流程如下：
4.2 基于业务场景的全链路实时质量
通用实时质量视图
实时质量的度量分析已经存在很多成熟的产品，比如主要用于服务端的Sunfire、云监控、eagleeye和用于前端的体验+等，那为什么我们不直接使用这些平台，而要着重提到基于业务场景的全链路实时质量呢？在我们实践业务质量保障的过程中，发现单纯的服务端和前端实时质量度量及监控不能完全满足我们想从用户实际体验的角度来度量和发现质量问题的诉求，主要体现在以下方面：
- 产品视角维度：割裂的服务端和前端实时质量，从技术栈上就天然的把产品分开了，但是对于用户来说，不论是服务端问题、前端问题或者设备问题，都可能造成用户有损的体验。因此，我们需要一个和用户视角一致的维度来"看见"产品的质量。
- 业务场景视角维度：举个例子，用户在长链路场景中，会访问多个前端页面和服务端接口，前置步骤操作成功(包含接口及页面)是最终业务成功的必要条件。按照比较常规的做法，我们会去看最后一个接口的成功率，但是这样就过滤掉了前面失败的用户。优化一下，我们用最后一个接口成功的数量比上业务起始接口的调用数量，但是如果前端出现了一些不影响流程但是确实影响用户体感的问题(比如：最后一个接口调用成功跳转的提示页面展示错误)，也就无从感知了。因此，我们需要一个涵盖前后端的业务场景质量视角。
当然，除了我们定义的产品视角和业务场景视角，基础的服务端和前端应用视角对于完整的质量全方位保障也是必不可少的，所以我们提炼了如下产品模块：
- 产品质量概览：从业务场景入手，通过业务实时成功率，平均耗时以及日环比和周环比来反馈业务的整体质量情况；同时产品质量概览中细分出了服务端和前端实时质量概览大盘，服务端和前端质量主要是通过展示应用的接口调用成功率和耗时来进行实时质量的反馈。通过点击详情可以对单应用的质量指标进行详细分析。
- 业务场景质量：业务场景的实时质量情况，以及异常的页面列表和错误码分布，同时根据错误码进行明细日志查询，最后进行全链路Trace分析。
- 服务端实时质量：基于单应用一段时间内的服务端质量情况，包括接口异常率，异常率趋势，异常API分布等，通过异常API分布情况可进行异常API的详细分析，包括耗时和错误码分布等，根据错误码分布可直接进行明细日志查询，以及全链路Trace查询。
- 前端实时质量：基于单应用一段时间内的前端质量情况，包含API，JS等的异常数，以及异常页面排行。
业务应用实践
使用狄仁杰埋点的业务，一键接入魔洛哥，分钟级透出通用实时质量视图，包含产品质量、业务场景质量分析、服务端质量分析、前端质量分析、质量查询、多维分析（建设中）等，目前菲住布渴、餐配中台等多个业务已经接入使用。
- 菲住布渴产品在接入平台后，经过对业务场景数据的分析发现：在小程序入住办理场景中，真正能走到最后一步且成功的用户占比很低，很多用户被前置流程的规则阻断了。再深入下去，发现酒店房间未准备好的问题最多，反馈业务方之后，正在进一步讨论优化方案。
- 餐配中台在接入平台后，经过对业务场景数据的分析发现消费退款失败较多，一部分失败是因为在之前就餐消费失败时，会直接去调退款接口，近期迭代做了优化，代扣结果未返回支付成功便直接异步调用撤销支付请求，并返回代扣失败。订单实际上支付未成功，因此去调用退款接口无可退订单，导致大量退款异常。另一部分失败是因为查询到订单状态是否支持退款的逻辑判断不精准，部分订单状态无法调用退款。
5 技术架构
根据上述的目标，在业务接入时，我们需要实现低成本快速接入，同时展示业准确的全链路实时质量情况，因此从技术角度出发要解决的问题有三点：
- 低成本快速接入
- 实时数据
- 全链路指标串联
根据上述的三点，从技术实现上来说有一定的复杂度，首先要解决实时性，其次要能够将全链路日志进行串联，最后还要实现低成本接入，最终通过一定的调研分析，整体的技术方案如下：
5.1 狄仁杰
为了能够将全链路指标进行串联，我们需要在业务应用中引用狄仁杰SDK，通过一行代码即可将系统中基于slf4j接口的业务日志全部用鹰眼traceId串起来，并将收集到的日志发送到应用自定义的SLS中。
5.2 数据服务
为了降低接入成本，我们开发实现了基于SLS的数据服务工具，通过一条SQL即可将SLS数据查询结果生成一个可调用的API。
数据服务能力参考了DFaaS（Data Function As Service）的数据服务能力，提供数据函数即服务，使用户无需编码而直接可生成服务，降低研发门槛、实现低成本接入，使得开发同学更快捷、持续的交付业务以及产品需求。
6 总结和展望
通过基于IoT的全链路实时质量，业务使用狄仁杰进行全链路埋点后，可一键接入魔洛哥平台，实现终端问题的实时感知和链路分析，以及智能终端系统业务场景的全链路实时质量。整体方案接入成本低（分钟级别接入），可实现全链路的实时质量分析，以及精准的终端预警能力。帮助开发运维同学实时发现问题，快速问题的定位分析。
但目前整体方案还在持续建设中，还有部分能力需要持续进行迭代优化：
- 离线加速：目前采用的数据服务直接调用sls SDK进行全链路日志实时查询以及生成可调用API，对于数据量较大的业务（亿级数据量的查询）查询时间较长，正在优化中，预计本月底可上线
- 预警规则模版自动生成：业务接入魔洛哥后，直接具备基于专家经验配置的预警模版和规则，该方案还在迭代实现中，预计下个月可上线
- 多维分析：基于业务场景任意指标和维度的分析能力，目前正在开发实现中。
原文链接：https://click.aliyun.com/m/1000361977/
本文为阿里云原创内容，未经允许不得转载。
标签：IoT,业务,实时,魔洛哥,质量,链路,服务端,终端 From： https://www.cnblogs.com/yunqishequ/p/16848639.html