[改进后的中文总结内容]

在2025年6月4日的Ceph开发者月度会议上，与会者讨论了Ceph审计日志（Audit Logs）的设计与实现。以下是对会议内容的总结：

会议背景与目标

  • 提案人：来自CFS团队的Daria
  • 核心需求：当前Ceph集群中，用户执行某些命令可能导致集群状态异常，缺乏审计机制，难以定位问题根源。
  • 目标：实现一个集中化的审计日志系统，记录所有Ceph命令。

主要讨论议题

  • 设计方案：
    • 数据来源：Monitor、Manager、独立工具。
    • 存储后端：首选libsqlite（基于SQLite 3），通过RADOS交互。挑战包括Monitor日志通过MGR路由，但MGR可能不可用。
  • 替代方案讨论：
    • 现有技术：OpenTelemetry，已在RGW和OSD中用于端到端追踪。
    • 性能与可靠性：未启用时零开销；启用后性能影响取决于日志量，数据可能因缓冲或网络问题丢失。
  • 功能扩展与配置：
    • 日志保留策略：默认按时间或大小修剪，支持用户自定义配置，关键操作永久保留。
    • 多组件需求：RGW团队希望记录radosgw-admin命令，Core团队关注时间戳和延迟数据。

关键决策与行动计划

  • 技术选型：优先评估OpenTelemetry的适用性，若不满足需求，推进原生libsqlite方案。
  • 日志范围：覆盖所有Ceph子系统的关键命令，支持按组件和用户角色过滤日志。
  • 后续行动：
    • 短期：Daria团队研究OpenTelemetry的Monitor集成可能性，与RGW团队协作。
    • 长期：设计统一的审计日志API，支持动态配置，集成到cephadm部署流程。

其他要点

  • 性能与可靠性权衡：OpenTelemetry的UDP传输可能丢包，需评估是否可接受；原生方案需解决MGR单点故障问题。
  • 社区协作：欢迎其他组件提出审计需求，确保设计通用性。

下次会议

待定（根据需要进一步讨论设计进展）。 ### 参会人员 Daria、Patrick、Weni、Mahesh、John、Casey等。

本次会议重点讨论了Ceph审计日志的设计与实现，包括数据来源、存储后端、替代方案、功能扩展与配置、决策与行动计划等。会议还探讨了性能与可靠性权衡以及社区协作的重要性。