I think the right way to do this is using the modify filter with conditional rules to overwrite the couchbase.node key:

[FILTER]

    Name        modify

    Match        couchbase.log.*

    Condition   Key_Exists                              pod['namespace']

    Condition   Key_Exists                              couchbase['cluster']

    Condition   Key_Exists                              couchbase['node']

    Set         couchbase.node   $couchbase['node'].$couchbase['cluster'].$pod['namespace']

Not sure if you can set a nested field that way so confirm, it might also be better to set up a new field for it but really we want a simple one-size-fits-all for Loki labelling with both on-premise and CAO clusters.

Hostname would also be fine I think and then switch to that for Loki.

Personally I'd argue for hostname as it's not K8s specific, meaning the configuration (and thus LogQL) can be the same whether on k8s or on-prem, whereas if we used couchbase.node, we'd have the situation where you need to use hostname for on-prem but couchbase.node for k8s.

Aaron Benton any preference or comments?

Patrick Stephens no preference.  I've used node, hostname and I have a few customers that use instance.  This is a label added automatically by prometheus at scrape time.  Then we just added a relabel config in prometheus to strip the port off, this way metrics from various jobs can still be correlated from the same instance.  

Let's go with hostname then, it's just a helper currently and not being used by anything. May as well make it accurate.

Build couchbase-fluent-bit-1.1.3-111 contains couchbase-fluent-bit commit 25c7f11 with commit message:
K8S-2531: Set pod hostname label

Covered in logging tests