source_* and destination_* labels show only unknown
- Dominant language
- Go
- Stars
- 3.2k
- Forks
- 304
- Avg merge
- 1d 19h
- Merged PRs (30d)
- 78
Description
**Describe the bug**
Each agent has metrics available under its `/metrics` endpoint but it lacks the proper labels. Beside `destination_ip` and `source_ip` all other labels have the value `unknown`.
Example snippet from a few series:
```
networkobservability_adv_tcpflags_count{destination_ip="",destination_namespace="unknown",destination_podname="unknown",destination_workload_kind="unknown",destination_workload_name="unknown",flag="PSH",source_ip="",source_namespace="unknown",source_podname="unknown",source_workload_kind="unknown",source_workload_name="unknown"} 72
networkobservability_adv_tcpflags_count{destination_ip="",destination_namespace="unknown",destination_podname="unknown",destination_workload_kind="unknown",destination_workload_name="unknown",flag="ACK",source_ip="",source_namespace="unknown",source_podname="unknown",source_workload_kind="unknown",source_workload_name="unknown"} 87
networkobservability_adv_tcpflags_count{destination_ip="",destination_namespace="unknown",destination_podname="unknown",destination_workload_kind="unknown",destination_workload_name="unknown",flag="FIN",source_ip="",source_namespace="unknown",source_podname="unknown",source_workload_kind="unknown",source_workload_name="unknown"} 6
networkobservability_adv_tcpflags_count{destination_ip="",destination_namespace="unknown",destination_podname="unknown",destination_workload_kind="unknown",destination_workload_name="unknown",flag="PSH",source_ip="",source_namespace="unknown",source_podname="unknown",source_workload_kind="unknown",source_workload_name="unknown"} 48
networkobservability_adv_tcpflags_count{destination_ip="",destination_namespace="unknown",destination_podname="unknown",destination_workload_kind="unknown",destination_workload_name="unknown",flag="SYN",source_ip="",source_namespace="unknown",source_podname="unknown",source_workload_kind="unknown",source_workload_name="unknown"} 6
```
**To Reproduce**
Steps to reproduce the behavior:
1. Install via helm as per (this guide)[https://retina.sh/docs/Installation/Setup#advanced-mode-with-remote-context-with-capture-support].
My helm values:
```
image:
tag: v0.0.26
os:
windows: false
linux: true
enabledPlugin_linux: '["dropreason","packetforward","linuxutil","packetparser"]'
enablePodLevel: true
enableAnnotations: true
remoteContext: true
operator:
tag: v0.0.26
enabled: true
enableRetinaEndpoint: true
```
**Expected behavior**
I expect to see source/destination namespaces and pod names.
**Screenshots**
**Platform (please complete the following information):**
- OS: AL2023
- Kubernetes Version: 1.31
- Host: EKS
- Retina Version: v0.0.26
**Additional context**
- cluster has a high pod churn, pods come and go at a high rate
- removing `remoteContext: true` from values is not generating any metrics
- removing `enableAnnotations: true` from values is not generating any metrics
- annotation `retina.sh: observe` seems to not do anything, but hard to verify at the current state
- cluster is IPv6 only
thanks!
Contributor guide
Research direction
Start by reproducing the issue through each agent's /metrics endpoint using the Helm values shown, especially remoteContext, enableAnnotations, and the packetparser plugin. Compare label output for IPv4 and IPv6 workloads under high pod churn, and verify whether source and destination namespace, pod name, and workload labels are populated. Done means the expected labels no longer remain unknown in the reported metrics.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- aws, helm, kubernetes, linux
- Domain
- networking, observability
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100