我在超化研究上的日志采集架构设计

软件工程师罗小东，多年平台架构和落地经验，在与社区团队研究超自动化方面的设计和产品方向。

背景

以下是针对超化管理超化的设计，因此会偏向技术方向的阐述。

目前对于超化的关注点似乎更多集中在方法论方面，而较少关注具体实现，目前仍处于探索阶段。我们的编码工作目前在 Github 上进行，以便与对这个领域感兴趣的同学进行更好的交流。

在进行超自动化研究的过程中，我们遇到了数据采集的问题。在上层自动化过程中，需要大量的数据支持，因此需要采集大量内容。由于缺乏业务场景，我们在这方面的研究考虑是先使用超自动化来管理超自动化（即自己管理自己）。这里主要针对日志采集设计。

概述

我们原来的整体设计方向是朝着数据支持方面发展的。根据一定的规则和判断条件，结合 AGI（人工通用智能）的推理判断，形成智能化的操作。在日志的采集和管理方面，我们需要采集完整的数据链，进行判断、管理和预测。在确定采集哪些数据时，我们参考了许多开源项目，但也发现了一些问题。各个开源项目过于分散，无法形成组合，数据分离也比较麻烦。另外，技术迭代速度较快，有些项目没有很好地跟进。综合考虑后，我们需要进行部分重写和整合。这里主要采集的内容包括：

  • 前端日志：包括 UI 事件、访问日志、操作日志、热点日志和 IO 日志等。
  • 自动化日志：镜像日志、构建日志、过程日志和操作日志。
  • 安全日志：代码、质量、版本、漏洞安全、容器漏洞、密钥日志和 Git 提交日志等。
  • 应用日志：运行日志、运行状态、请求日志、运行情况和链路情况等。
  • 系统日志：操作日志、历史日志、IO 日志、网络日志、请求情况和运行情况等。
  • 操作日志：操作记录、SQL 操作和审计操作等。
  • 登录日志：登录的所有信息和请求，例如 IP、地点、位置和账号等。
  • 项目日志：任务操作日志、变更日志、审计日志、人员变动和状态变更等。
  • 链路追踪：请求链路、操作链路、日志链路、SQL 链路和阶段链路等。
  • …

这只是初步设计，后期还会继续添加。目前按照上述设计进行集成，采集回来的数据使用流水线方式进行判断和处理。在这个过程中，我们主要使用了 GPT 的推理结果作为推理能力的基础。当前的原则是尽量使用流水线和自动化，在特定阶段使用 GPT 的能力作为辅助，以提高过程的稳定性。实现的超化能力演化效果类似于以下示例：

  • 在云服务器准备到期时，自动采购或续费。
  • 当功能准备延期时，自动通知并向指定人员提供合理建议的方案。
  • 每月或每周自动生成报告结果，并给出合理的建议。
  • 自动检测和构建验证过程中的漏洞，并生成分支。
  • …

在这些过程中，我们使用规则和推理能力进行简单的判断，协调这些自动化流水线，类似于自动驾驶，但也有辅助驾驶，推理能力就是这个协调的大脑。为了实现更便捷的操作，我们还添加了语音交互，以便更好地进行操作，并将结果通过 SSE 推送到系统界面或进行语音播报。

下面是当前设计的整合思路，这仅涉及日志采集方面的设计，其他自动化内容不包含在其中，我有自己的思路。

过程设计

相对而言，采集的设计是相对简单的。目前有许多开源工具可用，但搭建起来可能需要较长时间。然而，由于 AIGC（人工智能生成代码）的能力，我们可以使用生成式代码和单元测试，效果还是不错的。

采集工具

我们的采集工具主要使用了一些开源工具，并结合了 Maven、Shell 和自研的流水线进行改进。在选择工具时，我们考虑了定制化的需求，并综合考虑后决定自行开发。下面是我们主要使用的采集技术：

  • 前端采集：log.js、filebeat 和 nginx。
  • 自动化采集：Python + shell，并将数据发送到 Webhook。
  • 安全日志采集：Trivy、Checkstyle、Murphysec、SpotBugs、Gitleaks 等工具。
  • 应用日志采集：自定义的 logback、OpenTelemetry、AOP、Nginx 等。
  • 系统日志采集：Ansible、Shell、Python，定时采集结果并结合 node-exporter 返回。
  • 操作日志采集：AOP 和自定义的 logback，自定义的 MDC 参数。
  • 登录日志采集：Nginx、AOP 等。
  • 项目日志采集：通过调用 API 进行定时采集，并有一些会接收推送结果（例如禅道）。
  • 链路追踪采集：OpenTelemetry 和 agent 的方式。

对于数据量较大的情况，我们使用 Kafka 作为数据缓冲。为了方便交互和安全性，我们在 Kafka 前面加了一层控制器层，提供了 HTTP 接口，并使用自定义的令牌进行拦截。目前还在研究过程中，尚未添加 HTTPS。

有些 Webhook 提供的是一个前端系统，例如 Spring Boot 应用或 gRPC 应用，它们接收数据后将其输入到数据仓库中。我们使用 ClickHouse 作为数据仓库，因为它能够保存多种数据结构。一些日志会在实时计算后保存到数据仓库中，另一部分会使用数据进行离线计算。我们对 ds 的 2.0 版本进行了二次开发，以适应当前的工程结构并更好地维护。

维护平台

采集之后，并不仅仅是结束了。我们还设计了几个平台来管理数据，以应对不同的应用场景。这些平台类似于数据的前端和展示，便于管理过程流程跟进，并提供更好的可视化。我们基于 Ruoyi-Plus 进行了改造，主要产出了以下平台，便于维护管理，比如自动操作服务、安全感知服务、持续集成服务、日志审计服务、容器管理服务、监控预警服务、链路追踪服务等。

这些服务功能主要是在数据上展示和管理，便于超自动化的管理。一些数据来源于 ODS 层和 ADS 层，目前的流水线集成还在 GitHub Actions 上，但数据应该已经采集到了。后续需要进行验证，并进行多个自动化流水线的验证处理。这个过程可能需要进行调试，当前的功能点已经规划和编码产出。

总结

以上是我们在研究超自动化过程中关于日志处理的思路和结构。目前还在进行调试和验证。除了日志的自动化处理，还有其他方面需要结合超自动化，例如项目管理、产品市场营销、流水线自动生成等。希望对从事这方面的同学提供一些经验参考。

鸣谢

在处理日志的过程中，我们参考了一些产品，主要包括以下内容：

  • GitHub Security 服务
  • 阿里云分布式链路
  • AnsibleTower 自动化操作
  • ELK 套件
  • PlumeLog 开源日志工具
Post Views: 113