-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[processor/k8sattributes] Operator resource attributes #37114
base: main
Are you sure you want to change the base?
Changes from all commits
a3c9923
f0eea3d
89edad2
7ff75fa
1b690ac
0f60422
1d676dd
c22d45c
18b99c0
98b29ee
926ff32
b2b46dc
d4dc77d
61b534d
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,13 @@ | ||
change_type: enhancement | ||
|
||
component: k8sattributesprocessor | ||
|
||
note: Add option to configure resource attributes using the same logic as the OTel operator | ||
|
||
issues: [37114] | ||
|
||
subtext: | | ||
If you are using the file log receiver, you can now create the same resource attributes as traces (via OTLP) received | ||
from an application instrumented with the OpenTelemetry Operator - | ||
simply by adding the `extract: { operator_rules: { enabled: true } }` configuration to the `k8sattributesprocessor` processor. | ||
See the [documentation](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/processor/k8sattributesprocessor/README.md#config-example) for more details. |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -272,10 +272,19 @@ k8sattributes/2: | |
- k8s.node.name | ||
- k8s.pod.start_time | ||
labels: | ||
# This label extraction rule takes the value 'app.kubernetes.io/component' label and maps it to the 'app.label.component' attribute which will be added to the associated resources | ||
- tag_name: app.label.component | ||
key: app.kubernetes.io/component | ||
from: pod | ||
# This label extraction rule takes the value 'app.kubernetes.io/component' label and maps it to the 'app.label.component' attribute which will be added to the associated resources | ||
- tag_name: app.label.component | ||
key: app.kubernetes.io/component | ||
from: pod | ||
operator_rules: | ||
# Apply the operator rules - see https://github.com/open-telemetry/opentelemetry-operator#configure-resource-attributes | ||
enabled: true | ||
# Also translate the following labels to the specified resource attributes: | ||
# app.kubernetes.io/name => service.name | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It is mentioned before that these should be standardized at some point: open-telemetry/opentelemetry-helm-charts#905 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. OK - I'll work with semconv before I continue with this PR There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I've created open-telemetry/semantic-conventions#1756 for the spec part |
||
# app.kubernetes.io/version => service.version | ||
# app.kubernetes.io/part-of => service.namespace | ||
# This setting is ignored if 'enabled' is set to false | ||
labels: true | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Could we use like |
||
pod_association: | ||
- sources: | ||
# This rule associates all resources containing the 'k8s.pod.ip' attribute with the matching pods. If this attribute is not present in the resource, this rule will not be able to find the matching pod. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would avoid calling this feature
operator_rules
. If we decide on supporting this from the Collector at first place then it should have a generic name not coupled to the Operator project.Also from this section it's not clear if we support both labels and annotations (as described in the Operator's docs). Is sth like
resource.opentelemetry.io/service.name: "my-service"
supported?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good idea - I just didn't find a good name so far
the linked page describes it:
Annotations like this
labels like this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#27261 suggests
well_known_labels