金融业务系统日志精益化分析

Posted 2022-08-06

大家好，很高兴有这次机会和大家分享一些日志分析方面的心得。金融业日志管理面临着一些共性的问题，日志易在助力数百家大型企业用户建设日志精益化分析体系的过程中，积累了一些经验。借这次直播的机会，和参与本次直播的诸位金融企业相关技术负责人，梳理业务系统日志分析平台的一些架构及分析思路，算是抛砖引玉，希望今后能和大家就日志分析有更加深入的交流。

本次分享共分三个部分。

第一部分会就金融业日志管理方面的共同面临的问题作出浅谈，供大家了解行业现状，这部分起名为“同是天涯沦落人”。

第二部分是我们在与上百家金融企业合作过程中，积累建设日志管理平台的经验，主要围绕场景案例模型进行讲述，起名为“相逢何必曾相识”。

第三部分是关于日志管理平台落地的说明，这里面有诸多细节需要注意。同时，我们也会谈一些日志平台规划化管理的建议，日志规范了，不仅分析起来方便，日常运维管理也会轻松很多，起名为“千淘万漉虽辛苦，吹尽狂沙始到金”。

最后，直播结束后，我们还会针对大家提出的问题作出答疑。

1、同是天涯沦落人

1.1金融业日志分析现状

目前金融业日志分析都面临着一些共性问题，用六个字可以总结 ——“单”、“慢”、“繁”、“散”、“难”、“险”。

“单”： 很多企业的业务系统之间是相互独立的，因为流水号、订单号没办法相互关联；跨业务系统的日志记录分散孤立，很难做关联分析；
“散”：百GB甚至TB级别的日志量分布在数百台服务器上，包含数据分布不均的情况；
“繁”：日志种类多，这种情况就算再精通awk、sed、sort、uniq等指令，排查一个问题也要针对多种不同格式的日志，一次次重定向文件，这种情况对运维人员而言当然是个大灾难；
“慢”：日志系统没有实现实时的日志监控告警，一旦出现问题，不能及时发现；同时日志排障时间消耗很多；
“难”：业务系统多，日志量大，日志每年都在增加，同时系统间的复杂性强，难以实现联动分析，日志价值无法及时得到挖掘；
“险”：日志体系建设不健全，企业日志管理方面面临主机操作风险、敏感信息泄露等安全隐患。

1.2 审视企业日志现状

面对上述问题，如何解决？

俗话说“知己知彼百战百胜”。要解决目前面临的问题，我们先从如下视角来对我们自己的日志进行多维度梳理：

a.日志来源维度：
将我们手中的日志依次分为操作系统日志、网络安全设备日志、业务系统日志、数据库日志等种类。

b.日志需求维度：
明确我们对于日志最为迫切的需求，可以参考日志审计、监控告警、业务统计、关联模型、报表分析、智能运维、安全分析等方面。

c.多样性维度：
掌握自己日志是否存在编码多样性、需要多行合并、交叉打印、目录嵌套、日志冗长、快速切分、格式繁多等情况。

从上述维度加以梳理，借助日志工具将会大大降低日志分析系统建设的难度。

2、相逢何必曾相识

在分享案例之前，我们先从一个新的视角看一下我们的日志。之后我们基于以往真实案例，分享日志分析的思路。

2.1 日志新视角

先看两个日志样例：

上面的单行日志是Apcahe访问日志，下面多行日志是ESB业务系统的日志样例。可以看到这两种日志是截然不同的，同时单行日志格式较为规范，下面的多行日志格式复杂。
原生日志就是一行行的文本格式，日志都是字符排列。
只从文本的角度看日志是不够的，做日志分析，要从结构化的新视角看待日志。请先看下图：

从结构化的视角看日志，可以从内在属性和外在属性着手。
内在属性是从时间戳、字段、字段命名等日志内容本身所具备的信息内容的角度，对日志进行分析。
外在属性是从来源、归属分类、资产信息等维度来分析。来源是指日志来自哪台主机、哪个IP；归属分类是从日志的所属系统及日志用途等方面看日志；日志的资产信息是指日志的负责人、负责人的联系方式等相关信息，可以通过平台将日志与负责人进行关联，以便事故发生后可以直接通知到相关负责人。

2.2 日志分析维度之指标分析

对日志进一步进行分析，就要落到具体指标上了。基于指标分析是日志数据分析最常见的切入形式。

最简单的，可以将一个字段理解为一个指标。对一个单指标来说，分析涉及指标使用场景及用途、可视化类型、基础分析条件等信息。对单指标的分析通常有占比分析、单值分析、趋势分析、同比分析、环比分析、陡变等维度。此外还有一些综合指标需要关注，如成功率、成功率趋势等。不同的指标分析往往选择不同的可视化图形，如占比分析采用饼图、趋势分析采用折线图等。当然，实现指标分析的基本的条件就是，日志中需包含该字段，此外还应知道该字段在日志中出现的位置识别方法。

经过以往日志分析的积累，我们总结出业务系统通用的指标分析项，几乎在所有的业务场景中都有用到。

通用指标分析项中，单值统计有交易成功率、交易量、系统健康度、平均响应时间等，在日志易系统中，可将想要展示的指标放到一张仪表盘上，支持点击单值直接跳转到特定指标或者指标集合分析的详情页。

通用指标分析项中，趋势分析一般会用到某指标的今夕分析、多指标变化率分析，从多指标变化率分析中，可以发现某指标随另一指标的变化情况，当有故障发生时，可据此判断故障是否与某一指标波动有关。此外，趋势分析中的波动区间分析，可以很直观的发现某指标的异常值。

2.3 日志分析思路

业务系统的独特性，决定了其除了具备通用指标项之外，还有特定的分析需求。业务多样性，分析更是难上加难。但是，面对业务更为特殊的场景分析层面，可以遵循后面分享的方法--察外控内法。

察外控内，既可以应对已知业务系统的分析，也可以应对未知业务系统的分析。下面对察外控内简要说明：

察外是将业务系统看做黑盒，关注业务系统上下游项关联系统、接口重要指标。如关注上游交易量、请求量，及下游响应耗时、健康度。

控内是将业务系统看做白盒，从整体视角看业务系统的运行情况，当然也可以是不同维度的最重要指标。控内最主要是从运维、安全、业务维度去把控业务系统。运维维度要关注性能，要对业务、网络、主机性能进行监控，还有日志告警、排障及服务可用性。安全维度应关注异常交易、用户行为等。业务维度则有交易量、趋势、成功率、响应耗时、报表等信息。

察外控内方法在 日志分析ABC模型应用最为广泛。ABC模型一个典型的应用是银行系统服务总线，可以将终端用户通过手机银行发送付款请求，经ESB系统到外联平台的过程抽象为业务上游、中游、下游。

ABC模型示例如下：

2.4 日志系统分析思路

设计企业自己的日志分析系统，首先需要总览系统，站在领导视角上，快速、高效、直观地梳理定义各业务系统整体关键核心指标，而不仅限于本系统重要指标。总览指标可以展现在仪表盘或大屏上，点击跳转，可直接钻取至对应业务系统。

外部梳理，其实就是察外，是指外部的维度梳理各个业务系统之间的关联，关注与自身模块具有上下游关联的系统调用关系，明确对本模块有重要影响的上下游指标。察外时可以使用ABC模型。假设A、B、C系统分别处于业务链的上、中、下游，从外维视角看B系统，如业务系统B的应答失败率较高，在对B系统进行排障时，我们就可以结合上下游系统的某一个具体项，分析这个点是否与故障有关。

内部细分，是指洞察内部模块具体指标项，组织一切对于日常工作有益的分析。

2.5 ABC模型示例

a.统览全局

ABC模型应用第一步是统览全局。即将我们所关心的业务A、B、C的最重要指标统一到一张仪表盘，直览全局。

b.外围视角

之后从业务B外围视角进行分析。

如上图中，B系统应答A系统的交易成功率为89.81%，B系统应答A系统的特殊报文（图中的142报文）交易成功率为99.72%，可以看出，该特殊报文的应答成功率，不是影响B系统应答A系统的交易成功率的真正原因。从B业务系统洞悉C业务系统，从特殊报文交易成功率上进行分析，可从数值或图表中直观了解到二者关系，从图中数据可以得知，B业务系统的故障，与C业务系统交易状态关系不大。

综上，我们可以知道，B业务系统的故障与C业务系统无关，与A业务系统有关。排查掉A系统的特殊报文，再从别的角度分析故障就可以了。

c.内部视角

然后从业务B内部视角分析。

案例一：从业务级与交易级2个视角分析自身业务：

交易级视角关注项：技术失败(超时)计量、交易类型(渠道)计量及统计、耗时甄别、失败明细(时间、全局流水、交易来源、业务类型、耗时)、搜索钻取定位原始日志及上下文；
业务级视角关注项：业务失败及类型统计、交易类型(渠道)计量及成功率统计、搜索钻取定位原始日志及上下文。

案例二：某模块内部自身各环节耗时分析

直接定位内部耗时最长的环节是数据库调用，以便有的放矢进行优化。

案例三：单笔交易定位模型
在对单笔交易进行分析时，通常使用循序图展示交易流程中各环节的调用关系及耗时，方便快速发现交易中断环节。

对于大的支付机构而言，使用ABC模型展现成员行机构运行情况更为直观明朗，尤其在双十一、618之类的高并发场景中，该模型往往能够超乎寻常的效果。在这种爆发场景下，金融企业压力较大，日志易的日志记录也可采用相应的策略，高峰期时优先保证业务性能，高峰期之后追记日志。

3、千淘万漉虽辛苦，吹尽狂沙始到金
落地实现及规范指引

搭建日志分析平台，自然要基于不同种类的日志数据。数据接入是日志分析的第一步，然后便是日志结构化、存储、数据分析。数据分析又包括搜索及可视化，基于数据分析的结果，还可以用来做监控告警及报表展现。

3.1 日志分析平台落地实现

日志分析的关键环节主要集中在日志源识别、数据接入、数据结构化清洗、数据分析等环节。

根据企业实际生产环境，日志数据分别有操作系统日志、网络设备日志、中间件日志、数据库日志、业务系统日志等类型。数据接入有Agent、Syslog、SNMP等方式。数据结构化涉及各种类型日志的清洗方式、字典扩展、正则解析、字段识别等内容，内容比较多，有一个标准化流程的话实施起来会相对容易。数据分析包括搜索、可视化，此外还要考虑监控、定时任务、报表等功能。

在落地交付时，日志易可以从业务维度，根据系统模块进行数据接入，即先调研部分业务系统要实现的分析效果，然后针对这些需求做相应的告警、分析。后续用户还可接入更多的业务系统。日志易也可以从功能维度做日志分析，即先调研所有系统要实现的分析目的，然后再做告警、分析。用户可以根据自身企业的需求选择对应的交付方式。

3.2 日志分析规范指引

建立标准化的日志分析管理规范，不仅会使得企业日志分析有法可依，对IT服务稳定、安全、可靠，业务系统稳健、高效都有不可小觑的作用。

日志系统规范化，包括日志记录规范化、日志采集规范化、日志存储规范化，而这需要基于工单系统实现。需求梳理、评审、平台建设，工单系统涵盖了日志分析体系的各个环节，保证没有预料之外的变更存在，则一切尽在掌握之中，个中妙用不必多说。

日志管理规范化，也是明确角色职责，加强交易状态跟踪，明确问题根源，分析应用性能，满足安全管控、审计的需求。

以上内容，与君共鉴。

谢谢大家这次的倾听，这就是这次分享的全部内容了，根据大家的反馈，我们后续还会开展更多分享。

下面是答疑时间。

4、答疑

问题1：实现链路分析，唯一业务id是前提吧？

有全局流水好或唯一业务ID是最好的。很多环境下不具备唯一业务ID，但如果A和B系统之间有一个共同字段能够实现关联，B和C系统之间也有一个共同字段能够实现关联，我们仍可以把A、B、C三个系统相互关联起来，以实现业务关联分析。这种情况最好是在同一个模块内，日志交叉打印的情况下。跨模块的话，最好有一到两个，或由多个字段合并为一个关联字段，这样也能实现模块间的关联。

问题2：每套系统的日志格式不同，如何在解析的时候进行处理？

对每套业务系统的日志建立不同的日志解析规则，然后分别去解析。

问题3：支持对非在线日志的分析？

所有的日志都基于我们的日志易平台进行采集，可以采集实时日志，也可以采集非实时日志。

问题4：这套体系是和日志内容格式紧密相关的吧？

我们是尽可能对各种规则的日志内容去做解析的。但日志输出还是要尽可能规范，这样不止日志分析方便，日常运维也会轻松很多。

问题5：如果日志格式发生了变化，整套体系是不是就有可能无用了？

日志格式变化，原有的日志规则不能匹配变化后的日志，但日志采集仍在继续，这种情况下日志解析实际上是不可用的，会导致原有日志解析效果受影响。但按照日志管理规范，在日志格式发生变化前，通过工单提交变更申请，我们可以及时更新日志解析规则，从而使日志分析系统完美应对变更，继续发挥作用。

问题6：关于避免这种过拟合，提升模型适应性，你们有做什么工作么？

在先做解析规则后采集的场景下，确实可能发生因日志位置、内容变化影响解析效果。但我们是支持先采集日志，在查询时，根据查询条件去做解析的，当然这种实时查询的情况下，性能是会受到很大影响的。

问题7：对于业务日志的话，是否需要改造？

取决于想要做到的分析效果。如果人工都没办法实现业务日志关联，想做关联分析，自然是需要改造日志的。

问题8：如何提升业务日志质量（因为很多系统不可能说先去规划，存在很大的可能是在继承老项目），你们后面的分析是需要调用链分析项目支撑的吧？单独日志做不到的吧。

确实很多业务系统比较老，没办法去做改造。在现有的日志基础上，我们会尽可能的识别现有日志规则。目前，在采集上，我们能够实现时间戳的自动识别、黑白名单的自动过滤，能把日志中不需要的部分过滤掉，后面通过规则清洗，能把仅有需要的或有意义的字段保留下来。如果老系统实在没有可关联的字段，这时要实现关系分析就相当于无米之炊，就比较难了。
调用链分析确实需要不同系统间的日志关联。单系统也能做关联分析，但只能在这个系统内部做调用链。

问题9：目前你们的AIOps到哪一步了？

我们现在的版本是2.4，在下一个版本，即3.0版本中，AIOps功能就会面世。新版本会在1-2个月之内发布，尽请期待。

问题10：现在Snmp支持源端trap出来，后续会支持get模式取数据吗？

推荐使用API的方式直接从我们这里获取数据。SNMP的话，我们的Agent是支持采集snmptrap和snmpget数据。