Repository navigation
feat(stg): Add OTel Pod CONSUMES PersistentVolumeClaim relationship - #3349
Conversation
Add otelKsmK8sPodConsumesPersistentVolumeClaim to a staging override of the Pod-to-PVC relationship file. It keys on the kube-state-metrics kube_pod_spec_volumes_persistentvolumeclaims_info metric, which is pod-centric: entity.guid is the Pod, and k8s.pvc.name, k8s.namespace.name and k8s.cluster.name identify the PVC. The Pod is extracted from entity.guid and the PVC GUID is built from cluster:namespace:pvc, matching the PVC entity's compositeIdentifier. The existing Kubernetes Integration rule is carried over unchanged. Add a kube_pod_spec_volumes_persistentvolumeclaims_info row to the Pod OTel test fixture. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
entityBot
left a comment
entityBot
left a comment
There was a problem hiding this comment.
We don't think these changes require an API Review Board (ARB) review, so it is not required to merge this PR. Note that all API changes do require one: if you believe this PR needs an ARB review, please create the ticket and add the ARB:pending label. Reach #api-review-board in case of doubts.
The fixture only exercises Pod entity synthesis, which already matches any kube_pod_* metric. It is not needed for the relationship rule. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
entityBot
left a comment
entityBot
left a comment
There was a problem hiding this comment.
We don't think these changes require an API Review Board (ARB) review, so it is not required to merge this PR. Note that all API changes do require one: if you believe this PR needs an ARB review, please create the ticket and add the ARB:pending label. Reach #api-review-board in case of doubts.
Add present: true conditions for k8s.namespace.name and k8s.cluster.name, which the target PVC GUID is built from, so the rule never builds a partial identifier. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
entityBot
left a comment
entityBot
left a comment
There was a problem hiding this comment.
We don't think these changes require an API Review Board (ARB) review, so it is not required to merge this PR. Note that all API changes do require one: if you believe this PR needs an ARB review, please create the ticket and add the ARB:pending label. Reach #api-review-board in case of doubts.
Relevant information
Adds the missing OpenTelemetry Pod → PersistentVolumeClaim relationship, as a staging-only override (
.stg.yml). Today only the Kubernetes Integration rule (keyed onK8sVolumeSample) exists, so OTel PVCs have no pod edge.New rule:
otelKsmK8sPodConsumesPersistentVolumeClaimkube_pod_spec_volumes_persistentvolumeclaims_info(pod-centric, one row per pod per PVC volume).extractGuidfromentity.guid.buildGuidfrom{k8s.cluster.name}:{k8s.namespace.name}:{k8s.pvc.name},FARM_HASH,account: lookup: true. This matches the PVC entity'scompositeIdentifierand the other OTel rules (e.g.otelKsmK8sPersistentVolumeManagesPersistentVolumeClaim).CONSUMES, same as the Kubernetes Integration rule, which is carried over unchanged.Verified on staging (account 10885357, cluster
otel-dev): the metric is emitted with the Podentity.guidon every row, and carriesk8s.cluster.name,k8s.namespace.name,k8s.pod.nameandk8s.pvc.name. A matching PVC entity exists for each pair, and e.g.working-pvccurrently has only the PV→PVC edge and no pod edge.Not yet verified: that the built PVC GUID resolves to the real PVC entity. I couldn't reproduce the hash offline. After this deploys to staging,
otel-dev:detector-tests:working-pvcshould gain aCONSUMESedge fromworking-pvc-pod.Not promoting to production: PR #3158 is held for performance concerns, and this adds one lookup per pod per PVC per scrape.
Api Review Board (ARB)
Staging-only relationship change; no entity type or identifier changes.
ARB Jira ticket:
https://new-relic.atlassian.net/browse/NR-XXXX
Checklist
identifierwill be unique and valid.🤖 Generated with Claude Code