日志系统的尽头是OLAP引擎？

降本增效主旋律下的生存之道

最近几年，互联网产业在政策抑制和市场容量接近饱和的情况下，慢慢地由野蛮生长、争抢客户的增量市场发展模式，进入了一个需要精细化运营，通过优质服务来留住客户的存量市场发展模式。能够通过创新来开辟的业务新赛道的机会和案例已经越来越稀缺。各大厂商纷纷开始高举“降本增效”的大旗，以期能够度过寒冬。

在降本增效紧箍咒的高压下，不少企业纷纷祭出“自研”这一法宝，期望减少在软硬件基础设施上的支出，或者在支出不变的情况下，能够“优化”出更有效率的系统。

层出不穷的自研日志系统2.0

而在选择哪些系统可以自研的时候，日志系统以其影响范围广、资源投入多、使用时间少（主要集中在故障排查）等特点，成了各互联网大厂自研目标的集火对象。同时，集齐天时地利人和的是，在日志系统这个领域，有一个大家都公认的标准（ELK）可以作为比较对象，只要做得比开源自建的ELK好，就能证明基线之上创造的价值；同时，在采集端和数据规范上，有正在毕业的Opentelemetry, 在存储和分析；有众多高效的开源OLAP引擎能够提供核心组件的替换；在可视化和交互层面，可以用Grafana；而且这件事情已经被证明过可行性，有现成的案例。从构建思路到解决具体问题上，也能够找到参考和帮助。这些，似乎都使得这件事情的难度大大降低，可以放心大胆的撸起袖子快上大干。

自然，也就促成了层出不穷的基于OLAP引擎的自研日志系统的案例，甚至有不少人把这种变种称为日志系统2.0。

那我们如何理解在日志分析领域出现的这种变化呢？

互联网特有的日志OLAP分析场景

上面，我们提到了在线分析处理引擎（OLAP），这是一种用于组织大型商业数据库和支持商业智能的技术。其本身主要是面对结构化数据的在线分析场景。而现今，在日志系统中采用OLAP引擎的主要原因来自于结构化的，固定格式的日志分析需求。这类日志以API的调用日志，web服务器、负载均衡、网关的access日志为主，其特点是数据的格式、字段、值相对有限而固定，对数据的使用以有限值的字段过滤与数据聚合运算为主，通过聚合统计来了解服务的运行情况，错误率，延迟率；或者是在圈选客户后，在不同维度做分类统计等，属于较为典型的OLAP分析场景。在分析过程中，并不需要对日志数据的进行复杂的全文检索。同时，因为字段固定且有限，也不会需要对大量的动态字段的支持需求。

而在业务属性上，这类日志的分析，不仅能够用于检查服务运行状态，而且还能在一定程度上支持运营决策， 比较适合用来做各种仪表板和大屏，相对于其他那些出错时才会去看的日志，其表现力更强，更容易被重视。因此，如果要自研，团队会更愿意选择适合这类场景的大数据引擎去作为日志系统的底座。而OLAP引擎因为其几乎是原生的支持各种SQL特性，使得其更适合这类日志数据的分析报表生成，并且对业务分析人员更为友好，学习成本更低。

并且，这类数据的数据量很大，且与平时的业务流量呈现非常一致的相关性，数据的时间属性具有明显的潮汐特点。当业务洪峰来临，日志量急剧上升。要支撑这种类型的日志数据，就需要系统有高吞吐的写入能力。相对于以搜索引擎为主的ELK，OLAP引擎因为不需要构建倒排索引，使用强类型表达等原因，其写入速度要更为出色。

因此，结合以上原因，不难理解为什么互联网企业会选择以自研的方式，开发一套基于OLAP的日志分析系统。

如何理解基于OLAP的自研日志系统

这种类型的日志系统，是有其合理性，并且也能解决特定场景问题的，因此，我们是可以把日志场景进行细分的，将其归类为一种以分析为主，辅以简单的过滤检索的分析型日志场景。

但如果我们把其称为日志系统2.0，那不免有点言过其实。因为其本质只是在特定场景下，在不同的功能和性能指标之间进行的取舍，并非是日志系统的进步。它不仅具有很大的局限性，也并不与下一代的日志系统发展方向同步（全观测性与AIOps）。而且在无法商用的前提下，对一个庞大的系统做自研，这种行为需要非常谨慎，因为稍不小心就会掉入陷阱。接下来，我们针对这几点分别阐述。

从传统行业看基于OLAP引擎的日志系统的局限性

正如我们上面描述的，以OLAP引擎来架构日志系统的前提是相对固定数据的格式和字段。类似Aphache的HTTP日志，网关的API日志等，本身就是非常固定的格式，天然适合。而对于业务日志，也可以通过强制且统一的日志规范，巧妙的设计，让其最大限度的具备“结构化”，让排错也能够通过字段过滤的方式尽可能将需要进行全文检索的范围缩小。因此，以OLAP引擎来架构日志系统对于业务日志也是OK的。

但这里要强调的是，这个前提主要对互联网企业有效。总体看，互联网企业的其技术特点包括：

• 大量的使用开源软件
• 业务模式和流程相对简单，以用户对内容的交互式操作为主（Web 2.0）。架构复杂性和难点在于支持高并发，而非支持复杂流程

互联网企业普遍采用开源技术

因此，在日常的运维工作中，互联网企业对所有使用到的软件模块几乎都是有代码权限的。在企业内部，可以比较容易的制定统一的日志规范，在内容输出方式、格式、名称、分类等方面做到一致。这样，也就方便了OLAP引擎来处理几乎是一致的、结构化的日志。如果仔细看各种基于OLAP引擎构建日志系统的分享，这一步几乎是必须要做的工作。

同时，因为倡导解耦和微服务化，使得每个服务所需要完成的事情比较单一和简单，流程复杂度大大降低。这使得日常在做日志分析的时候，往往只需要做简单的关键字过滤（甚至都不需要用到检索），就完成了日志工具的使命。（因为复杂的调用关系和上限文理解，已经交给了APM的分布式链路追踪功能）。

但是，这种模式只能在互联网企业中生效。对于大量的传统行业，比如金融，医疗，通信，制造等，其日志数据则完全是另外一个场景。在这些行业中，大量用到了第三方供应商的专业软件或者是历史遗留软件，甚至还有一些是专有设备产生的日志。通常，这些软件对我们来说是完全不可控的，并且需要专业人员才能对其日志进行解读。

传统行业广泛使用商用软件

当我们需要将这些数据进行集中处理和统一分析的时候，会遇到大量不一致的日志输出格式与表达方式。从客观上，就不可能有一个统一的规范，甚至是不可能有人能够了解所有这些应用的日志并为他们制定合适的字段schema。因此，就会要求日志系统在这方面有很强的兼容性，能够：

• 支持不确定的动态字段，并在单一表中支持足够多的字段
• 所有的字段都默认生成索引，能够在需要时进行快速的字段检索和过滤
• 支持全文检索和模糊查询

另一方面，在传统行业中，不少业务并非像互联网企业那样能够充分的解耦和微服务化。对于重流程，强耦合，上下调用关系之间有多重逻辑表达的业务，当出现问题时，往往需要我们跨业务，通过比较复杂的查询语句才能去跟踪和分析。

而且，传统行业每天产生的数据量会相对稳定，容易预估。不需要系统对瞬时流量有非常大的包容性。

因此，对于大量的传统行业来说，其对日志分析的核心诉求不是高吞吐、低延迟和支持SQL。而是对大量不同格式数据的广泛支持，有效查询，能够帮他们真正的定位故障，找到问题，并且这套技术应该是被广泛使用的，能够以很低的代价被沿用、升级和人员可替换的。

而显然，一个自研的，基于OLAP的日志分析系统是不具备这样的特性的。

从日志系统的历史看基于OLAP引擎的日志系统的局限性

如果回顾日志系统的历史，你会发现，在互联网还未诞生的30多年前，我们就已经有了日志分析的需求，并从那时候开始着手于日系统的研究与构建。从我们有操作系统、有syslog开始，日志就成了非常重要的一项数据资产，用于保证IT资产的正常运行、事故溯源分析、取证、响应、合规和审计等需求。可以说，日志系统几乎是伴随着安全日志分析一步步成长起来的，在特定的时期，甚至可以说一个日志分析软件就是一个SIEM软件。

在安全领域，日志来自于不同领域、不同厂家的设备：IDS/IPS，防火墙，路由器，方便度软件，WAF等，以及主机和软件产生的各种syslog和应用日志。日志系统的主要使命包括跨源分析来自不同数据源的数据，并且能够进行有效的关联分析，以支持规则引擎能够定制各种类型的扫描规则，并方便安全分析师进行有效的威胁捕获，同时，长期存储，以满足溯源、取证和监管、审计的需求。

特别是在攻击方的攻击更加复杂化，攻击点更多、攻击链条更长、潜伏时间更久的今天，对于安全日志分析系统来说，能够接入尽量多的数据源，获得全面的可见性；能够存储足够多的，足够久的数据进行有效的追溯和取证；能够进行足够复杂的分析，揭示可疑操作之间的关系和逻辑。都需要更加复杂的，在解决方案层面提供的诸多手段和工具才能完成。

在这个层面上来说，基于OLAP引擎的日志系统就不可能，也不应该被描述为日志系统2.0。只有简单的SQL聚合功能，在安全领域完全就是寸步难行。

而在我们持续倡导DevOps, DevSecOps，可观测性左移，安全左移的今天。我们需要重复建设，为IT运维人员负责的业务系统构建一个简单的日志系统，而为负责安全运维的同学构建另外一套日志系统吗？

要知道，IT运维的日志数据只是安全运维数据的一个子集，IT运维采集的链路数据，对于安全运维也是需要的。在你将IT运维日志的集群通过OLAP引擎改造，将集群规模由100个节点降为50个节点的同时，你可能会发现另一个安全运维集群存储了相同的数据，同时还用了300多个节点。

这样看来，或许自研一套针对特殊场景的日志系统而获得的成本收益，还不如考虑将对日志的分析的不同需求进行整合来得高

自研的局限性

第三个不得不提的是自研这个事情，看似是降本增效的利器，实则暗藏陷阱和杀机。

首先，软件研发这个事情，如果不是奔着商业化，不是奔着追求利润去的，而只是用于企业内部，目标是降低成本，那么这个项目显然就不太可能取得长期的成功。毕竟所谓的“技术影响力”对品牌的作用，大抵只能对以云计算的方式提供服务和商品的厂商产生正向收益，而其他的企业若是奔着这目的去，是有点水中望月的。道理非常简单：非商业化、市场化的企业内部应用，很难有一个长期的、能够持续迭代Product backlog；因为无法从市场获得反馈，靠内部使用来推动的进化，最终的结果往往就是慢慢的落后于时代，最终由新来的领导为这个项目画上终止符。

其次，如果宣传自研的好处是降低了成本，那么要小心是否真正考虑了总体拥有成本。当你自研的产品不能通过销售而产生正向的盈利，但又需要持续保持一个庞大的团队对其进行持续的开发、迭代和维护的时候，人力成本，维护成本，适应未来需求的升级成本、以及核心人员流失后带来的风险都需要进行仔细的评估。

再者，每一次投资都应该评估当下和未来的收益，自研系统是否真正满足了当前和未来的需求，还是捡了芝麻丢了西瓜，这也是需要评估的。以我们这里的日志分析系统为例，一套这样的系统涉及到数据采集、处理、统一规范化、存储、分析、可视化展示、告警、报告、与下游系统对接、自动化、自助化甚至是机器学习等等很多功能，在应用层面上还有非常多的面向使用不同使用场景的特殊功能。一个小规模的自研团队是否对这个产品有充分的了解，还是只是了解了两个不同的数据引擎就开始重建？如果一个有100个功能的商用软件，企业平时主要用到其中的10个，现在自研软件对这10个功能进行了优化，但放弃了其余90个功能。企业是否能够准确的评估这种行为在当下和未来都是值得的？

没有产品经理，没有对产品深入细致的研究和长期的规划，没有市场反馈，没有成本的精算，不是奔着商业化而去的自研产品行为，不建议大多数企业这样去执行。

除非，这是一个非常静态的，不再有什么创新的历史遗留系统，而且投入又是一次性，我们才值得去做这样的自研。但我们的日志系统是这样吗？

日志系统发展的方向

上面，我们我们在日志系统的层面简单分析了基于OLAP引擎自研日志系统的局限性，但这个是基于对自己企业情况进行评估后，可以自由选择的、可能对自己可能最有益的选项之一。我们擅长在不同的场景下找局部最优解来解决问题。

但如果这个系统是另一个更复杂，更动态的系统的一部分呢？ 这时，我们还应该把本该属于专业人员该干的事揽到自己身上吗？

很不幸，日志系统并不是一个独立的静态系统。为了应对更复杂的现代IT环境，我们需要可观测系统，需要智能运维系统，而日志系统，是其中非常有机的一环。

成为有效的可观测性系统一部分

对于所有的运维和基架同学来说，可观测性（Observability）一定不是一个陌生的词汇。不少人应该能够说出其含义：

What is Observability?Observability lets us understand a system from the outside, by letting us ask questions about that system without knowing its inner workings. Furthermore, allows us to easily troubleshoot and handle novel problems (i.e. “unknown unknowns”), and helps us answer the question, “Why is this happening?”

但如何获得可观测性呢？是不是只要有日志、指标、追踪这三种数据就够了？答案显然不是那么简单的。可观测性的核心是让我们通过可观测性获得向系统提问并获得答案的能力。这是一个解决方案，而不是一个简单的俯卧撑动作。

在Gartner 2022的咨询报告中，已经将可观测性与APM进行了合并。

Gartner的APM与可观测魔力象限

这两个词所代表的含义因为大量的需求重叠，已经可以归纳到一起。

APM和可观测应用的关键能力

这里就不一一赘述上面每个功能的具体特点和需求了，只是强调一点：越是复杂的系统，对可观测性系统提出的要求就越高。

因为高度的分布式架构，多云环境和云原生的广泛采用，我们的业务系统和服务变得非常的离散，动态和弹性，而且非常强调自动化和快速变化。要获得这种系统的可观测性，要求可观测性工具本身也是非常自动化，动态和快速迭代的。

显然，在构建一个可观测性解决方案的时候，更多孤立的工具并不是答案。

一些团队错误地试图通过采用更多孤立的监控工具来解决 "大规模可观观测性 "的问题，但这样，反而让团队不断陷入人工密集型任务，产生更多的技术债务，并在识别问题和优先定位具有最大影响的问题上表现挣扎。

在可观测性解决方案中，日志只是其中一环，它的核心作用是帮助我们理解问题，而非发现问题。为了保证日志能够在指标指示出异常，分布式追踪定位到具体模块的情况下，能够快速的为我们解释问题，日志数据在整体上须要和其他数据有统一联动和锚定上下文的关联分析能力。这些所谓的其他数据，甚至可以是我们的拨测数据、用户真实数据的遥测数据。

而如果我们把可观测解决方案的构建简单理解为只要有日志，指标，分布式追踪数据就够了，然后分别独立构建日志系统，指标监控系统和APM系统，却没有提前设计好这些系统在元数据，交互，跳转之间的关系并进行有机的整合，那么，日志系统就会很快变成一个技术债，又会面临重新架构和设计。

而在另一方面，无论是从遥测数据（日志，指标，trace）的采集的集中管理，还是后期的数据的统一生命周期管理，上卷聚合，历史数据的趋势发现，与机器学习的有机整合，实现故障主动发现与自动修复，这些也都要求全观测系统是一个有机的整体。独立的工具，与这个目标也是相悖的。

自助化 —— 更高的使用效率和频率

这个系统最终是要拿来给人用的。从使用者的角度，最关心的是用户体验：易用、好用，真正的解决问题，它应该像一个基础的SaaS服务，拿来即用。因此，进化的方向会包含更多运营和使用方面的功能。这些都跟底层的引擎没有关系，而是到底投入了多少资源进行了开发。

不同数据的自动泊入

对于现在普遍采用的云计算和云原生计算，对于不断涌现的新技术和新工具，能够多快程度的进行适配，并且提供开箱即用的对接，而不需要开发人员自己进行手动的配置和开发，会是这个系统非常重要的一项体验指标。

统一的数据schema

采集的异构数据，应该在进入系统之前，有统一的清洗、整理和规范的过程。这个东西应该是自动实现的，而不是扔出一个文档，让系统的使用人员自己的去follow。自动化的数据整理，不需要使用人员手动去调整、规范和整理数据，也是这个系统非常重要的一项体验指标。

主动的异常检测、降低告警疲劳

如果团队只是对已发生的问题进行观察、应对，那么并不能减低风险。而在繁多的种类、海量的数据面前，期望人工能够转变为事先进行了解、优化的文化是不现实的。做到预判，预测需要机器学习的参与，而根据动态的信息进行调整，过滤含混不清的告警信号风暴，也需要机器学习。不需要使用人员时刻盯着仪表板，能主动的、智能的预警，降低告警疲劳，也是这个系统非常重要的一项体验指标。

自动化

日常运维工作中必定存在大量重复性的工作。当全观测系统检测到异常时，它应该能够与上下游系统进行联动，执行一些自动化的剧本，帮助缓解和承担人工操作的负担，也是这个系统非常重要的一项体验指标。

自助化

这个是常被忽视的一个功能。所有的团队都需要可观测性工具并可能频繁的使用。这个工具不应该是一个需要培训，需要申请，需要调配才能入手的工具。因此，丰富、详细、随时更新的文档和使用手册和SaaS化，也是这个系统非常重要的一项体验指标。

紧随发展方向

随着我们的IT系统越来越复杂，可观测性系统也必然越来越复杂。可观测性系统的化繁为简变得非常重要，而不是交给用户一个优化的引擎和大量的手工工作。而在这里，最优的途径，肯定还是跟着主流的几个厂商的技术路线发展，因为它们对此进行了大量的投资，产品经过大量的迭代，积累了非常多有效的用户反馈。而对于喜欢用开源的企业来说，Elastic会是一个最好的选择。因为在Elastic的解决方案中，已经包含了从全面的可观测性功能套件，到对几乎所有常见数据源的集成，再到机器学习、安全防护和运维等下一步的领域整合的所有内容。在此基础上，企业唯一需要做的就是保持迭代更新的频率和小部分的自定义开发，以及与企业内部环境的整合。

而选择自己开辟一条路径，从多个开源软件中尝试整合出一个全观测性解决方案，这个方案能否成功，能否有效还需要打一个非常大的问号。但人力投入，多系统建设，数据无法复用这些成本问题就已经是板上钉钉的一件事情。更不用说，后期如果要升级到AIOps，DevSecOps，ResponseOps，还需构建机器学习平台，并与安全运维的系统进行整合等，这些让架构进一步复杂化，数据迁移成本更高的事情。

因此，在考虑构建一个日志分析系统时，我们就要想到下一步如何去做全观测，甚至是如何做AIOps。而让数据尽量待在一个平台，减少重复建设成本、数据迁移成本、多平台维护和升级成本、人力学习成本是比简单降低数据存储成本更为重要的事情。

总结

因此，日志系统的尽头绝对不是OLAP引擎。甚至在未来，日志系统该不该独立存在，都是值得思考的。日志的未来只会是可观测性中的一极，日志系统最终会成本为完整可观测性系统的一部分，如果你想要的是一个有机的整合，而不是一个拼凑的缝合怪，那么从整体和长远上进行规划是必要的。

系统应该专注于从可观测性这个理念上去设计，而不是从成本，吞吐，硬件利用性能上去考虑，因此，日志系统的2.0，强调的应该是在可观测性这个领域中与其他不同数据的融合，让操作人员能够无缝的在各种数据和上下文下切换，日志只是完整数据和总体流程中非常有机的一部分，不是应该是独立的个体。对于可观测性系统来说，MTTD，MTTR才是核心的KPI。可观测性项目的成功的逻辑在于能够在持续变化的复杂环境中解决我们的问题，而非需要大力出奇迹。这是一个需要持续发展的解决方案，而不是一次性的拼装项目。你自己魔改五菱神车，装上v12发动机，看起来很美。但真上了赛道，发现依然跑不过只有V6引擎的GTR，因为专业的赛车并非只有引擎，传动，底盘，刹车，转向助力，空气动力都是不可忽视的组件，而且需要专业调教与模块化。

基于OLAP引擎的自研日志系统，在某些方面看起来很美，你可以在某些场景使用它。但不要太冲动，目前，它只是专注于某些场景。这是一个额外的东西，它让你在做特定日志数据的OLAP分析的时候更得心应手。但它并不是为可观测性而生的。

另外，自研很棒，但如果不是以商业化为目的，只是一时心血来潮，那么，请三思而后行。