作者介绍

沙丹丹，17年加入去哪儿，致力于提高研制和测验人员的功率，在CICD、测验东西范畴有一定的经验，现在在根底架构—根底渠道团队担任测验东西的开发和维护作业，包括接口自动化测验、全链路压测、反常日志核算等。

一、布景

跟着事务发展和微服务架构的遍及，企业界微服务拆分粒度越来越细，服务间调用联系错综复杂。对于一些复杂的，比方机票和酒店售卖事务场景，或许动辄涉及上百个运用，当某个体系产生反常时会导致多个服务受到影响。此时 APM 体系就派上了用场，监控（Metrics）、调用链（Tracing）、日志（Logging）帮助事务同学快速定位问题。普通的事务监控报警能起到快速发现问题的效果，但具体case的排查还需要研制人员经过反常栈信息来分析，比方数据库连接反常、空指针等等。

去哪儿网很早就有了监控体系 Watcher，能够起到快速提示事务呼应反常的效果，然后开发同学排查是接到报警的体系本身的问题仍是下游依靠的体系的问题，假如是下游体系的问题，就要这样一层层地找下去，有时分定位问题时刻会比较长。当某个体系呈现问题时最根本的体现就是产生反常，假如能直接提示开发同学体系产生了新的反常，或许反常量上涨了，就能够大大缩短开发同学排查问题的时刻，做到快速恢复毛病。

去哪儿网有一套完好的日志搜集和查看体系，首要运用经过日志打印结构将日志打印到本地 log 文件，机器上默认安装日志搜集的 agent，将日志内容经过 kafka 上报，再经过 ELK 供给日志存储和查询的才能。假如能够自动地、快速地识别反常，并将日志仓库内容直接提示给研制同学，将会大大提高处理问题的功率，乃至防患于未然。因而，反常核算分析体系——Heimdall 应运而生，首要方针如下：

1.分钟等级的反常核算
2.发布进程中展现同比环比
3.支撑添加监控报警
4.支撑用户自定义时刻规模查询
5.能够展现反常栈
6.支撑运用和机器等级的反常核算

全体的演进包括两个阶段：
1.依据实时日志搜集的建造
2.依据根底组件的改造，以在事务服务端直接阻拦并上报反常的方法进行了改善

以下分阶段进行论述。

二、实践结构

1. 阶段一：依据实时日志搜集的建造

1.1 技能栈

实时日志搜集 kafka+大众点评开源东西 CAT+FLINK+Heimdall 渠道

1.2 架构图
去哪儿网异常统计分析实践——Heimdall

图2-1 架构图

1.3 中心模块介绍

1.3.1 clog 模块

clog 模块首要担任反常栈的接纳、存储和查询。消费 kafka 音讯接纳日志，解分出 ERROR 等级的日志，并将其关联的运用、trace、日志概况、时刻戳等相关信息一并存储起来，再将转换成统一格局的日志以 kafka 音讯的方法宣布，待 flink 使命消费并做进一步解析。clog 的存储结构分为三层：本地磁盘（临时存储）+ES（做文件索引）+HDFS（持久存储）。这样的存储结构确保了热数据的快速查询和冷数据的持久存储。

存储：首要全部的实时日志都会按 bu 发送到 kafka，clog 以二进制流的方法消费此 kafka 音讯，然后经过 MessagePackDecoder 进行解析，解分出日志等级、AppCode、traceId 等信息，组装成固定格局的日志内容。再由 BlockProcessor 为每个 DataBlock 构造出索引用于查询，EsIndexManager 将索引保存到 ES 中，数据部分 DataBlock 保存到本地文件，守时转存到 HDFS 做持久存储。

block position 格局定义：ip-保存天数-时刻（ yyMMddHHmmss ）- offset，例如：10.xx.xx.xx-7-20211110185535-4625901837。

每个运用 5s 一个 block，一个 block 最大8M，当本地磁盘空间利用率到达75%，就上传到 HDFS。

去哪儿网异常统计分析实践——Heimdall

图2-2 存储架构图

查询：查询反常概况时先查询 ES，得到索引，依据索引判断本机是否存在相应的 blockPosition，假如是本机 ip 而且本地磁盘中存在，直接从磁盘读取数据回来，若是本机 ip 但磁盘中不存在，依据文件名、position、seconds 等信息查询 HDFS 。假如不是本机 ip ，则向索引中的 ip 发起长途 HTTP 请求，转化成对应 ip 的查询。

去哪儿网异常统计分析实践——Heimdall

图2-3 查询流程图

1.3.2flink 使命模块

flink 使命首要用来进行反常信息的解析核算处理，将反常类型、运用、机器等相关信息提取出来，按分钟等级做次数核算，并打印反常目标到监控体系。

1.4 难点分析

（1）容器化后日志搜集方法改变—容器化后的运用核算不到数据

近两年去哪儿在进行 KVM 到容器化的搬迁，两者技能差异仍是比较大的，日志搜集的方法也进行了完全的改变，包括 kafka 音讯的方法和格局都改变较大，原有反常日志核算架构现已完全不能满足。因而，咱们对反常核算分析的体系架构进行了调整，从源头反常日志搜集到核算逻辑都做了重大改善。下面介绍改善后的架构。

（2）实时日志存在推迟—flink 数据核算不准确

因为日志搜集属于非中心流程，当运用的日志量较大的时分，实时日志搜集存在推迟的状况，有些日志的推迟乃至超过了1个小时。在反常日志核算时运用了 flink 的滚动窗口来进行核算，因为日志的乱序和部分日志推迟，导致这些日志被丢掉，形成核算数据不准确，误差将近10%。

（3）实时日志搜集的日志量巨大—耗费资源大

因为实时搜集的日志本身是不过滤日志等级的，许多的非 ERROR 日志也会被搜集。从运用角度上，这些非 ERROR 的日志并不是用户关怀或许希望看到的数据，纳入反常日志核算并没有什么用反而会形成搅扰，所以需要从许多日志中过滤掉非 ERROR 日志，这会耗费许多的核算资源。还有一部分是多个体系间传递数据，耗费在了跨体系传递无用信息的宽带上。

（4）非全量运用都有实时日志搜集—有些运用不能运用此功能

因为公司内整套实时日志搜集是 ELK，本钱比较高，所以只有部分中心运用注册了实时日志搜集，未注册的运用就没办进行反常日志核算和监控。

（5）未考虑环境阻隔—掺杂仿真环境数据

公司内部依据不同运用目的和途径，存在多种不同的环境，包括 beta、仿真、灰度和线上，实时日志搜集没有对环境进行区分，仿真、灰度和线上的日志都会被核算，而事实上仿真环境属于测验范畴，会对核算成果形成搅扰，尤其是当短时刻内进行许多自动化测验且引发反常的状况产生时，搅扰会愈加明显。

2. 阶段二：依据根底组件的改造

2.1 改善方针

（1）支撑容器的反常日志核算。
（2）处理核算不准确问题。
（3）下降资源本钱。
（4）运用规模要扩展到全司 java 运用。
（5）能够依照环境类型维度进行过滤。

2.2改善战略

（1）将数据源从实时日志搜集改成在事务服务端的根底组件进行阻拦和上报反常。
（2）将从全量等级的日志中挑选反常日志改成直接在源头过滤，只上报带反常栈的日志。
（3）经过根底组件在事务服务端直接做好结构化，并做开始聚合（按反常类型做聚合，同种反常次数聚合，反常栈概况采样），减少冗余数据传输的资源耗费，kafka 集群 partition 从60个下降到14个，反常日志每秒音讯量从486K 下降到 106K。
（4）抛弃 flink 使命（之前运用 flink 首要是做日志文本解析，数据源变更后，就不再需要了），开发新的核算服务。

去哪儿网异常统计分析实践——Heimdall

图2-4 改善后的架构图

2.3中心模块介绍

2.3.1 logger-spi

担任在客户端进行日志采集、过滤、聚合、采样、上报。经过 agent 对 logger 进行插桩，并过滤出带反常栈的日志，然后将反常日志依照反常类型进行开始聚合，将1min 内同一种类型的反常进行累加计数，而且对反常日志概况进行采样，最终将数据经过 kafka 音讯上报。一起为了避免对服务形成过多损耗，当占用的内存到达限额时会直接上签到 kafka。

咱们将反常日志分为了事务反常（ BusinessError ）和体系反常。事务反常是指没有反常栈的，和事务流程相关的反常，比方：”没有该目的地的航班”等；体系反常是指没有体系事务意义的，带仓库信息的反常。现在咱们只关怀体系反常，事务反常是直接过滤掉的。

上报的数据结构如下：

{"ip":"xx.xx.xx.xx",
   "sendTime":1634802724460,
   "host":"l-xxxxxxx",
   "appCode":"xxx",
   "envName":"proda",
   "exType":"com.xx.xx.xx.xx.xxException",
   "count":100,
   "details":[
            {
               "level":"ERROR",
               "fileName":"/home/xxx/logs/xx.log",
               "content":"2021-10-21.15:52:04.040INFO[Dubbo-thread-57]ProxyUtil.proxyConnection:38[proxyConnection]QTraceId[xxx_211021.155203.xx.xx.xx.xx.6786.xxx_1]-QSpanId[1.7.1.5.1.1.3.1.13.1.3.1]dbproxyerror",
               "timestamp":1634802724458,
               "traceId":"xxx_211021.155203.xx.xx.xx.xx.6786.xxx_1",
               "stackTrace":"com.qunar.xxx.QProcessException:api|BookingRuleError:[预定规矩过错,最大可预订间数<=0,maxRoomNumber=0]
               atcom.qunar.xxx.xxx(xxx.java:197)
               atcom.qunar.xxx.xxx(xxx.java:117)
               ...
               atorg.apache.dubbo.remoting.transport.dispatcher.ChannelEventRunnable.run(ChannelEventRunnable.java)
               atjava.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
               atjava.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
               atjava.lang.Thread.run(Thread.java:748)"
               }
            ]
         }

模块具体架构图：

去哪儿网异常统计分析实践——Heimdall

图2-5 logger-spi 模块具体架构图

2.3.2 heimdall-statistic

接纳客户端上报上来的反常日志开始聚合成果，在内存中按分钟进行核算并暂存储核算成果，并守时更新到 hbase 中，更新时先从 hbase 中查询出该运用、该分钟原有的反常数据，再与内存中的数据叠加，最后更新到 hbase 中。这种核算、核算方法与 kafka 音讯到达的次序无关，不管音讯有没有推迟，只需音讯没丢，就都能核算进去，然后确保核算数据和实践不会有误差。核算数据包括以下四个维度：

-每分钟的反常个数
-每分钟每种类型的反常个数
-每分钟每个机器的反常个数
-每分钟每个机器每种反常类型的反常个数

三、效果展现

1.指守时刻段的反常类型及个数核算环比

去哪儿网异常统计分析实践——Heimdall

去哪儿网异常统计分析实践——Heimdall

图3-1 某个运用指守时刻段内的反常数据示例图

2. 可查看反常栈概况及 trace 信息

去哪儿网异常统计分析实践——Heimdall

图3-2 某种反常的具体反常栈信息和 trace 信息示例图

四、运用场景

依据咱们供给的反常核算、分析和反常概况查看等基本才能，公司内部孵化了一些东西渠道自动帮助事务体系定时进行服务管理和实时观测体系健康状况的东西，反常核算分析作为其中的一个重要数据源和点评、分析目标。下面列举了几个比较常用的场景：

1. 服务管理

将 AppCode 和 owner 对应起来，每周发邮件提示 owner 担任的体系的反常量，并制定规范、定义反常等级，比方P1的反常有必要修正等，便于 owner 持续重视本身体系的健康状况。

去哪儿网异常统计分析实践——Heimdall

图4-1 发送给事务担任人的反常日志日报示例图

2. 与发布体系集成

在发布进程中，发布体系会调用 Heimdall 接口获取该运用及其上下游体系的反常量改变状况即反常环比，便于在发布进程中有问题及时发现、及时停止。

3. 反常检测报警

不仅是在发布进程中要重视反常量，在平常也会呈现各种各样的突发状况，比方硬件毛病、中间件毛病、数据库毛病、攻防演练等。因而依据 Heimdall 的根底数据，开发了实时地依据反常核算数据自动识别新增反常类型和反常数量环比上涨，并及时提示给研制人员的东西，想要注册的运用能够自定义装备报警规矩，比方环比上涨多少要报警等。能够进一步提高体系稳定性和研制人员排查问题的功率。

4. 毛病根因分析

在产生毛病时，许多状况下体系都会体现出反常，比方下游接口不通、数据库连接反常、空指针等等，假如体系中许多新增了某种反常，或许某种反常的环比突然增高，反常改变和目标改变的时刻点相匹配，那么很或许和这些反常相关。毛病根因分析效果数据：22年下半年毛病处理超时率60.9%，23年 Q1 毛病处理超时率降到38.8%（反常日志分析是其中一个分析项）。

去哪儿网异常统计分析实践——Heimdall

图4-2 根因分析渠道定位问题示例图

五、 总结展望

现在 heimdall 体系现已接入1300+运用，成为了研制质量中的一个重要目标，研制人员也养成了重视体系反常状况的习气，为公司事务稳定发展供给技能保证。

一个体系在诞生的时分基本上都会有一些没考虑到的点，而且跟着周边环境的改变，原有的规划也会不满足，优异的体系不是一成不变的，而是渐渐打磨、优化、改善、完善才形成的，每个时期和阶段都有它的价值。一起也要敢于突破原有规划的捆绑，取其精华去其糟粕。

反常量核算数据和反常仓库的效果远不止于此，未来咱们还会将 heimdall 的数据运用于中测验范畴，将 heimdall 中已存在的反常作为基准，从 beta 环境的反常中过滤掉线上已有的反常，再将剩下的反常自动提示给开发或 QA 同学，提高联调测验进程中排查问题的功率，未来的运用场景还会更多！