You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
We suspect some of the traffic being captured and converted to events is the agent sending events to Honeycomb, eg libhoney sending events. Should the act of sending telemetry cause more telemetry to be generated?
Describe the solution you'd like
Have a way to filter out traffic generated directly by the agent.
Describe alternatives you've considered
We trialed a potential solution in the following PR that used the agent pod's IP in the bpf filter. However, because we use hostnetwork:true in our Kubernetes deployment, the agent's pod IP is the same as the node IP which leads us to filter out more traffic than intended. For example, node->pod health checks and any other service that uses hostnetwork:true.
Is your feature request related to a problem? Please describe.
We suspect some of the traffic being captured and converted to events is the agent sending events to Honeycomb, eg libhoney sending events. Should the act of sending telemetry cause more telemetry to be generated?
Describe the solution you'd like
Have a way to filter out traffic generated directly by the agent.
Describe alternatives you've considered
We trialed a potential solution in the following PR that used the agent pod's IP in the bpf filter. However, because we use
hostnetwork:true
in our Kubernetes deployment, the agent's pod IP is the same as the node IP which leads us to filter out more traffic than intended. For example, node->pod health checks and any other service that useshostnetwork:true
.Additional context
The text was updated successfully, but these errors were encountered: