一、审计日志的爆炸式增长

在 MCP 体系中，每一次 Skill 调用都会产生一条审计日志。对于一个小型部署，每天可能只有几千条日志。但随着系统规模扩大，日志量会呈爆炸式增长。一个中型企业每天可能产生数百万条日志，大型平台则可能达到数十亿条。

这些日志包含关键信息：谁调用了哪个 Skill、传入了什么参数、结果是什么、耗时多久、策略决策是什么。审计日志不仅是合规审计的依据，也是安全追溯、性能分析、成本优化、异常检测的数据基础。丢失或无法查询审计日志，意味着整个治理体系失去根基。

然而，规模化存储和高效查询审计日志面临严峻挑战。写入吞吐量方面，峰值每秒数万条日志写入，需要高吞吐的存储系统。存储成本方面，长期保存（如金融行业要求七年）的数据量极大，存储成本高昂。查询性能方面，在海量日志中快速搜索特定条件的记录，对查询引擎要求极高。合规要求方面，审计日志不能丢失、不能篡改，需要特殊的保护措施。

本章将探讨 MCP 审计日志的规模化存储与查询优化策略，包括数据模型设计、分区策略、冷热分离存储、压缩与生命周期管理，以及 Peta 的实践经验和优化技巧。

二、审计日志的数据模型

一个设计良好的数据模型是存储和查询优化的基础。

核心字段

审计日志的核心字段应该包括以下内容。caller_id，调用方标识，可以是 Agent ID 或用户 ID。caller_type，调用方类型，如 agent 或 user。target，被调用的 Skill 名称。action_type，操作类型，如 call、query、subscribe。parameters，调用参数，JSON 格式，存储传入的参数值。result，调用结果，JSON 格式，存储返回的结果或错误信息。duration_ms，调用耗时，单位为毫秒。status，调用状态，如 success、failure、denied。policy_decision，策略决策结果，如 allow、deny、require_approval。policy_rules，命中的策略规则列表。timestamp，调用发生时间，精确到毫秒或微秒。trace_id，分布式追踪标识，用于关联调用链。span_id，当前调用的标识。parent_span_id，父调用的标识。tenant_id，租户标识，用于多租户隔离。environment，环境标识，如 prod、staging、dev。cost_estimate，预估成本，用于成本分析。

扩展字段

除了核心字段，审计日志还可以包含扩展字段。context，从 MCP Context 中提取的关键信息，如 user_id、session_id。request_size，请求体大小。response_size，响应体大小。retry_count，重试次数。region，处理请求的区域。gateway_id，处理请求的网关实例标识。skill_version，被调用的 Skill 版本号。

数据模型设计原则

设计审计日志数据模型时应遵循以下原则。字段类型明确，避免使用过于灵活的类型，以提升查询性能。避免过深的嵌套，嵌套层级过深会显著增加存储和查询开销。预定义常用字段，将高频查询的字段提取为顶级字段，而不是嵌套在 JSON 中。预留扩展空间，但不过度，为未来需要增加的字段预留位置，但不要添加永远不会使用的字段。

三、分区策略

当单表数据量过大时，分区是提升查询性能的关键手段。

时间分区

按时间分区是最常见的策略。可以按小时、按天、按月进行分区。分区粒度的选择取决于查询模式和数据量。按天分区适合大多数场景，查询时通常指定日期范围。按小时分区适合数据量极大、需要精确到小时查询的场景。按月份分区适合数据量较小或主要进行月度汇总查询的场景。

Peta 默认采用按天分区。每天的数据写入对应的分区，查询时只扫描相关分区，大幅减少 I/O。

按租户分区

在多租户场景下，可以按租户进行分区。每个租户的数据存储在独立的分区或表中。这实现了租户间的物理隔离，也方便按租户进行成本核算。Peta 支持按租户分库分表，租户数量多时可以进一步分片。

按 Skill 分区

对于 Skill 数量少但调用量大的场景，可以按 Skill 进行分区。热门 Skill 的数据可以单独存储，冷门 Skill 的数据可以合并存储。这种方式可以防止热点 Skill 的查询影响到其他 Skill。

复合分区

复杂场景可以使用复合分区。例如，先按租户分区，再按时间分区。或者先按 Skill 类型分区，再按时间分区。复合分区可以更精细地控制数据分布。Peta 支持多级分区策略。

四、冷热分离存储

审计日志的数据价值随时间的推移而快速衰减。近期的日志需要频繁查询，应存储在高性能存储上。历史日志很少查询，可以迁移到低成本存储上。

热存储

热存储存放最近 N 天的日志，通常是一周到一个月。热存储需要高性能写入和低延迟查询。Peta 使用ClickHouse 作为热存储引擎。ClickHouse 是列式存储数据库，对分析型查询性能极佳，支持高吞吐写入，压缩比高。

冷存储

冷存储存放超过 N 天的日志，可以是一年到七年。冷存储需要低成本、高容量。Peta 使用 S3 或 Azure Blob 作为冷存储。数据以 Parquet 或 ORC 格式压缩存储，查询时通过 Presto 或 Athena 进行。

热转冷流程

日志从热存储迁移到冷存储的过程是自动的。每天定时任务扫描热存储，找到超过保留期限的分区。将分区数据导出为 Parquet 文件，上传到 S3。从热存储中删除已迁移的分区。在元数据中记录数据位置，确保查询时可以路由到正确的存储。迁移过程对用户透明。

温存储

对于查询频率介于热数据和冷数据之间的日志，可以使用温存储。温存储可以是成本适中的存储，如本地 HDD 或普通云盘。Peta 支持三级存储：热、温、冷。

五、压缩与生命周期管理

为了控制存储成本，需要对审计日志进行压缩和生命周期管理。

压缩策略

ClickHouse 默认使用 LZ4 压缩，压缩比约为 3 到 5 倍。对于冷存储，可以使用 ZSTD 压缩，压缩比可达 10 到20 倍。针对 JSON 字段的压缩效果通常很好，因为 JSON 中有大量重复的键名。

生命周期策略

审计日志的生命周期策略包括以下阶段。热保留期，例如 30 天，日志保留在 ClickHouse 中。温保留期，例如90 天，日志迁移到温存储。冷保留期，例如 365 天，日志迁移到冷存储。归档期，例如 7 年，日志归档到Glacier 或 Deep Archive。销毁期，超过保留期限的日志被安全销毁，满足合规要求。

Peta 支持配置灵活的生命周期策略，不同租户可以有不同的保留期。金融行业的租户可能需要 7 年保留期，而内部测试租户可能只需要 30 天。

数据清理

数据清理必须确保合规。删除操作需要审计，记录谁在什么时间删除了哪些日志。硬删除后数据不可恢复，软删除后数据可以恢复。Peta 默认使用软删除，标记删除而非物理删除，保留恢复窗口。恢复窗口过期后，自动执行硬删除。

六、查询优化

在海量审计日志中进行快速查询，需要多方面的优化。

索引设计

ClickHouse 使用稀疏索引。分区键选择时间字段，可以快速过滤分区。排序键选择高频查询字段，如tenant_id、caller_id、target。数据按照排序键的顺序存储，相同值的记录连续存放，利于压缩和查询。跳数索引可以对非排序键字段建立索引。

物化视图

对于常见的查询模式，可以创建物化视图。物化视图是预计算的结果集，查询时直接读取，无需扫描原始数据。例如，创建按天聚合的调用统计视图，每天每个 Skill 的调用次数、成功率、平均延迟。创建按租户聚合的成本视图，每个租户的每日成本汇总。

查询路由

查询路由层根据查询条件自动选择数据源。查询近期数据时，路由到 ClickHouse。查询历史数据时，路由到 S3 或 Presto。查询跨越热冷边界时，分别查询后合并结果。Peta 的查询路由对用户透明。

分页与限制

审计日志查询通常需要分页。使用游标分页而不是偏移量分页，偏移量分页在大偏移量时性能差。设置最大返回行数，防止查询返回过多数据。设置查询超时，防止慢查询占用资源。

七、Peta 的审计日志实践

Peta 在生产环境中管理着数百 TB 的审计日志，积累了丰富的实践经验。

写入优化

Peta 的审计日志写入采用批量异步写入。网关先将日志放入本地缓冲区，每积累 1000 条或每 100 毫秒批量写入 ClickHouse。批量写入减少了网络往返和写入次数。写入失败时自动重试，重试 3 次后仍失败则写入本地文件作为备份，防止日志丢失。

查询优化

针对常见的查询模式，Peta 创建了多个物化视图。热点查询从物化视图返回结果，通常在一秒内。复杂查询直接扫描原始数据，根据时间范围和数据量，响应时间在几秒到几分钟之间。管理员可以查看慢查询日志，优化查询条件。

数据大小

在典型配置下，每条审计日志原始 JSON 大小约为 1 到 2 KB。经过 ClickHouse 压缩后，每条日志平均占用约200 到 400 字节。压缩比约为 5 到 10 倍。一年的日志量取决于调用频率，一百万次调用每天约产生 200 到400 MB 压缩后数据。十亿次调用每天约产生 200 到 400 GB。

八、常见问题与解决方案

问题一：写入延迟过高

原因可能是批量太小，频繁提交。解决方案是增大批量大小和提交间隔。也可能是磁盘 I/O 瓶颈，使用 SSD 而不是 HDD。

问题二：查询超时

原因可能是扫描数据量过大，缩小查询时间范围。可能是缺少分区键过滤，确保查询条件包含时间字段。也可能是查询结果集过大，增加分页限制。

问题三：存储成本过高

原因可能是保留期过长，评估业务需求，适当缩短保留期。可能是压缩比低，更换压缩算法，如使用 ZSTD。也可能是未使用冷热分离，将历史数据迁移到低成本存储。

问题四：日志丢失

原因可能是网关崩溃导致缓冲区丢失，使用 WAL 预写日志，崩溃后可以恢复。可能是 ClickHouse 写入失败，增加重试次数，配置本地文件备份。

九、小结

本章的核心结论可以总结为以下几点。

第一，审计日志是 MCP 治理体系的核心数据。规模化存储和高效查询是生产级部署的必要条件。

第二，数据模型设计应遵循字段类型明确、避免深嵌套、预定义常用字段、预留扩展空间的原则。

第三，分区策略包括时间分区、租户分区、Skill 分区、复合分区。分区是提升查询性能的关键。

第四，冷热分离存储大幅降低存储成本。热存储使用 ClickHouse，冷存储使用 S3 或 Azure Blob。

第五，压缩和生命周期管理进一步控制成本。LZ4 适合热存储，ZSTD 适合冷存储。生命周期包括热保留、温保留、冷保留、归档、销毁。

第六，查询优化包括索引设计、物化视图、查询路由、分页限制。

第七，Peta 使用批量异步写入优化写入性能，使用物化视图优化查询性能，支持灵活的保留期配置。

在下一章，我们将讨论 MCP 控制平面的容灾与备份恢复策略。