Details
Minor Description
Currently the hostname label is set to just the pod name, e.g. cb7-0000, whereas CBS sees the host names as pod.cluster.namespace.svc, for example cb7-0000.cb7.default.svc. For consistency it'd be good to have hostname match that.
Attachments
| For Gerrit Dashboard: K8S-2531 | ||||||
|---|---|---|---|---|---|---|
| # | Subject | Branch | Project | Status | CR | V |
| 169449,13 | K8S-2531: Set pod hostname label | main | couchbase-fluent-bit | Status: MERGED | +2 | +1 |
Activity
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.
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
I think the right way to do this is using the modify filter with conditional rules to overwrite the couchbase.node key:
[FILTER]Name modifyMatch 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.