OpenTelemetry在Azure Log Analytics中日志丢失问题求助

我正计划迁移到基于Azure Monitor和Log Analytics的OpenTelemetry日志采集方案，写了一个多线程示例程序来写入日志并发送到Azure Log Analytics。低负载（少于1000条日志）时所有消息都能正常送达，但负载提升到20个线程写入10000条消息时，开始出现日志丢失的情况。有意思的是，如果开启OTel的控制台日志，所有消息都会正常显示——这说明微小的延迟可能起到了作用。我正在排查日志是否在导出器或提交环节丢失，求问有没有人遇到过类似问题，或者知道解决方法？

配置代码 #

public static WebApplicationBuilder AddOpenTelemetryServices(
    this WebApplicationBuilder builder,
    bool useAzureMonitor = false,
    bool useConsole = false)
{
    // Remove default providers (Console, Debug, EventSource, etc.)
    builder.Logging.ClearProviders(); // Comment for .NET console logging

    // ----- OpenTelemetry resource (what identifies your service) -----
    var resourceBuilder =
        ResourceBuilder.CreateDefault()
            .AddService(
                serviceName: ServiceName,
                serviceVersion: "1.0.0",
                serviceInstanceId: Environment.MachineName);

    // ----- OpenTelemetry Tracing -----
    var otelBuilder = builder.Services.AddOpenTelemetry()
        .ConfigureResource(rb => rb.AddService(ServiceName))
        .WithTracing(tracing =>
        {
            tracing
                .SetResourceBuilder(resourceBuilder)
                // Always collect (no head sampling drops while developing)
                .SetSampler(new AlwaysOnSampler());

            if (useConsole)
            {
                // Export to console (see spans immediately)
                tracing.AddConsoleExporter();
            }
        })
        .WithLogging(logging =>
        {
            logging.SetResourceBuilder(resourceBuilder);

            if (useConsole)
            {
                logging.AddConsoleExporter();
            }
        });


    if (useAzureMonitor && TryGetConnectionString(builder, out var connectionString))
    {
        otelBuilder.UseAzureMonitor(options =>
         {
             // Send logs/traces/metrics to Application Insights
             // Prefer reading from APPLICATIONINSIGHTS_CONNECTION_STRING.
             options.ConnectionString = connectionString;
         });
    }

    builder.Services.Configure<OpenTelemetryLoggerOptions>(logger =>
    {
        //options.ParseStateValues = true;
        logger.IncludeFormattedMessage = true;
        logger.IncludeScopes = true;
    });
    Console.WriteLine("Open Telemetry is configured.");
    return builder;
}

可能的原因及解决方法 #

1. 调整Azure Monitor导出器的批量配置 #

Azure Monitor导出器默认采用批量发送策略，高负载下默认参数可能导致数据积压或队列溢出。可以显式调整批量相关参数：

otelBuilder.UseAzureMonitor(options =>
{
    options.ConnectionString = connectionString;
    // 优化批量发送参数
    options.LogsExportProcessorOptions.BatchTimeout = TimeSpan.FromSeconds(1);
    options.LogsExportProcessorOptions.MaxQueueSize = 20000;
    options.LogsExportProcessorOptions.MaxExportBatchSize = 1000;
});

• BatchTimeout：设置批量等待的最长时间，避免数据因凑不齐批量数一直滞留
• MaxQueueSize：增大队列容量，防止高负载下队列溢出丢失数据
• MaxExportBatchSize：控制单次导出的最大条数，匹配Azure Monitor的接收限制

2. 确保程序退出时完成剩余数据导出 #

高负载场景下，程序退出时队列中可能还有未发送的日志，需要手动触发导出器的关闭逻辑，确保数据全部发送：

// 在ASP.NET Core应用关闭时添加清理逻辑
app.Lifetime.ApplicationStopping.Register(async () =>
{
    var otelSdk = app.Services.GetRequiredService<OpenTelemetrySdk>();
    await otelSdk.ShutdownAsync();
});

如果是控制台程序，需要监听退出信号（如Console.CancelKeyPress）并调用ShutdownAsync。

3. 检查并发写入的线程安全性 #

确认多线程代码中使用的ILogger实例是通过依赖注入获取的——OpenTelemetry的日志记录器本身是线程安全的，但如果手动创建实例或存在自定义的非线程安全逻辑，可能导致日志丢失。

4. 排查Azure Monitor的限流情况 #

Azure Monitor有请求频率和数据量的配额限制，短时间内发送大量数据可能触发限流，导致部分请求失败。可以在Azure门户查看Application Insights的Requests指标，确认是否有失败请求。如果是限流，可调整批量发送频率，或申请提高服务配额。

5. 显式配置日志处理器 #

默认的日志处理器可能在高负载下处理不及时，可显式配置BatchExportProcessor并调整参数：

.WithLogging(logging =>
{
    logging.SetResourceBuilder(resourceBuilder);
    if (useAzureMonitor && TryGetConnectionString(builder, out var connectionString))
    {
        var exporterOptions = new AzureMonitorExporterOptions { ConnectionString = connectionString };
        logging.AddProcessor(new BatchExportProcessor<LogRecord>(new AzureMonitorLogExporter(exporterOptions)));
    }
    if (useConsole)
    {
        logging.AddConsoleExporter();
    }
});

内容的提问来源于stack exchange，提问作者VinceSuperC