如何建立一个网站放视频,网站注销备案查询,京东网站的建设与发展,wordpress 主题 三栏本文导读#xff1a;
数智时代的到来使网络安全成为了不可忽视的重要领域。奇安信作为一家领先的网络安全解决方案领军者#xff0c;致力于为企业提供先进全面的网络安全保护#xff0c;其日志分析系统在网络安全中发挥着关键作用#xff0c;通过对运行日志数据的深入分析…本文导读
数智时代的到来使网络安全成为了不可忽视的重要领域。奇安信作为一家领先的网络安全解决方案领军者致力于为企业提供先进全面的网络安全保护其日志分析系统在网络安全中发挥着关键作用通过对运行日志数据的深入分析能够对漏洞和异常行为生成关键见解帮助企业建立有效的防御策略。本文将深入探讨奇安信在网络安全与日志分析解决方案的关键优势了解基于 Apache Doris 构建的全新一体化日志存储分析平台如何实时监测和分析日志事件加强对可疑活动的追踪与应对提升系统安全性与快速响应能力。
作者奇安信 服务端技术专家 舒鹏 奇安信是中国企业级网络安全市场的领军者专注于为政府和企业用户提供新一代网络安全产品和服务。目前核心产品天擎终端安全系统在国内已有 4000 万政企用户部署、全国部署服务器超过 100 万台、服务超 40 万大型机构。作为网络安全国家队奇安信立志为国家构建安全的网络空间在终端安全、云安全、威胁情报、态势感知等领域的技术研发持续领先。
随着现代企业数字化转型的不断深化大数据、物联网、5G 等创新技术的广泛应用加速了企业的数字化转型步伐这使得原先的网络边界被打破多源多样的终端设备成为了新的安全边界。
网络安全系统的防御性能与日志分析密不可分当网络设备、操作系统以及应用程序在运行时会产生大量的运行日志其中蕴涵了丰富的数据价值。最大化地利用运行日志数据能够有效检测内部系统的安全风险、还原攻击路径、回溯攻击入口等可以进一步提升系统安全性、保障企业网络安全因此日志分析系统在其中发挥着不可或缺的作用。
本文将介绍奇安信在网络安全场景中基于 Apache Doris 进行架构升级迭代并建设全新一体化日志存储分析平台的实践经验。
早期架构痛点与需求
安全日志平台的架构如下图所示原始的设备、系统日志首先经过业务处理环节包括归一化和扩充维度等操作。这些处理步骤旨在将来自不同设备和系统日志转化为半结构化 JSON 格式的安全日志并将其写入 Kafka 消息队列中。
最新的日志会被写入实时数仓安全分析师可以通过分析平台对实时数仓中的最新数据进行交互式查询从而进行攻击研判和追踪溯源等安全分析工作。另外离线数仓用于保存历史数据以支持长周期数据挖掘的离线分析。 在以上日志数据平台中日志数据的写入速度与查询分析效率对上层业务人员进行实时安全事件监控和分析至关重要这也是当前我们所面对的最主要痛点。
一方面每天所生产的安全日志数据达到千亿级写入压力很大。最初我们选择使用某 Apache Doris 的 Fork 版本来存储日志数据但在实际应用中随着每天新增日志量的不断增长入库速度逐渐降低、集群写入压力过大、高峰期数据积压严重对集群稳定性造成很大影响并且数据压力较高时、查询效率也达不到有效果的保证。随后我们对集群进行多次扩容从 3 节点逐步扩容到 13 节点尽管机器成本已经大幅超过预期、但写入效率并没有发生本质的改善。
另一方面业务人员在进行安全日志分析时经常需要对文本字段如 URLpayload 等进行关键字匹配。在原系统中只能通过 SQL LIKE 进行全量扫描和暴力匹配整体查询性能不佳千亿级数量的数据表查询耗时接近分钟级甚至达到数百秒即便按照时间区间过滤大量数据后、查询耗时仍在数秒到数十秒。一旦遇到并发查询性能还会进一步恶化很难满足日常安全分析的需求。
除写入和查询效率以外运维监控也是我们的痛点之一该厂商提供的可视化运维系统需要商业 License 授权对于开源社区用户不友好集群维护处于原始手动状态。
架构选型与升级的思考
为了解决过去版本的痛点、满足更高效实时的日志分析诉求我们亟需对早期系统升级改造。同时面向安全日志分析场景我们也对新日志分析平台的架构提出了更高的要求 写入性能系统一方面需要支持海量病毒查杀事件等数据实时写入与存储以满足分析时效性的要求另一方面需要基于日志数据 Schema Free 特点支持丰富数据类型的写入与变更。 查询性能由于日志查询分析会涉及对文本类型、JSON 数据进行全文检索、日期或普通数值的范围查询系统需要对字符串提供模糊查询的能力还需要支持能够灵活创建且类型丰富的索引以加速筛选过滤海量数据提升查询效率。 存储成本设备每天产生大量的日志数据为了挖掘这些有价值的日志信息业务人员还需要从数据中进行筛选和分析并对异常日志回溯追踪这使得日志存储的规模很大、存储周期相对较长因此高性价比的存储成本也是系统构建的目标之一。 运维成本系统自身的运维简易程度以及是否具备合适的管控工具都能帮助我们进一步提效。
在持续关注业界 OLAP 数据库的过程中我们发现 Apache Doris 最近一年的发展非常迅猛最新的 2.0 版本也把日志存储和检索分析作为新的发力点推出了倒排索引、NGram BloomFilter 索引等特性对关键词检索、LIKE 文本匹配的性能有大幅提升与我们文本检索慢的痛点需求非常契合因此开启了新架构的升级之旅。
架构升级之旅
上文中提到在整体架构选型过程中我们主要关注的地方包括写入性能、查询性能、数据存储成本以及运维成本等方面。在架构升级过程中我们选择了 Apache Doris 当时最新发布的 2.0 版本具体升级收益如下。
01 写入性能提升超 200%
为了评估 Apache Doris 写入的极限性能我们初期使用与线上系统相同配置的 3 台服务器从 Kafka 接入线上真实写入流量测试期间当 CPU 写入效率跑满至 100% 时写入吞吐达到了 108 万条/s、1.15 GB/s写入数据的可见性延迟保持在秒级。
而线上运行的原系统集群规模达 13 台在同样的数据写入情况下CPU 利用率 30% 左右、写入吞吐仅 30 万条/s并且存在高峰期 CPU Load 高、系统响应慢的问题。
根据测试结果我们预估架构替换为 Apache Doris 后保持同样 30% 的 CPU 占用只需要 3 台服务器即可满足写入需求机器资源成本至少节约 70%。值得注意的是在测试中对 Apache Doris 表中一半字段开启了倒排索引如果不开启倒排索引的话写入性能在之前基础上还能够再提升 50% 左右。
02 存储成本降低近 40%
在看到写入性能的大幅提升后Apache Doris 存储空间占用也给我们带来了惊喜。在开启倒排索引的前提下存储空间比原系统不具备倒排索引还要略低压缩比从 1 : 4.3 提高至 1 : 5.7。
通过对比 Apache Doris 在磁盘上存储的文件大小同一份数据的索引文件(.idx)与数据文件(.dat) 大小相差无几。换言而之增加索引后 Doris 数据膨胀率大约在 1 倍左右与许多数据库和检索引擎 3-5 倍的膨胀率相比Doris 的数据存储空间占用相对较低。经过研究发现Apache Doris 采用了列式存储和 ZSTD 压缩算法来优化存储空间占用。Doris 将原始数据和倒排索引都以列的形式存储使同一列的数据被存储在相邻位置从而实现了更高的压缩率。
ZSTD 是一个优秀的新型压缩算法使用了智能优化算法相较于常见的 GZIP 算法 ZSTD 具有更高的压缩率和更快的解压速度尤其在处理日志场景时表现非常出色。
03 查询性能平均提升 690%
对于业务最关注的查询性能我们从线上查询日志进行去重后分析出 79 条 SQL在同一天总数据1000 亿条、同样规模的集群10 BE 节点上对比测试 Apache Doris 与原系统的查询耗时。
我们发现与原系统相比所有的查询语句均有明显提升整体查询性能提升近 7 倍有 26 条 SQL 查询语句性能提升 10 倍以上其中 8 条 SQL 查询提升 10-20 倍、14 条 SQL 查询提升 20-50 倍、还有 4 条 SQL 查询提升 50 倍以上。最大差异的一条 SQL 查询语句为 Q43在原系统中执行时间接近一分钟在 Apache Doris 中仅需不到 1 秒其性能差异高达到 88 倍。 针对性能提升幅度高的查询我们进行了对比分析并发现了其中几个共同点
倒排索引对关键词查找的加速Q23、Q24、Q30、Q31、Q42、Q43、Q50 等
1 -- 例如q43 提升88.2倍
2
3 SELECT count() from table2
4 WHERE ( event_time 1693065600000 and event_time 1693152000000)
5 AND (rule_hit_big MATCH xxxx);
这种基于倒排索引进行关键词检索的技术相较于基本的暴力扫描后进行文本匹配具有显著的优势一方面极大地减少了需要读取的数据量另一方面在查询过程中无需进行文本匹配操作因此查询效率往往提升一个数量级甚至更高。 NGram BloomFilter索引对 LIKE 的加速Q75、Q76、Q77、Q78 等
1 -- 例如q75 提升44.4倍
2
3 SELECT * FROM table1
4 WHERE ent_id xxxxx
5 AND event_date 2023-08-27
6 AND file_level 70
7 AND rule_group_id LIKE adid:%
8 ORDER BY event_time LIMIT 100
对于要查找的非一个完整关键词的场景LIKE 仍然是有用的查询方式Apache Doris 的 NGram BloomFilter 索引能对常规的 LIKE 进行加速。
NGram BloomFilter 索引与普通 BloomFilter 索引不同它不是将整个文本放入 BloomFilter 而是将文本分成连续的子串每个子串长度为 n 并将他们放入 NGram BloomFilter 中。对于 cola LIKE %pattern% 的查询将pattern按照同样的方式分成长度为 n 的子串判断每个子串在 BloomFilter 中是否存在如果有一个子串不存在则说明 BloomFilter 对应的数据块中没有跟pattern匹配的数据块因此通过跳过数据块扫描的步骤达到加速查询的效果。
满足条件的最新 TopN 条日志明细查询优化Q19-Q29 等
1 -- 例如q22提升50.3倍
2
3 SELECT * FROM table1
4 where event_date 2023-08-27 and file_level 70
5 and ent_id nnnnnnn and file_name xxx.exe
6 order by event_time limit 100;
这种SELECT * FROM t WHERE xxx ORDER BY xx LIMIT n 的查询在查找满足某种条件的最新 n 条日志时使用频率非常高Apache Doris 针对这种 SQL 查询模式进行了专门的优化根据查询的中间状态确定排序字段的动态范围并利用自动动态谓词下推的方式避免读全部数据进行排序取 TopN从而减少需要读取的数据量有时甚至可以减少一个数量级进而提升了查询效率。
04 可视化运维管控和可视化查询 WebUI最大化减少运维和探索分析成本
为了提高日常集群维护的效率我们使用了飞轮科技免费开放的可视化集群管理工具 Cluster Manager for Apache Doris 以下简称 Doris Manager 。Doris Manager 提供的功能可以满足日常运维中集群监控、巡检、修改配置、扩缩容、升级等操作降低登陆机器手动操作的麻烦和误操作风险。 除了管控 Apache Doris 集群之后Doris Manager 还集成了类似 Kibana 的可视化日志探索分析 WebUI对于习惯 ELK 日志分析的用户非常友好支持关键词检索、趋势图展示、趋势图拖拽日期范围、明细日志平铺和折叠展示、字段值过滤等交互方便的探索式分析跟日志场景探索下钻的分析需求很契合。 总结与规划
在跟随 Apache Doris 2.0-alpha2.0-beta2.0 正式版本发布的节奏我们根据业务场景进行了详细的评测也为社区反馈了不少优化建议得到社区的积极响应和解决。系统经历试运行一个月之后我们将 2.0.1 版本正式用于生产环境替换了原系统集群完成架构升级改造实现了写入性能、查询性能、存储成本、运维成本等多方面收益 写入性能提升 3 倍以上目前奇安信的日志分析平台每日平均有数千亿的新增安全日志数据通过 Doris 的 Routine Load 能够将数据实时稳定写入库保障数据低延迟高吞吐写入。 查询性能平均提升 7 倍查询响应时间大幅减少与之前的查询效率相比达到平均 7 倍提升其中业务特别关注的全文检索速度达到 20 倍以上的提升助力日志分析与网络安全运营效率。 高效便捷的可视化管理Cluster Manager for Apache Doris 工具提供了可视化集群监控告警平台满足日常集群监控等一系列操作同时 WebUI 多种功能为分析人员提供了操作简单、使用便捷的交互式分析。总而言之Doris 的易用性、灵活性大幅降低了开发、运维、分析人员的学习与使用成本。
后续我们还将在日志分析场景下探索更多 Apache Doris 的能力。我们将扩大 JSON 数据类型的相关应用加强系统对于半结构化数据深度分析的能力。同时我们也非常期待 Apache Doris 2.1 版本中新增的 Variant 可变数据类型支持存储任意结构的 JSON 数据支持字段个数与类型的变化让业务人员灵活定义特殊字符以更好地实现半结构数据 Schema Free 的分析需求。
非常感谢 SelectDB 团队一直以来对我们的技术支持助力奇安信走向“体系化防御、数字化运营”的网络日志安全管理帮助客户准确识别、保护和监管网络设备与各类系统确保业务人员在任何时候都能够安全、可信、稳定地访问数据与业务。
最后我们也将持续参与到 Apache Doris 社区建设中将相关成果贡献回馈社区希望 Apache Doris 飞速发展越来越好
