Skip to content

Revert logs service_name preference of container.name vs k8s.pod.name #1533

@cyrille-leclerc

Description

@cyrille-leclerc

The logs service_name logic used to prioritize the value of container.name over k8s.pod.name before we started embracing the OpenTelemetry operator naming conventions for service.name (here) through the PR #1175 .

Unfortunately, as we haven't yet fully implemented the OTel Operator logic, not yet retrieving k8s.deployment.name, k8s.cronjob.name, or k8s.job.name, we end up too often with the logs service_name picking k8s.pod.name.

Waiting to fully implement the OTel Operator service name logic, we want to revert the previous behaviour and prioritize container.name over pod.name.

The logic is implemented in

// explicitly set service_name. if not set, loki will automatically try to populate a default.
// see https://grafana.com/docs/loki/latest/get-started/labels/#default-labels-for-all-users
//
// choose the first value found from the following ordered list:
// - pod.annotation[resource.opentelemetry.io/service.name]
// - pod.label[app.kubernetes.io/name]
// - k8s.pod.name
// - k8s.container.name
rule {
action = "replace"
source_labels = [
"__meta_kubernetes_pod_annotation_resource_opentelemetry_io_service_name",
"__meta_kubernetes_pod_label_app_kubernetes_io_name",
"__meta_kubernetes_pod_name",
"__meta_kubernetes_pod_container_name",
]
separator = ";"
regex = "^(?:;*)?([^;]+).*$"
replacement = "$1"
target_label = "service_name"
}

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions