[receiver/cloudflare]: Support extracting all attributes in Cloudflare receiver

[panys9]

Component(s)

receiver/cloudflare

Is your feature request related to a problem? Please describe.

Since the Cloudflare receiver by default map all fields in the payload to attributes it should support all data types. Currently it generated a warning which becomes a lot of warnings.

Payload in the body:

{
  "ClientIP": "something",
  "ClientRequestHost": "something",
  "ClientRequestMethod": "POST",
  "ClientRequestURI": "/",
  "EdgeEndTimestamp": "2025-05-27T07:45:17Z",
  "EdgeResponseBytes": 648,
  "EdgeResponseStatus": 200,
  "EdgeStartTimestamp": "2025-05-27T07:45:17Z",
  "RayID": "9463e45639ff0a61",
  "RequestHeaders": {}
}

Warning:
warn cloudflarereceiver@v0.125.0/logs.go:314 unable to translate field to attribute, unsupported type {"otelcol.component.id": "cloudflare", "otelcol.component.kind": "receiver", "otelcol.signal": "logs", "field": "RequestHeaders", "value": {}, "type": "map[string]interface {}"}"

Describe the solution you'd like

Either add support for extracting the fields sent or make it configurable so the receiver doesn't try to extract attributes automatically.

Describe alternatives you've considered

It is possible to solve this using the transform processor but since the receiver does the same it result in wasted cpu.

Processor config:

      transform:
        error_mode: ignore
        log_statements:
          - context: log
            statements:
              - merge_maps(cache, body, "upsert") where IsMatch(body, "^\\{")
              - set(attributes, cache)

Additional context

No response

[github-actions]

Pinging code owners:

• receiver/cloudflare: @dehaansa

See Adding Labels via Comments if you do not have permissions to add labels yourself.

[dehaansa]

Seems like this was a bit of an undesired side effect of #37721 . Definitely worth a fix, if the logs bother you however you can explicitly name the attributes you would like to include while waiting for someone to have capacity to fix!

[panys9]

@dehaansa The thing is that I want the fields as attributes and the solution you sugget still make the collector process the attributes twice which is a waste of CPU, especially when handling +10k req/s. The bigger problem is that the receiver can't handle a map[string]any. Created this change but not sure on the best approach.
Here are a few things I consider.

1. Make the extract all fields optional with a config flag
2. Keep as is but support extracting a map[string]any
3. If adding support for map[string]any should we use . or _ as separator or should it be configurable with default .?

[dehaansa]

The proposed change looks good, I would be happy to review it as a PR against the receiver.

I agree that supporting #2 is ideal. I would lean towards using the . separator as it's relatively OTel idiomatic, but I'm definitely happy to see it configurable.

In the not-too-distant future there may also be support for complex attributes, at which point the right solution would be to retain the structure and require the exporter(s) to handle how to translate to the form their respective backend supports. However, at that point there can be an opt-in config added to make that change instead of this one.

[panys9]

I also lean towards . and can make it configurable with . as default.

The support for complex attributes look interesting and will read more about it. Will be interesting to see how the processors will handle it when the format get more complex. Like if you for instance want to mask content in headers or something.