Audit.NET 中处理 Elasticsearch 连接失败的优雅降级方案

在分布式系统中，日志和审计功能是保障系统可观测性的重要组成部分。Audit.NET 作为一个强大的审计日志框架，提供了与 Elasticsearch 集成的能力。然而，在实际生产环境中，Elasticsearch 服务可能会因为网络问题、服务重启或资源不足等原因出现暂时不可用的情况。本文将深入探讨如何在 Audit.NET 中实现优雅降级，确保系统在 Elasticsearch 不可用时仍能保持稳定运行。

问题背景

当使用 Audit.NET 的 AuditMiddleware 中间件时，如果配置了 Elasticsearch 作为数据存储后端，一旦 Elasticsearch 服务不可用，默认情况下会抛出异常。这种设计虽然能及时暴露问题，但在某些场景下可能过于严格，特别是当审计日志功能不应该影响主业务流程时。

解决方案一：自定义数据提供者

最直接的解决方案是创建自定义的数据提供者，继承自 ElasticsearchDataProvider 并重写关键方法，加入异常处理逻辑：

public class ResilientElasticsearchProvider : ElasticsearchDataProvider
{
    private readonly ILogger _logger;

    public ResilientElasticsearchProvider(
        Action<IElasticsearchProviderConfigurator> config,
        ILogger<ResilientElasticsearchProvider> logger) 
        : base(config)
    {
        _logger = logger;
    }

    public override object InsertEvent(AuditEvent auditEvent)
    {
        try
        {
            return base.InsertEvent(auditEvent);
        }
        catch (Exception ex)
        {
            _logger.LogError(ex, "Failed to insert audit event to Elasticsearch");
            return null; // 静默处理
        }
    }

    public override async Task<object> InsertEventAsync(
        AuditEvent auditEvent, 
        CancellationToken cancellationToken = default)
    {
        try
        {
            return await base.InsertEventAsync(auditEvent, cancellationToken);
        }
        catch (Exception ex)
        {
            _logger.LogError(ex, "Failed to insert audit event to Elasticsearch");
            return null;
        }
    }
}

这种方式的优势在于：

1. 实现简单直接
2. 可以灵活控制异常处理逻辑
3. 能够集成应用现有的日志系统
4. 不影响原有业务流程

解决方案二：使用 Polly 实现弹性策略

对于需要更复杂容错机制的场景，可以结合 Polly 库实现更强大的弹性策略。Audit.NET 提供了专门的 Polly 集成包，支持多种弹性模式：

Audit.Core.Configuration.Setup()
    .UsePolly(p => p
        .DataProvider(new ElasticsearchDataProvider(config => 
            config.Client(new Uri("http://elastic:9200"))))
        .WithResilience(resilience => resileince
            .AddRetry(new()
            {
                ShouldHandle = new PredicateBuilder().Handle<Exception>(),
                Delay = TimeSpan.FromSeconds(1),
                MaxRetryAttempts = 2
            })
            .AddFallback(new()
            {
                ShouldHandle = new PredicateBuilder().Handle<Exception>(),
                FallbackAction = args => args.FallbackToDataProvider(
                    new FileDataProvider(config => 
                        config.Directory(@"C:\Temp\AuditLogs")))
            })));

这个配置实现了：

1. 首次失败后自动重试 2 次
2. 如果重试全部失败，则降级到文件存储
3. 整个过程对应用透明，不会抛出异常

方案选型建议

对于不同场景，我们建议：

1. 开发环境：可以直接使用默认行为，快速发现问题
2. 关键业务系统：采用 Polly 方案，确保审计日志不丢失
3. 非关键辅助系统：使用简单的自定义提供者，静默处理异常
4. 高并发系统：考虑结合内存缓存作为中间层，缓解 Elasticsearch 压力

最佳实践

1. 始终监控 Elasticsearch 的健康状态
2. 为降级方案设置适当的存储空间监控
3. 定期测试故障转移机制的有效性
4. 考虑实现自动恢复机制，当 Elasticsearch 恢复后自动回迁数据
5. 在系统文档中明确记录审计日志的可靠性级别

通过以上方案，开发者可以确保 Audit.NET 在 Elasticsearch 不可用时仍能提供可靠的服务，同时保持系统的整体稳定性。这种设计符合现代分布式系统的容错原则，是构建健壮应用程序的重要一环。