1、如何完整的获取到完整的日志？

【问题描述】由于目前云、微服务等架构主要都是采用复用硬件设备资源的方式部署，全链路的日志采集（如采用抓流量的方式）某些交易日志可能会因为在设备内流动（如虚机的几个服务器流量不出机头到达不了物理交换机）。如何解决这类问题？如果采用探针部署，对系统本身又会造成性能损耗，尤其是在高并发高负载的场景。如何解决？

@ljosef 某股份制银行 系统架构师：

建议评估高并发负载的场景，形成完成的测试数据。

我们目前采用了Javaagent对Java应用进行链路日志采集，作为平行于网络流量的链路解决方案，应对不同视角的运维需求。

@luxh08 某互联网银行 科技部门副总：

其他银行不清楚，但是我们是采用纯应用日志方式实现的全链路，和网络流量没有任何关系，其他探针方式实现也不是基于网络流量获取的，通过在应用侧部署探针方式获取应用交易情况，之前银行都是通过网络流量旁路方式进行APM，但是这种基于网络旁路实现的平台不适合微服务和云，不破不立，建议不要采用老的平台去适配新架构。

@yotta_beyond  日志易 技术总监：

在云和容器化的架构下，流量采集方式必然会遇到问题里面提到的抓包问题，通过日志采集是目前来看比较好的解决方案。

采用探针部署对系统本身又会造成性能损耗其实是可控的，毕竟是读操作，另外探针如果加上CPU、带宽等控制条件，对系统的造成的风险也会降低。

另外如果考虑到合规留存，故障定位的因素，日志打印、日志集中、日志分析是避免不了的。

综上，既然避免不了采集日志，那就解决磁盘IO问题吧。

@yxb86101 潍柴动力 基础设施与安全架构师：

这个目前关键出口、聚合出口依然采用流量抓取的方式，通过镜像方式将流量引导至日志分析平台进行处理，这个还是比较好处理的；但对于虚拟机集群内部，目前接触到的都是采用安装代理的方式去处理，这样势必会造成一定的性能影响，容易对业务造成影响。如果采用非代理模式，那监控的功能就降低，日志可参考性也会降低。但目前确实没有很好的解决方案，只能在初期规划时候提前预规划好用于日志分析的计算资源量，以保障降低对业务的影响。

@饶琛琳 日志易 产品总监：

是的。传统的抓流量方式解决不了这个问题。

考虑性能损耗问题的话，相比探针来说，还是建议采用应用自己打日志的方式，因为打日志的行为相对简单，对系统性能带来的损耗非常容易评估计算，打日志时还可以通过内存缓冲区合并一下，减少 IO 次数，损耗就更小了。而探针内部逻辑太多，哪怕你正儿八经做了压测，也保不齐什么超过测试集范围的业务逻辑会触发什么新问题。

2、如何降低多语言日志客户端的研发和维护成本？

@ljosef 某股份制银行 系统架构师：

建议还是从业务需求方分析具体的使用场景，从技术上合并或者排除非必要的日志客户端工具种类，这是问题的基础。

其次，技术的选型无外乎商用、开源或者自研几种策略，目前针对日志客户端的场景，建议选择一种开源产品的客户端工具，进行长期维护。

@yotta_beyond  日志易 技术总监：

目前在linux、windows、容器、arm 架构等前提环境情况下go语言开发的agent 基本够用的。

在维护方面，agent的维护需要考虑到几方面：

（1）agent的批量部署，批量升级，批量下发策略

（2）agent性能的控制，句柄的控制，带宽的控制

（3）agent采集配置的界面化管理能力

（4）agent采集日志的黑白名单能力，自动识别能力（自动识别时间，自动识别编码，自动多行合并）

@luxh08 某互联网银行 科技部门副总：

我们采用的纯日志方式实现的全链路，制定全行统一的日志的规范和标准非常重要，对日志的输出格式进行统一要求，对研发采用的语言没有依赖。

@饶琛琳 日志易 产品总监：

个人推荐尽量复用开源领域比较成熟的日志客户端项目，将维护成本转嫁给整个开源社区。而且一般开源界成熟的日志客户端，都会支持比较主流的日志输出协议，如 File/HTTP/Syslog/GELF 等。那么多语言情况下也不用担心后续的采集接收有太大的问题。

3、金融行业应该如何选择一个强大的统一日志平台作为技术底座？

【问题描述】如果通过日志报文采集方式实现的全链路追踪平台和传统的APM相比来说会有一定的延迟性，需要建设强大的统一日志处理平台，提升日志采集、传输、处理的效率来缩短业务监控的延时性。

@luxh08 某互联网银行 科技部门副总：

日志平台是企业的IT技术基础底座，后续的微服务治理、智能化运维等工作的基础平台，大部分企业的日志体系都是基于elk模式搭建的，开源的产品在日志量可控的量级上没有任何问题的凸显，主要有以下三部分的建议，一是如果日志量每天达到T级别就需要对es框架进行优化，但是这部分工作可能需要专业的公司或者团队来完成，一般企业可以采用商业化的产品，比如日志易的beaver，日志处理性能比es要提高2倍以上。二是要对日志进行归档处理，减少在线分析的日志量，根据应用特点在日志平台保留一周左右的日志量，其他历史日志归档到对象存储或者分布式存储上保存。三是可以提升硬件的性能，增加更多日志分析节点或者采用性能较高的服务器作为日志节点。

@秋名山车神 日志易 项目经理：

1.性能方面：第一要考虑到采集端agent的性能（既要保证对服务器cpu使用率，也要保证采集的速度），第二要考虑解析的速度，优化解析效率，第三要考虑数据入库（es或beaver）性能，结合实际使用情况配置模版或其他优化项，最后整条链路下来所消耗的时间，要考虑集群整体负载，券商的交易高峰压力会比其他行业更为明显。

2.稳定性方面：结合性能方面进行集群的阈值和性能拐点的测试；

3.架构方面：有条件的尽量做到日志的冷热分离；有实际计算指标需求的情况增加flink、spark streaming等组件。

@ 招商银行 系统运维工程师：

如果实现全局应用监控，传统APM性能容量会是一个不小的挑战，如果全面上云后应用实例超W级别后，APM存在一定的瓶颈。

全链路监控本人经验，日超20TB的情况下，如下平台设计可以做到分钟级，已经能很好满足全局应用全链路监控的需求。

在线：Spark Strenming

离线：Spark

时序统计：ES

明细数据：Hbase

实时架构图：Neo4j

其他：Mysql

4、全链路如何扩大跟踪覆盖面？

【问题描述】企业会更加期望能实现端到端的链路跟踪，也即从浏览器、APP端开始，一直可跟踪到后端交易的执行，在这个过程中，链路节点上除了微服务，还有NGINX、F5等各类节点，如何能实现左右关键节点的跟踪也需要考虑。

@luxh08 某互联网银行 科技部门副总：

全链路实现的方法有三方插件探针或者通过日志报文的改造两种方式，只能覆盖服务之间的调用关系，涉及到F5、网络设备、防火墙可以通过网络全流量监控平台，设备日志进行补充，如果需要实现端到端的拓扑关系监控，后续可以考虑通过智能运维平台的统一监控功能将全链路、网络全流量平台、统一日志平台、基础监控平台等等的相关数据和日志进行统一采集分析，实现端到端的图谱关系。

@yotta_beyond  日志易 技术总监：

对于应用层，各应用模块可以通过链路追踪方式进行端到端串联

对于逻辑层（数据库，中间件），物理层（虚拟机，物理机，容器），网络层（F5，交换机）可以通过监控单节点性能和日志方式，把性能和日志都发送到统一日志平台，结合时间维度和CMDB信息，与应用层数据做关联分析，形成长流程端到端监控

通过积累上述数据，下一阶段就可以尝试进行根因分析。

@yuxb 潍柴动力 系统架构师：

全业务流程跟踪涉及很多的工具，需要对业务应用日志，流量日志，数据等进行全方面监控，可以配置集中的日志收集和处理平台，引入大数据及ai分析技术，如splunk。关键还是打通数据能够联动分析

5、金融企业存量系统运行多样复杂环境中，如何实施全链路日志监控？

【问题描述】大金融企业存量业务多，运行环境复杂。支持全链路监控涉及众多业务系统的改造，而存量系统运行在大型机、小型机、物理服务器、虚拟机和容器等多环境中，如何完成存量系统的改造是实施全链路日志监控的基础。

@luxh08 某互联网银行 科技部门副总：

根据我行经验，日志报文规划和标准要尽早制定，在项目需求和开发阶段就把日志规范要求下去，如果涉及到老系统的改造，就需要付出一定的开发成本，技术是前提，但是要把规范和标准执行下去，管理手段是关键。

@ 招商银行 系统运维工程师：

存量系统全链路改造实施个人经验如下：

1.设计好存量系统的通讯报文协议，包括TCP等私有协议的支撑；

2.设计好存量系统日志规范，根据不同情况可以选择：写本地、异步发送KAFKA、旁路解码等方案。

@饶琛琳 日志易 产品总监：

在实施全链路监控的过程中，一般建议优先从比较新的系统开始，比较容易见到效果。在这个过程中，尚未完成改造的存量系统，对于全链路监控系统本身来说，和数据库、消息队列中间件一样，可以视作一种第三方服务，在链路日志中记录为远端调用过程即可。

当然，最终还是希望能完成存量系统的改造过程，达到各系统之间日志规范一致，链路跟踪的效果也更加明显。

6、对日志格式和日志输出规范有何要求？

@luxh08 某互联网银行 科技部门副总：

日志输出必须能够提供以下几点信息，1、（Traceid）交易的全局唯一流水号，需要全链路透传。2、（Spanid）交易调用的单元ID,用来标识节点单元。3、（ParentSpanid）父调用单元ID，交易接受的上一个单元ID。再将错误码，交易耗时等等信息都通过日志格式输出，实现整条交易链路状态的展示。在出现交易超时等问题的时候，可以比较清晰的判断问题节点、每个节点耗时时间等等。

@yotta_beyond  日志易 技术总监：

建议采用json格式输出，便于扩展，统一时间戳和日志等级。

traceid，parentid，spanid可以实现单笔交易的串联，此外建议制定规范的时候明确返回码类型区分业务错误（如余额不足）和系统错误（如数据库连接失败）提供成功率统计的准确性。

同时，建议增加 渠道，交易类型，产品类型字段，方便用于运维统计监控。

7、跨容器实现链路跟踪？

【问题描述】如果一条链路中还涉及容器环境，根据容器网络选型的特点，如何使得链路跟踪能抓到容器云内部的链路走向并统一展现到整体链路中，也是比较复杂的问题。

@siguadantang 苏宁银行 技术经理：

链路追踪是一件比较难做工作，但在故障分析，应用调优，应用监控等方面起着至关重要的作用，可以说做好链路追踪，能使得如上的工作效率大幅度提升。

应用容器化之后，又增加了容器层，因此使得链路的追踪变得更难。目前的主要APM技术有：

skywalking，pinpoint，zipkin，jaeger等。

可以采用3种方式部署：1. 侵入方式，以插件形式集成于业务运行时环境，例如：将skywalking 集成于jboss运行环境；2. 与服务无网格（istio）集成，实现链路追踪，例如：jaeger；3. 以sidecar方式运行；

如上仅供参考。

@ljosef 某股份制银行 系统架构师：

网路链路和服务链路作为两种不同视角的链路能力，可以优先考虑网络链路能力的构建，在自主研发能力和业务规模的基础上，逐步增强日志链路的能力。

考虑到容器环境的网络复杂性，应考虑选型具有支持underlay、overlay多种网络模型的流量采集工具，基于Vxlan包协议能够进行拆包分析。当然这也有个前提，容器网络也要进行精确的网络分区规划，避免网段重叠。此外，考虑目前容器网络技术的发展，选择合适的路由或者underlay网络也是比较可行的一种技术方案，这样传统的流量分析工具仍然可用。

@luxh08 某互联网银行 科技部门副总：

我补充下，还有一种方式是通过应用日志的改造，不用三方探针，和底层环境无任何依赖。

@饶琛琳 日志易 产品总监：

云原生基金会下的主流容器网络实现，都提供了一些流量跟踪的基础功能。著名的比如 Cilium 的 Hubble 方案通过自己的 eBPF 层获取；比如 kiali 方案通过 istio 获取等。目前容器网络选型尚无统一的最佳实践，还需要按实际情况来研判。

更实际一点的来说，既然上了容器，说明这些业务系统都是比较新的，那么通过应用日志改造的方式，走日志分析角度做链路跟踪，应该比走网络流量分析更加合适。

8、应用日志报文格式改造的成本难点如何控制？

【问题描述】所有涉及到追踪的业务场景都需要进行代码的改造，不同项目组在能力和时间上都不相同，涉及的沟通成本和改造成本也不可预知。那在进行应用日志斑纹格式改造中成本如何控制？

@luxh08 某互联网银行 科技部门副总：

新建的项目可以要求遵循日志规范进行开发，对存量的应用，为了减少项目开发改造成本和全链路实施复杂度，可以选择一些重要的业务场景，比如重要的互联网渠道类交易业务，三方支付、互联网贷款，减少改造的应用节点的数量，框定一定的应用范围。

@ 招商银行 系统运维工程师：

为了成本与节奏可控个人看法如下：

业务系统：关键流量业务先行；

链路改造顺序：核心、业务逻辑、渠道；

改造逻辑：核心与业务逻辑采用框架层实现，渠道层尽量提供统一的SDK。

@yotta_beyond  日志易 技术总监：

应用日志改造或者业务链追踪是未来必须经历的一个阶段，需要做好长期作战的准备，必须迈出第一步；建议可以先选择新开发的业务作为试点，其他业务系统在需求升级过程中再逐步推广。

9、针对日志全链路追踪，是否有必要将公司现有日志体系对接到行业标准，若是，如何对接？

@luxh08 某互联网银行 科技部门副总：

根据我们的经验，日志的规范和标准要乘早制定，不管是基于日志的告警分析、全链路追踪、或者后面的智能运维都需要规范化日志格式，并且在规划阶段对字段位要有充分的预留，为后续其他项目进行提前考虑。日志规范和标准的制定还是需要根据自身的业务特点和运维需求进行考虑，没有一成不变的行业标准，比如google dapper框架只是针对全链路追踪这块有参考，比如需要统一所有日志的级别定义和错误代码标准，日志的规范不能局限于全链路的需求，日志的价值非常大，后面我们需要通过日志挖掘很多有价值的信息，比如业务交易的分析挖掘，智能运维的日志分析需求等等。

@yotta_beyond  日志易 技术总监：

全链路日志一般可以参考dapper，基于skywalking或者zipkin进行改造，改造后会单独输出一份全链路追踪日志，但对于原有业务日志，大部分都没有流水号，可能只有线程号；因此我们建议在全链路追踪日志里面增加一个扩展字段，把原有业务日志中的线程ID加到扩展字段里面，通过线程ID+IP+时间 实现全链路日志和现有业务日志的关联

10、多种开发语言应用难以制定统一日志采集标准，对于业务日志采集和分析都带来了挑战？

【问题描述】异构技术栈，日志采集标准化程度不高。以Cobol、C、Java、JavaScript等各种开发语言为基础的业务应用难以制订统一的日志采集标准，对于业务日志采集和分析都带来了挑战。听听同行专家的一些建议和实施方案。

@ljosef 某股份制银行 系统架构师：

我们的做法是在业务层定义一致的描述，在组织内推广，在实现上基于不同的方式实现，譬如C应用会自己输出日志，而Java应用更多采用无侵入的方案，如skywalking进行字节流的采集。

@饶琛琳 日志易 产品总监：

在环境内存在大量已有系统的前提下，强制完全一致的日志标准确实是不现实的。通常来说只能要求应用研发方面做到至少覆盖基础数据，采集方面做到对齐元数据，然后通过引入更高级的事后分析手段，来达到类似效果。

采集元数据，比如来源 IP、归属应用、软件路径和依赖等。基础数据，比如时间戳、日志级别、线程号、流水号等。facebook 在 2016 年曾经公开过一种方法，结合时移补全技术和剪枝推理算法，在只有流水号的大规模系统上近似的推导链路拓扑关系图。万不得已的情况下，可以作为一种参考。

@anonymous：

1、主要是统一日志输出格式，例如统一输出成  json / csv / txt ，如果有些开发语言没有提供这样的工具，可以自己开发，或者按照现成格式输出再转化到统一的格式。个人感觉这个挑战不是很大，尤其是都是自研的时候。

2、在哪些地方输出日志，以个人经验主要是 1. 关键流程跟踪 2. 关键数据跟踪 3. 接口和接口调用处。

11、银行统一日志平台建设建设思路？

【问题描述】计划搭建一套全行的统一日志分析平台，一般应按照怎样的建设路线进行建设、平台的主要应用场景、产品选型时需关注哪些关键点、具备什么条件才适合使用开源日志产品自建？容器和虚拟机，一套应用多种架构并存，如何统一进行日志收集查询和和分析？是否有行业内通用的日志规范。

@yotta_beyond  日志易 技术总监：

1.首先要满足日志留存的合规要求，这就要求日志平台能兼容各种数据源的采集，包括虚拟机、容器、数据库，兼容各类操作系统

2.能根据日志类型按需制定留存计划，能进行日志冷温热数据降存处理

3.能实现快速数据检索，快速故障溯源

4.能具备日志分析能力，挖掘日志价值，包括能从日志中提炼交易量，耗时，成功率等黄金指标进行同环比，突变，缓慢增长等异常分析

日志规范可以参考opentracing的标准，也可以咨询一下我们公司的同事

@luxh08 某互联网银行 科技部门副总：

日志平台本身并不重要，在早期日志量不大的时候可以采用elk开源框架搭建，日志量达到一定量级可以替换成商业化产品，日志平台建设的最难点是要形成统一的日志规范，把后续的全链路平台，智能运维平台考量进去，形成统一的日志改造标准，让所有应用开发人员都能接纳和执行，并且对现有的应用的侵入性在可控的范围内。

12、日志分析平台性能方面问题应该从哪些方面予以解决？

@luxh08 某互联网银行 科技部门副总：

根据我行的实施经验，主要从以下三个方面，给出一些拙见，首先是要优化日志分析的协议，我们最初采用的是开源的ElasticSearch，当每天日志量超过1T级别之后，搜索日志变动非常困难，我们采用了厂商经过优化之后的处理引擎，性能问题得到了较大的提升。第二是在线日志量保存7天周期，日常检索的日志也只需要一段周期的日志，其他历史日志进行归档保存，减少日志处理的数量来提高检索效率，第三是硬件层面，日志平台对服务器内存和IO要求比较高，采用内存和IO性能比较好的服务器，在不计成本的条件下，也可以通过横向的扩展来提高性能。

@yotta_beyond  日志易 技术总监：

1.采集速度，采集端的性能消耗，采集端对采集文件大小，采集文件数量的可控性

2.ETL日志清洗的速度

3.搜索引擎的入库速度，搜索速度，大分组统计速度、长周期日志搜索的健壮性、以及日志存储空间

13、如何设计链路日志的实时计算逻辑也是亟待解决的难题？

【问题描述】链路日志规模大，计算分析复杂，存储容量大。链路日志采集后，日志量成千倍增长，而业务决策、故障排查、扩缩容等都需要可靠且实时的计算能力，如何设计链路日志的实时计算逻辑也是亟待解决的难题。

@yotta_beyond  日志易 技术总监：

链路日志在高采样率情况下，日志量可达TB/天以上，交易笔数多，分组统计大，如果全靠入库后再进行统计，对搜索引擎的压力会很大，建议考虑引入Flink流处理引擎，在日志ETL过程中就进行流式计算；但链路计算场景会比较较多，计算过程比较复杂，需要用到很多流式计算管道，所以可以考虑在Flink流处理引擎基础上增加可视化配置算子，降低运维人员的使用难度

@ljosef 某股份制银行 系统架构师：

实时计算框架flink可以给出一定的参考，通过可扩展性的计算和模版化的规则引擎提供实时计算的能力。一种可参考的技术框架可以设计如下：

beat->kafka->flink->alert
             |
           ES

@luxh08 某互联网银行 科技部门副总：

通过日志采集的全链路追踪功能，本身就没有传统的网络旁路方式的APM实时性高，但还是可以通过采用高性能的日志分析平台、投入硬件配置来达到秒级的延时，对实时的交易监控还是可以接受的。

14、日志采集后是否需要在elk之外引入其它的数据分析工具？

@yotta_beyond  日志易 技术总监：

1.日志采集后需要考虑海量数据留存问题，这涉及到日志压缩，日志裁剪，不同日志保存不同时间等问题

2.另外日志价值不仅在于搜索和留存，通过好的日志分析工具，可以更好挖掘日志价值，如可以做单笔交易快速追踪，交易量/耗时/成功率的实时监控，业务运营分析等等

@ljosef 某股份制银行 系统架构师：

具体工具的建设通用的标准还是用户，有用户基础就可以考虑独立的工具支持，譬如平台管理员更关注系统的审计合规性、应用运维更关注错误日志的上下文、业务人员更关注事务性的执行时间，不同的场景都应该有不同的分析工具支撑。

根据自身企业的技术平台架构规范，可以考虑嵌入式开发或者集中式开发过程。合合分分，确实也不存在标准的答案。

@luxh08 某互联网银行 科技部门副总：

elk是日志平台的标准架构，能够满足基本的采集、传输和分析，如果有其他的需求可能需要其他平台，比如全链路功能，比如智能运维平台。日志是原始数据，好比是是食材，你需要什么口味就需要什么调料和厨具。

15、全链路日志发起端如何判定，异步非实时交易能否跟踪？

【问题描述】全链路日志每次的tracerid从源头开始生成，对于第三方的业务，一笔交易需要和第三方交互的情况下，如何确定全链路？对于异步非实时交易，例如：将交易信息送入队列后，从队列里定时处理，这种情况怎么进行日志整合，全链路展示？

@luxh08 某互联网银行 科技部门副总：

第三方交互的情况下，如果和三方实现端到端的全链路监控非常困难，业务场景的全链路需要将所有覆盖的应用交易节点需要进行统一的日志报文头规范进行代码改造，在三方节点不改造的情况下，对三方交易节点只能进行被动的监控，比如可以监控交易从三方的回盘时间，三方节点的交易状态无法获取。异步非实时业务不建议进行交易全链路交易监控，可以根据业务特点定义基于日志规则的实时告警。

@秋名山车神 日志易 项目经理：

异步交易日常见到的会分成两种：

1.A系统发送请求到B系统，B系统会进行批处理（比如满100笔或5分钟处理一次），A系统会处理其他任务，B处理完成后发送应答到A系统；

2.A系统发送请求到B系统，B系统会进行批处理（比如满100笔或5分钟处理一次），A系统会每过30s向B系统发送一个请求询问交易是否完成，B系统会返回“处理中”或“处理完成”。

针对第一种情况暂时没有特别处理方法，针对第二种，可以将B系统返回的“处理中”或“处理完成”状态作为一个判断标志，但是在计算指标的时候应当考虑窗口时间。

此外上述两种情况都可以在异步交易处理完成后，将日志作为同步日志输出出来，缺点是时效性不足，可作为前一天的分析。

16、在没有全局流水号的情况下，如何自动发现关联，实现日志全链路分析？

@yotta_beyond  日志易 技术总监：

这是一个难度很大的问题了，我们曾经尝试过几种场景：

1.如果是ESB架构的，因为每个模块的接口调用都通过ESB总线，所以通过ESB总线的日志可以将全链路串联起来。

2.手机充值会经过APP->支付网关->CRM->BOSS 这样一个流程，没有全局流水号，但APP跟支付网关会有唯一订单号，支付网关跟CRM有唯一工单号，也就是说每个环节之间是有唯一标识可以过滤出单笔交易日志，我们通过SPL（可编程搜索语言）实现这种串联分析。

3.手机银行->前置->核心 这样一条链路，没有全局流水号，模块之间也没有唯一标记，但每个模块都记录了报文内容，我们通过SPL对报文内容里面的账号，ip，交易类型等字段做相似度分析，将相似度高的报文日志串联起来（简单来说就是把运维人员查找日志的过程通过SPL做自动化操作。

以上三种场景都是临时的解决方案，目前看最彻底的解决方案还是dapper那种业务链追踪方案。

@luxh08 某互联网银行 科技部门副总：

没有全局流水号，没办法将业务场景进行串联，关联不了业务交易，不管是基于日志方式还是三方探针方式，全局流水号是必须的条件。

原标题：银行业进行全链路日志分析难点探讨

如有任何问题，可点击文末 阅读原文 到社区原文下评论交流

觉得本文有用，请转发或点击“在看”，让更多同行看到

• 企业微服务转型过程中的业务全链路分析思考及实践

  https://www.talkwithtrend.com/Document/detail/tid/442257

https://www.talkwithtrend.com/Topic/7455