OpenTelemetry .NET SDK 中日志 Body 字段与 Attributes 的分离实践

在 OpenTelemetry .NET SDK 的日志采集场景中，开发者经常需要处理日志消息体（Body）与属性（Attributes）的分离问题。本文将通过一个典型场景，深入探讨如何实现动态消息体与结构化属性的优雅分离。

核心问题场景

当使用 LoggerMessage 源生成方式记录日志时，开发者会遇到一个典型矛盾：

• 消息模板需要预定义（如 "Food {name} price changed to {price}"）
• 但实际业务中往往需要动态传递完全自由格式的消息体

问题本质分析

通过源码分析可以发现，OpenTelemetry 协议中：

1. Body 字段是日志的独立元素，用于存储主消息内容
2. Attributes 是键值对集合，用于存储结构化元数据
3. 当使用参数化日志方法时，所有参数（包括消息体）默认都会被归入 Attributes

解决方案对比

方案一：参数分离 + 处理器过滤（临时方案）

// 定义日志方法时排除body参数
[LoggerMessage(LogLevel.Information, "{body}")]
public static partial void LogInfo(ILogger logger, 
    string? businessTxKey = null,
    /*其他参数...*/);

// 使用时
logger.LogInfo(
    body: "动态消息内容", // 作为参数传入
    businessTxKey: "123");

通过自定义 Processor 移除 Attributes 中的 body 字段。这种方法虽然可行，但存在架构上的不优雅。

方案二：基础 Log API + 格式化器（推荐方案）

logger.Log(
    logLevel: LogLevel.Information,
    eventId: default,
    state: new List<KeyValuePair<string, object>>()
    {
        new("businessTxKey", "123"),
        // 其他结构化参数...
    },
    exception: null,
    formatter: (state, ex) => "完全动态的消息内容" // 自由控制Body
);

此方案的核心优势：

1. 完全解耦消息体与属性
2. 保持结构化日志的所有优点
3. 消息内容可完全动态生成

最佳实践建议

1. 架构设计原则：

   • 将业务元数据设计为强类型参数
   • 为动态消息保留独立通道

2. 性能考量：

   • 源生成方式仍推荐用于固定模板场景
   • 动态消息场景建议结合两种方案

3. OpenTelemetry 配置：

loggingBuilder.AddOpenTelemetry(options => 
{
    options.IncludeFormattedMessage = true; // 关键配置
    // 其他配置...
});

总结

在 OpenTelemetry .NET 生态中处理日志消息时，理解 Body 和 Attributes 的分离机制至关重要。通过合理选择基础 API 与源生成方式的结合，可以既保持日志的结构化特性，又满足业务对动态消息的需求。建议在实际项目中根据消息稳定性选择混合策略，既保证性能又兼顾灵活性。