-
Notifications
You must be signed in to change notification settings - Fork 450
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
AMQP traffic not reliably showing in UI #1443
Comments
In case it's useful, the worker always starts up with a failure in
|
It's still not what I'm expecting, but things do seem to show up more reliably if I put kubeshark in its own namespace on install. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
With v51.0.0 kubeshark installed, I'm seeing next to no traffic reported over AMQP. The reports are very intermittent and usually attributed to the wrong source or destination. As a quick demo, I have two services publishing to rabbitmq and one service subscribed. The service subscribed is showing that there are around 10 messages per second being received. The UI rarely shows anything. When it does show things, it's typically a
basic deliver
method. These typically show up as going between "kubernetes" and "kubernetes". Even more rarely I see abasic publish
method that is attributed to the proper source and destination.Provide more information
minikube
To Reproduce
Set up helm chart values
Install helm chart
Add minikube ingress controller
Navigate to front end in web browser at
http://ks.svc.cluster.local/
Observe little to no AMQP traffic
Expected behavior
One
basic publish
method in the UI per message produced by publishers. Onebasic deliver
method in UI per message received by subscriber.Logs
Worker logs typically show this
Hub logs
Screenshots
N/A
Desktop (please complete the following information):
Additional context
Resource utilization of the worker looked stable
I have tried turning off other applications at the same time to free up system resources. I have also tried adjusting the
tap.regex
setting in the chart to reduce the number of pods we're capturing traffic for to just those of interest.The text was updated successfully, but these errors were encountered: