上期我们介绍了：《告警全生命周期管理的思路与落地实践》，本期我们聚焦可观测的另一个重要支柱——日志管理，从日志的数据特点角度出发，分析日志数据在可观测体系中的意义，深度剖析日志与可观测体系融合建设的难点与思路，并分享企业日志系统设计选型思路以及落地实践参考。（关注公众号嘉为蓝鲸获取PTT免费下载链接）
从数据特点看日志与可观测
1、指标数据和日志数据的区别
首先我们来看一个企业中比较普遍的现象，当系统发生故障时，运维人员通常关注指标类数据，而研发人员更“钟情“于日志数据，为什么会有这种区别呢？
从两个方面来分析，第一个方面就是运维与研发自身职责的不同，运维更希望能够快速的解决问题，而研发更注重于准确找到问题的根源。第二个方面就是指标数据与日志数据的本身特点具备着差异性。
运维人员能够通过指标数据，快速地了解当前系统的状态，通过指标聚合，从业务一步步追随到集群、再到具体的节点。而日志数据能够详细记录到代码执行的过程，如果能够收集到包含根因的日志数据，那么研发人员就可以非常准确地锁定故障发生的位置和原因，从而进行修复工作。
展开全文
指标数据：以数字形式呈现，可聚合并持续稳定输出，数据直观、精确，通常用于查询和展示。
日志数据：以文本形式承载，不可聚合，输出并不具备周期性，通常数据量较大，需要从海量日志中找到所需要的字段进行进一步的处理。
2、如何实现破局，发挥日志数据价值？
透过以上这类现象，不难发现，日志数据在传统的运维过程中，由于数据量大，价值信息少，文本形式的数据也无法像指标一样，进行有效聚合，掌握全貌，日志数据无法高效定位，也使得日志在传统运维中应用范围受到限制。
而如今可观测时代下，日志数据要想解决以上存在的这些问题，发挥数据价值，实现成功破局，核心必须聚焦在提升日志数据传递到人的价值密度。通常商业化或开源日志工具会具备以下四种特点，实现日志数据价值呈现：
● 日志主动监控：利用机器来自动化检测文本，获取有效信息后再输出。
● 结构化：清洗成结构化数据后，对某些字段进行统计。
● 可观测串联：将其他类型的观测数据于日志串联，快速定位。
● 日志聚类：将日志用机器学习算法进行分类后再统计。
前三种往往是单独在日志系统内部可以完成的，第四种则会涉及到可观测的体系化建设，这里可能不只是一个技术实现的问题，还需要依赖企业对可观测理念的感知和认可。本文也重点就这个话题进行展开。
3、可观测三大支柱数据联动，快速定位问题
云原生时代IT可观测的三大支柱数据：Metrics，Tracing，Logging，日志数据在其中承担着“排障的最后一公里”的角色，基于其信息量大的特点为研发、运维提供最直观丰富了解到IT系统运行的细节信息。
随着可观测体系的技术发展，可观测三大数据的融合和串联，已经成为提升日志价值信息密度的重要手段，前端的Metrics，Tracing数据就宛如快捷的交通工具，而故障的最后一公里就需要依赖日志数据来支撑，融合串联，快速定位关键信息点。
4、日志数据在可观测时代的全新意义
近年来，随着SRE理论的推广，运维角色职能发生了变化，从聚焦于底层资源的稳定性，变为需要关注整个服务对上层业务支撑的可靠性，这个过程中，对全局架构和上层业务的一定了解是必须的。
在这种情况下，传统的监控指标已经不满足于运维的需求，要从运维角度去了解整体架构和业务，而这一过程中，可观测技术就是一把钥匙。在可观测体系中，日志数据代表着一个个Event事件，不再是大面积的平铺陈列，而是作为观测结果的必备属性，与其他数据相辅相成，在新的运维模式下扮演着更加重要的角色。如此即是可观测技术发展给日志数据赋予的全新意义。
开源社区与企业实践探讨
以上是基于理论来阐述新时代日志和可观测密不可分的关系，那么在实践层面，可观测技术又是如何推动日志数据的呢？我们首先先了解一下开源社区关于日志的发展历程。
早期的可观测开源项目基本都是围绕着 Trace 这一类数据开展的，而随着可观测技术的发展，可以看到，日志在最新的OT协议中，已经被纳入标准规范。
（信息来源：OpenTelemetry）
OT协议希望能够统一日志规范，其目的也是想将可观测三支柱数据中最难结构化的数据也进行一定程度的规范，最终形成一套相互关联的数据作为可观测平台的数据后台。这个在其官方推荐的新版OT数据采集架构中就可以体现，它希望我们在汇聚三种数据的时候，有一个统一的富化过程，加强三种数据的关联性，从而能更好发挥观测数据的实际效用。
（信息来源：OpenTelemetry）
接下来我们来看一个有趣的企业实践，很多企业会尝试去使用日志数据作为底座来建设可观测平台，认为这是可观测性建设的一种可靠方案，但事实上，基于日志数据构建可观测体系的方式仍然是优劣并存的。
如果未来OT协议真的能覆盖到每种观测对象并将日志输出标准统一，那么这种方式确实有一定的好处，除了代码无入侵以及组件复杂度降低，更重要的一点好处就是日志数据和其他的观测数据可以天然串联，更方便实现前文所提到的串联排障以及架构分析。
但是目前这种方式也存在很大的局限性，规范推行的本身也是需要一定时间的，而且很多企业所拥有的存量系统十分繁多复杂，如果进行改造，建设可行性和周期都是一个很大的问号。
接下来我们就来针对日志与可观测融合建设的几个难点进行更加深入剖析，给出一些的有效的建设思路和方法。
日志与可观测体系融合建设的难点与思路
1、可观测体系中的日志与其他数据串联的难点
前面提到，日志数据可以通过可观测数据的相互串联来提升自身的数据价值，那么在具体建设中会遇到哪些难点呢？
难点一：数据格式不统一
在中大型企业中，还有不少老旧设备的日志，这些日志数据需要经过加工处理才可以识别出必要字段
解决思路：清洗转化，格式兼容
难点二：数据采集方式不统一
指标类数据，目前流行的采集方式已达上百种，有特有协议，有自定义输出，但一般会在demension中包含资源ID之类的上下文信息
解决思路：提取公共因子为关联线索（时间、资源ID等）
难点三：烟囱式工具，前台界面无法串联
很多企业有传统的监控工具，也有专门的日志系统，即使数据关联上了，两者的界面难以打通，串联观测的体验仍旧不佳
解决思路：尽量选用可拓展性较强的产品，或者一开始建设时就选用融合设计的产品
2、关联日志数据的解决方案
针对这些难以关联的问题，我们也有对应的关联手段。同时企业间存量日志情况各不相同，可以使用不同的方式做可观测关联。
通过执行时关联
日志、跟踪和指标都会记录发生的时间或时间范围。这是最基本的关联形式。
通过请求上下文关联
尽可能通过在日志记录中包含 TraceId 和 SpanId 来记录日志和请求的关系，这样每次跟踪到一条具体的请求时，也能快速找到这个请求产生之后所触发的日志。
通过资源上下文关联
指标数据和跟踪数据中也会包含一定的资源数据，例如主机IP或服务地址，如果能确定好这些资源关系的映射，可以进一步缩小关联日志的范围从而做到精准排障。
在实际的可观测系统落地的过程中，不同类型日志需要采用不一样的关联方式，常见关联方式如下图：
企业日志系统设计思路与选型建议
1、日志系统设计思路
如何设计企业日志系统呢？传统日志系统通常采用5层式独立结构，但这样的建设模式，排障时需从大量日志数据入手，难以快速定位到问题。
而随着可观测技术的发展，很多企业开始建设监控系统、日志管理系统、调用链追踪系统，但由于分开建设，底层数据之间无关联。虽然实现了三大支柱数据的系统建设，但彼此之间属于烟囱模式，无法有效联动，难以有效提升故障定位效率。
而双价值链条所驱动的企业级日志系统，通过日志数据流转链和可观测全景数据链的驱动，解决了日志数据“管理难”，“应用难”的问题。全栈可观测平台的建设，提供了一站式的排障能力，支持统一告警与统一展示，降低故障排查难度，提升排障效率。
2、企业日志系统选型建议：
结合上文提到的设计思路和难点，我们为企业日志系统选型提供以下几点建议：
选用覆盖完整的，且各类观测工具可自由组合的可观测平台
覆盖完整的工具或平台，往往从一开始就会考虑几种数据之间的融合设计（不仅局限于数据，还有UI界面上的串联），避免烟囱式建设。
同时以融合理念进行设计的产品，可以根据自身现状分批、分阶段建设，有限控制建设成本，实现最终的可观测体系建设，让企业能够顺利转型过渡。
选用支持开源协议的云平台或商业产品
顺应业界主流趋势：开源社区（OT）已经在很早期就开始设计几种数据的关联关系，并逐步迭代。
方便拓展对接：可以与自己早期使用的开源工具或者组件相互对接，兼容存量系统。
生态长存：采集和处理工具千千万，唯开源生态长存，可拓展和替换是必须考虑的因素。
需具备强大的日志清洗能力，沉淀常用组件清洗模板
助力标准化建设：有利于减轻落地推广的难度，提升观测体系的覆盖度，沉淀经验和标准，也有利于规范的落地。
案例分享
1、某新能源企业运维一体化项目
建设背景
1. 日志数据异构：和多家国内外企业有合作，对接的核心系统多达数十个，有自研、外购、外购二次开发、开源改造的企业系统，架构不一，日志多样且分散。
2. 日志规模爆发式增长：自建大数据平台进行供应链分析、设备健康管控以及园区智能管理，日志规模随着新能源业务迅猛发展而爆发式增长，每日TB级别日志流量，日志数据采集链路性能压力极大。
3. 日志主题划分困难：多业务方，相互依赖关系复杂，日志主题划分难度大，无法高效查询分析日志，无法关联分析日志。
4. 硬件监控落后：缺乏有效的监控手段，硬件设别厂商多种多样，需要针对每种硬件设备制作专门的监控指标采集插件或告警源插件，成本极高，且需要专门的技术人员针对这些硬件的指标数据进行值班监控。
建设内容
针对该企业现状，嘉为鲸眼日志中心为其打造了相契合的解决方案，集中纳管公司60+业务、4000+节点的日志，日数据量3TB+，制定60+系统的200+项监控策略，出现故障问题及时多渠道通知对应的专业人员进行排查，故障响应效率提升30%以上。
2、某银行企业日志集中化改造项目
建设背景
1. 日志串联繁琐：运维人员查看日志时往往需要根据交易串联日志，当前日志串联是通过各个应用管理员人力传递式查询（业务系统负责人查看本系统内的关键字，查找到相关信息之后，传递给其他系统的负责人），繁琐且耗时。
2. 管理维度不同：根据企业组织架构有两个运维部门，基础运维室负责运维中间件、数据库、系统日志，需要跨业务管理；应用运维室负责运维各业务部门的应用日志，需要业务隔离。
3. 信息泄露风险：银行内部通常有许多外包人员，并且有时候需要将日志数据发给系统服务商进行分析，日志中又包含了大量的客户敏感信息，如果任何运维人员都可随意查看日志中的敏感信息，信息安全风险将无法评估。
4. 存储成本高昂：为满足审计要求，需要长时间保留日志，日志存储成本高。且日志应用场景复杂，偶尔短时间大批量消费日志。
建设内容
银行对于日志数据的安全和存储都有更高的要求，嘉为蓝鲸根据企业组织进行了精细授权管理，同时日志数据流转处理过程中都进行了加密和脱敏处理，保障银行的安全性需求。除此之外，针对银行海量的日志数据存储需求，采用三层存储金字塔架构，降低存储成本。
完成了数据源接入2000+，数据清洗1700+，日数据量1TB+，存储成本降低50%以上，监控策略300+，仪表盘60+，沉淀30+采集配置模板、清洗模板、仪表盘模板。
3、某车企云管&研发运维一体化项目
建设背景
1、日志规模庞大：集团业务发展，整合集团“两地三中心”，承载各类集团管控任务，支撑各事业部、品牌业务发展。集团现有云IaaS、PaaS、微服务治理服务，主机数1000+，日志规模庞大。
2、技术栈复杂：正在企业IT运维转型的道路上，从传统的单机应用迈向云原生应用，现有私有云平台、华为混合云平台、容器平台，其中还包括14项云服务，技术栈复杂导致故障定位异常困难。
3、业务变更频繁：应用系统敏捷开发、快速迭代，迭代周期缩短到2个月，导致故障数量增加，日志频繁变化，还可能存在潜在的应用性能问题，对运维人员提出了更高要求。运维人员难以适应业务日志变化，难以通过历史经验进行问题定位。
4、人工运维困境：不同应用系统的编程语言多种多样，日志格式繁多且不断变化，依靠运维人员手动配置正则进行日志清洗非常低效。同时日志量级大，报警多，一些无关的错误日志容易掩盖真正的问题。
建设内容
该大型企业主要问题在于业务的高速发展带来了海量数据，复杂的技术栈，频繁的变更，对运维的要求越来越高，人工运维已经难以快读定位并处理问题。通过Trace全景分析+Metirc波动分析的建设，结合明细日志log数据，建立全景数据链条，从根源解决问题，快速定位故障根因。
对于人工运维难度大的问题，引入嘉为鲸眼AI能力，对日志进行日志聚类、模式智能异常检测、模式趋势可视化等人工智能手段方式，帮助运维人员快速掌握日志全貌，敏锐捕捉动态异常，动态配置监控策略，大大提升运维人员故障定位效率。
以上是嘉为在日志建设中的一些典型案例，感兴趣的读者可以点击下方图片查看回放或下载直播PPT获得更多相关内容。
当前，可观测性建设仍然在高速探索的阶段，不同的企业运维建设阶段不同，对于全栈可观测能力的构建也有适合各自的建设路径，本期我们仅仅是对日志系统之于可观测的意义以及日志运维场景工具设计和落地实践进行了分享，如果您在日常运维中也遇到了可观测建设的相关问题，或是对可观测有建设需求，欢迎联系我们！
欢迎关注公众号：嘉为蓝鲸，联系我们~
特别声明
本文仅代表作者观点，不代表本站立场，本站仅提供信息存储服务。