OpenTelemetry OTTL 怎样按条件修改日志属性

OpenTelemetry OTTL 可以用 set(目标, 值) where 条件 按条件修改日志属性。在 Transform Processor 的 log_statements 中使用 log.attributes 指向单条日志，使用 resource.attributes 判断服务归属；只有条件为真才执行赋值。若只想补缺失字段，还要在条件中明确比较 nil。

官方地址：https://opentelemetry.io/docs/collector/transforming-telemetry/

把条件写在字段变换旁边

这种模式把“哪些记录允许修改”和“修改哪个字段”放在同一条声明里。例如 AI 推理网关的日志需要统一检索标签，可以只给目标服务中具有模型字段、且尚未填写类别的记录补上 workload.kind。这里的业务键由应用自行约定，不声称它们属于 OpenTelemetry 标准语义属性。

最小写法如下。这是 Collector 配置片段，需要合入现有配置；不要把孤立的 OTTL 字符串当成可以在终端直接执行的命令。

processors:
  transform/model_logs:
    error_mode: ignore
    log_statements:
      # 只补单条日志中尚不存在的业务属性
      - 'set(log.attributes["workload.kind"], "inference") where resource.attributes["service.name"] == "harbor-model-gateway" and log.attributes["model.name"] != nil and log.attributes["workload.kind"] == nil'

命中条件时，目标键写入字符串 inference；已有值则保留。语句没有读取或修改日志正文，也不会凭空产生模型名称。

明确服务范围和日志属性层级

先确认输入数据的实际层级。resource.attributes["service.name"] 是资源属性，通常用于标识产生日志的服务；log.attributes["model.name"] 是这条日志携带的业务字段。两处即使使用同名键，也不是同一个位置。

示例读取资源层的服务名，仅修改日志层的 workload.kind。不要为了给一条日志打标签而改资源属性：同一资源可能关联多条记录，修改资源会扩大影响范围。log.body 则是正文；正文里出现模型名，不表示日志属性中已存在该键。

配置只补缺失字段的日志处理器

仅声明处理器不会自动作用于日志，还需把实例名称列入 service.pipelines.logs.processors。以下给出完整的本地教学配置，OTLP HTTP 只绑定回环地址，输出到 debug exporter。线上应合并已有接收器和导出器，不要直接替换现网配置。

receivers:
  otlp:
    protocols:
      http:
        # 教学入口只接收本机发送的数据
        endpoint: 127.0.0.1:4318

processors:
  transform/model_logs:
    # 运行期转换错误记入日志，继续处理后续语句
    error_mode: ignore
    log_statements:
      - 'set(log.attributes["workload.kind"], "inference") where resource.attributes["service.name"] == "harbor-model-gateway" and log.attributes["model.name"] != nil and log.attributes["workload.kind"] == nil'
      # 第二条独立规则：只给目标服务缺失的来源标签补值
      - 'set(log.attributes["ingest.source"], "collector") where resource.attributes["service.name"] == "harbor-model-gateway" and log.attributes["ingest.source"] == nil'

exporters:
  debug:
    # 仅在受控环境观察合成日志，避免打印真实业务内容
    verbosity: detailed

service:
  pipelines:
    logs:
      receivers: [otlp]
      processors: [transform/model_logs]
      exporters: [debug]

使用包含 transform 组件的发行版，例如 Collector Contrib。本文采用当前官方 README 展示的显式路径前缀写法；若部署的是较早版本，应参考与二进制版本对应的文档，不能假定仓库 main 的配置对所有旧版都适用。

这里第二条规则没有要求 model.name 存在，因此目标服务的普通日志也可以补来源标签。这是有意设置的独立范围，不是第一条语句的附属条件。若两条规则必须使用同一个筛选范围，就要在各自的 where 中写全约束，或明确采用分组条件。

识别覆盖与条件组合反例

set 是赋值操作，不是自动“只插入”。去掉目标键的 == nil 条件后，只要其余条件命中，就可能覆盖业务已经写好的分类。空字符串也不等于不存在：若业务希望空字符串也被补全，可以将目标检查写成带括号的二选一条件。

processors:
  transform/fill_empty:
    error_mode: ignore
    log_statements:
      # 括号限定二选一范围，避免空字符串条件越过服务限制
      - 'set(log.attributes["workload.kind"], "inference") where resource.attributes["service.name"] == "harbor-model-gateway" and (log.attributes["workload.kind"] == nil or log.attributes["workload.kind"] == "")'

这是另一种需求的配置片段，不是前一个完整配置的必加项。它没有要求模型字段存在，作用范围自然更宽；使用时应按业务约束决定是否补上该条件。

还有一个容易混淆的地方：高级配置的 conditions 列表按 OR 组合。把“目标服务”和“字段存在”分别放成两个列表项，不表示必须同时满足。需要同时成立时，把两个表达式用 and 放在同一个条件里。

不要因为日志正文是 JSON 文本，就直接访问正文内的键。字符串正文与 map 正文是不同类型；需要解析正文属于另外的转换任务。本例只使用已采集到的属性，避免把解析失败与条件不命中混为一谈。

理解错误策略和规则顺序的后果

同一处理器中的语句按照配置顺序执行。后面的语句看到的是可能已被前面修改的数据；如果先补类别，再写一条无条件 set，同一个键仍会被覆盖。若后续处理器也写这个键，最终结果还取决于日志流水线中处理器的顺序。

error_mode: ignore 会记录运行期语句错误并继续后续语句；silent 不记录这类错误；propagate 将错误返回上层，可能使相关负载在 Collector 中被丢弃。ignore 不会修复拼错的字段路径，也不能让非法配置在启动时自动变成有效配置。示例选用 ignore 是为了保留错误可见性，不是保证每条变换都成功。

复杂变换也会增加处理开销。本文没有执行基准或采集测试，不给出吞吐量、命中率和延迟数字；对本任务而言，优先用明确的等值与存在条件表达需求。

按输入样例判断适用范围

下表是第一条最小规则的推导案例，不是实测输出。各行只比较 workload.kind，第二条来源标签规则不在本表范围内。

为什么配置写了却没有变化？先区分处理器未接入日志流水线、属性位于不同层级、服务名不匹配和目标已有值；这些情况不都属于执行错误。

没命中的日志会被删除吗？本例的 set where 不会因条件为假而删除日志；条件为假只是跳过赋值。过滤删除是其他处理器或规则的职责。

能否拿它修改 Resource？可以选择资源路径作为目标，但那是更广的资源层修改。本任务只补日志属性，应保持目标为 log.attributes。

采用此模式前，确认目标路径、条件范围、缺失值定义、覆盖策略、流水线绑定和错误处理六件事；输入已经携带的数据，决定了条件能够判断什么。

官方处理器配置：https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/transformprocessor/README.md。函数说明：https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/pkg/ottl/ottlfuncs/README.md。