Skip to content

[chore][receiver/k8scluster] Add pods field to allocatable_types_to_report parameter options #39924

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

Open
wants to merge 6 commits into
base: main
Choose a base branch
from

Conversation

odubajDT
Copy link
Contributor

@odubajDT odubajDT commented May 7, 2025

Link to tracking issue

Fixes #39923

@odubajDT odubajDT added the Skip Changelog PRs that do not require a CHANGELOG.md entry label May 7, 2025
@odubajDT odubajDT marked this pull request as ready for review May 7, 2025 12:09
@odubajDT odubajDT requested review from dmitryax, TylerHelmuth, ChrsMark and a team as code owners May 7, 2025 12:09
@github-actions github-actions bot requested a review from povilasv May 7, 2025 12:09
@odubajDT odubajDT force-pushed the k8sclusterreceiver-pods-allocable branch from be0d2bb to 430eeab Compare May 7, 2025 12:09
Copy link
Member

@ChrsMark ChrsMark left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍🏼

Could you file an issue for Semantic Conventions project as well? It seems we miss those from the list of existing metrics open-telemetry/semantic-conventions#1032.

Probably that's because they are not explicitly defined in the metadata.yaml.

@odubajDT
Copy link
Contributor Author

odubajDT commented May 8, 2025

👍🏼

Could you file an issue for Semantic Conventions project as well? It seems we miss those from the list of existing metrics open-telemetry/semantic-conventions#1032.

Probably that's because they are not explicitly defined in the metadata.yaml.

Sure open-telemetry/semantic-conventions#2243

@odubajDT odubajDT force-pushed the k8sclusterreceiver-pods-allocable branch from 27fa221 to 3a48d97 Compare May 8, 2025 07:38
@@ -3017,6 +3073,11 @@ func (mb *MetricsBuilder) RecordK8sNamespacePhaseDataPoint(ts pcommon.Timestamp,
mb.metricK8sNamespacePhase.recordDataPoint(mb.startTime, ts, val)
}

// RecordK8sNodeAllocatableDataPoint adds a data point to k8s.node.allocatable metric.
func (mb *MetricsBuilder) RecordK8sNodeAllocatableDataPoint(ts pcommon.Timestamp, val int64) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see any actual code that uses it. Is it expected?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is a generated code by mdatagen. Even if it's not used, the CI will fail if it's not present

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is coming from https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/39924/files#r2116129944 right?

We would need to split the metrics in the metadata.yaml and then use the generated code instead of the custom one at

func CustomMetrics(set receiver.Settings, rb *metadata.ResourceBuilder, node *corev1.Node, nodeConditionTypesToReport,
.

k8s.node.allocatable:
enabled: false
description: The allocatable metrics of a particular Node.
unit: ""
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldnt this have a unit?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since allocatable is a multi-datapoint metric (you can have allocatable memory, cpu, pods etc), it does not make sense to have a unit here

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In that case, shouldn't be different metrics? We hit the same issue in resourcequota metrics and we had to split: open-telemetry/semantic-conventions#2076 (comment)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually that will be covered by open-telemetry/semantic-conventions#2267 anyways, right?

But can't we just split the metrics in the metadata.yaml already since those are already different metrics:

?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if the code owners agree, I would wait until the semconv is clear and merged and afterwards the receiver can be adapted accordingly, anybody against this approach?

Copy link
Member

@ChrsMark ChrsMark left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we need to deprecate this approach that uses the allocatable_types_to_report setting to enable 5 different metrics and define each metric on its own properly.

For now we can just add support for pods and work on a follow-up to make it happen properly through the metadata.yaml etc.

Right now the addition of the k8s.node.allocatable in the metadata.yaml does not make any sense as https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/39924/files#r2109946850 point out, right?

We will also need to coordinate this change with open-telemetry/semantic-conventions#2267, probably first ship the SemConv part and then introduce the metrics one by one in metadata.yaml, and eventually deprecate the allocatable_types_to_report setting.

k8s.node.allocatable:
enabled: false
description: The allocatable metrics of a particular Node.
unit: ""
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually that will be covered by open-telemetry/semantic-conventions#2267 anyways, right?

But can't we just split the metrics in the metadata.yaml already since those are already different metrics:

?

@@ -3017,6 +3073,11 @@ func (mb *MetricsBuilder) RecordK8sNamespacePhaseDataPoint(ts pcommon.Timestamp,
mb.metricK8sNamespacePhase.recordDataPoint(mb.startTime, ts, val)
}

// RecordK8sNodeAllocatableDataPoint adds a data point to k8s.node.allocatable metric.
func (mb *MetricsBuilder) RecordK8sNodeAllocatableDataPoint(ts pcommon.Timestamp, val int64) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is coming from https://github.com/open-telemetry/opentelemetry-collector-contrib/pull/39924/files#r2116129944 right?

We would need to split the metrics in the metadata.yaml and then use the generated code instead of the custom one at

func CustomMetrics(set receiver.Settings, rb *metadata.ResourceBuilder, node *corev1.Node, nodeConditionTypesToReport,
.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
receiver/k8scluster Skip Changelog PRs that do not require a CHANGELOG.md entry waiting-for-code-owners
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[receiver/k8scluster] Add pods field to allocatable_types_to_report parameter options
7 participants