Audit.NET 库中处理大尺寸审计日志的最佳实践

前言

在使用 Audit.NET 库进行审计日志记录时，开发人员可能会遇到一个常见问题：当审计事件数据过大时，会触发"属性值超过最大允许大小(64KB)"的错误。本文将深入探讨这一问题的成因，并提供多种解决方案。

问题分析

Azure Table Storage 对单个属性值有严格的大小限制：最大64KB。对于字符串值，由于UTF-16编码，实际字符数限制约为32K。当审计事件包含大量数据（如完整HTTP请求/响应体、长头信息等）时，很容易超出这一限制。

解决方案

1. 请求过滤与数据裁剪

首先，可以通过配置中间件来减少不必要的审计记录：

app.UseAuditMiddleware(_ => _
    .FilterByRequest(r => 
        !r.Method.Equals("GET", StringComparison.OrdinalIgnoreCase) 
        && r.Path.StartsWithSegments("/api"))
    .WithEventType("{verb}:{url}")
    .IncludeHeaders()
    .IncludeResponseHeaders()
    .IncludeResponseBody());

2. 数据裁剪策略

对于必须记录的大型数据，实施裁剪策略：

Audit.Core.Configuration.AddCustomAction(ActionType.OnEventSaving, scope =>
{
    var action = scope.GetWebApiAuditAction();
    
    // 裁剪过长的头信息
    foreach (var headerKey in action.Headers.Keys)
    {
        if (action.Headers[headerKey]?.Length > 1024)
        {
            action.Headers[headerKey] = "数据过长已裁剪...";
        }
    }

    // 处理响应体
    if (action.ResponseBody is { Value: not null, Length: > 16384 })
    {
        action.ResponseBody.Value = "响应体过大已裁剪...";
    }
});

3. 自定义存储策略

对于Azure Table Storage，可以自定义实体构建逻辑：

Configuration.Setup()
    .UseAzureTableStorage(config => config
        .ConnectionString("...")
        .TableName(evt => "...")
        .EntityBuilder(builder => builder
            .PartitionKey(auditEvent => auditEvent.Environment.UserName)
            .RowKey(auditEvent => Guid.NewGuid().ToString("N"))
            .Columns(col => col.FromDictionary(auditEvent => 
                new Dictionary<string, object>() 
                { 
                    { "Data", ProcessLargeData(auditEvent) }
                })));

其中ProcessLargeData方法负责处理大数据：

private static string ProcessLargeData(AuditEvent auditEvent)
{
    var json = auditEvent.ToJson();
    return json.Length > 32000 ? "数据过大已裁剪" : json;
}

4. 容错机制

使用Polly实现弹性策略：

var primaryProvider = new AzureTableDataProvider(...);
var fallbackProvider = new FileDataProvider(...);

Audit.Core.Configuration.Setup()
    .UsePolly(polly => polly
        .DataProvider(primaryProvider)
        .WithResilience(resilience => resilience
            .AddFallback(new()
            {
                ShouldHandle = new PredicateBuilder().Handle<Exception>(),
                FallbackAction = args => args.FallbackToDataProvider(fallbackProvider)
            })));

最佳实践建议

1. 合理过滤：只审计必要的请求，避免记录静态资源、健康检查等
2. 数据精简：只保留关键信息，裁剪冗余数据
3. 分层存储：对超大审计事件考虑使用Blob存储+Table存储引用
4. 监控机制：记录审计失败的次数和原因
5. 性能考量：异步处理审计事件，不影响主业务流程

总结

处理审计日志大小限制需要综合考虑业务需求、存储限制和系统性能。通过合理配置Audit.NET库的过滤策略、数据裁剪机制和弹性存储方案，可以构建出既满足审计需求又稳定可靠的日志系统。对于特别大的审计数据，建议考虑使用专门的大数据存储方案，或实现数据分片存储策略。