Audit.NET 中实现 CosmosDB 按实体条目存储审计日志的优化方案

背景介绍

在使用 Audit.NET 进行审计日志记录时，默认的 Azure CosmosDB 数据提供程序会将整个 Entity Framework 事件作为一个文档存储。这种存储方式虽然简单，但在实际应用中可能会遇到一些限制，特别是在需要针对单个实体操作进行查询或设置分区键时。

默认存储结构的问题

默认情况下，Audit.NET 会将所有实体操作记录在一个文档中，结构如下：

{
    "EntityFrameworkEvent": {
        "Database": "数据库名称",
        "ContextId": "上下文ID",
        "Entries": [
            // 实体操作条目数组
        ]
    }
}

这种结构存在两个主要问题：

1. 分区键设置困难：审计细节位于嵌套的 Entries 数组中，难以直接作为分区键
2. 查询效率问题：当需要查询特定实体类型的操作时，需要扫描整个文档

优化方案设计

为了解决这些问题，我们可以通过自定义数据提供程序，将每个实体操作存储为独立的文档。优化后的文档结构如下：

{
    "Database": "数据库名称",
    "LinkKey": "关联操作的唯一标识",
    // 实体操作详情
    // 其他审计数据
}

实现方法

从 Audit.NET 25.0.3 版本开始，可以通过继承 AzureCosmosDataProvider 类并重写相关方法来实现这种优化存储方式：

public class CosmosEfDataProvider : AzureCosmosDataProvider
{
    public CosmosEfDataProvider(Action<IAzureCosmosProviderConfigurator> config) : base(config) { }

    public override async Task<object> InsertEventAsync(AuditEvent auditEvent, CancellationToken cancellationToken = default)
    {
        var container = base.GetContainer(auditEvent);
        var efEvent = auditEvent.GetEntityFrameworkEvent();

        foreach (var entry in efEvent.Entries)
        {
            var audit = new CustomAuditDocument 
            { 
                Database = efEvent.Database,
                LinkKey = Guid.NewGuid(),
                Entry = entry
            };
            await container.CreateItemAsync(audit, cancellationToken: cancellationToken);
        }

        return null;
    }
}

优势分析

这种优化方案带来了几个显著优势：

1. 灵活的分区策略：可以根据实体类型、操作时间等关键字段设置分区键
2. 查询性能提升：针对特定实体类型的查询可以直接命中相关文档
3. 存储粒度控制：可以针对不同类型的实体设计不同的文档结构
4. 成本优化：细粒度的文档可以更好地利用 CosmosDB 的存储和吞吐量

实际应用建议

在实际项目中应用此方案时，建议考虑以下几点：

1. 关联操作处理：通过 LinkKey 字段保持同一事务中多个操作的关联性
2. 文档设计：根据查询需求设计文档结构，确保常用查询能够高效执行
3. 分区策略：根据查询模式选择合适的分区键，如按日期、实体类型或租户ID
4. 索引策略：为常用查询字段配置适当的索引

总结

通过自定义 Audit.NET 的 CosmosDB 数据提供程序，我们可以将审计日志的存储粒度从每个事务调整为每个实体操作。这种优化不仅解决了分区键设置的难题，还提升了查询效率和系统灵活性。对于使用 CosmosDB 作为审计存储的中大型应用，这种方案值得考虑实施。