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

本次分享共分三个部分。

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

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

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

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

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数据。