使用OpenTelemetry处理器解析日志traceId/spanId遇阻求助

背景 #

• 核心需求：解析日志中的属性，使其可在ES等后端查询
• 过往尝试：使用支持stanza operators的otel filelog receiver，但因不支持多行解析，改用FluentBit采集日志
• 当前困境：计划用logstransform处理器处理日志，但0.68.0版本的otel-contrib发行版未包含该组件

配置与报错 #

尝试的logstransform处理器配置 #

processor:
  logstransform:
    operators:
      - type: regex_parser
        id: trace_parser
        regex: 'traceId=(?P<trace_id>\S*)'
        parse_from: body
        trace:
          trace_id:
            parse_from: attributes.trace_id

启动报错信息 #

2023/01/05 17:22:19 collector server run finished with error: failed to get config: cannot unmarshal the configuration: 1 error(s) decoding:

* error decoding 'processors': unknown processors type: "logstransform" for id: "logstransform" (valid values: [attributes groupbytrace k8sattributes metricstransform probabilistic_sampler tail_sampling batch memory_limiter transform cumulativetodelta routing servicegraph span groupbyattrs resourcedetection experimental_metricsgeneration redaction resource spanmetrics deltatorate filter])

待解析日志行 #

[2022-12-30 12:34:56] [INFO] [Hotel Management System] traceId=4bf92f3577b34da6a3ce929d0e0e4736 spanId=00f067aa0ba902b7 message="Guest John Doe checked into room 214 for a 3-night stay." guestName=John Doe roomNumber=214 stayLength=3 night

期望处理后的日志格式 #

Resource SchemaURL: https://opentelemetry.io/schemas/1.6.1
Resource attributes:
     -> cloud.provider: Str(gcp)
     -> cloud.account.id: Str(project-jiomarket-non-prod)
     -> cloud.platform: Str(gcp_kubernetes_engine)
     -> cloud.region: Str(asia-south1)
     -> k8s.cluster.name: Str(cluster-central-alpha)
     -> host.id: Str(6758479764707402031)
ScopeLogs #0
ScopeLogs SchemaURL:
InstrumentationScope
LogRecord #0
ObservedTimestamp: 1970-01-01 00:00:00 +0000 UTC
Timestamp: 2023-01-05 18:22:02.466838531 +0000 UTC
SeverityText:
SeverityNumber: Unspecified(0)
Body: Str([2023-01-05 12:34:56] [INFO] [Hotel Management System] traceId=4bf92f3577b34da6a3ce929d0e0e4736 spanId=00f067aa0ba902b7 message="Guest John Doe checked into room 214 for a 3-night stay." guestName=John Doe roomNumber=214 stayLength=3 night
)
Attributes:
     -> fluent.tag: Str(kube.var.log.pods.newco_newcoshop-master-55c7f9d9f4-rmnqc_d02aa156-1671-4d58-b017-2e763b2d1683.newcoshop-master.test.log)
Trace ID: 4bf92f3577b34da6a3ce929d0e0e4736
Span ID: 00f067aa0ba902b7
Flags: 0
    {"kind": "exporter", "data_type": "logs", "name": "logging"}

解决方案建议 #

1. 升级OTel Collector版本：logstransform处理器在0.70.0及以上的otel-contrib版本中已被正式包含，升级后即可直接使用原配置逻辑。
2. 用transform处理器替代：在现有0.68.0版本中，可通过transform处理器实现相同解析与关联逻辑，配置示例：

processors:
  transform:
    log_statements:
      - context: log
        statements:
          # 提取traceId并关联到LogRecord的Trace ID
          - set(attributes.trace_id, regex_match(body, 'traceId=(\S*)')[1])
          - set(trace_id, attributes.trace_id)
          # 提取spanId并关联到LogRecord的Span ID
          - set(attributes.span_id, regex_match(body, 'spanId=(\S*)')[1])
          - set(span_id, attributes.span_id)
          # 提取其他业务属性
          - set(attributes.guest_name, regex_match(body, 'guestName=(\S*\s\S*)')[1])
          - set(attributes.room_number, regex_match(body, 'roomNumber=(\d*)')[1])
          - set(attributes.stay_length, regex_match(body, 'stayLength=(\d*)')[1])

3. 在FluentBit阶段提前解析：利用FluentBit的parser插件直接在采集阶段解析traceId、spanId及业务属性，再传递给OTel Collector，减少Collector侧的处理负载。

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