Closed slzcc closed 5 years ago
Thank you for your time.
Team RabbitMQ uses GitHub issues for specific actionable items engineers can work on. GitHub issues are not used for questions, investigations, root cause analysis, discussions of potential issues, etc (as defined by this team).
We get at least a dozen of questions through various venues every single day, often light on details. At that rate GitHub issues can very quickly turn into a something impossible to navigate and make sense of even for our team. Because GitHub is a tool our team uses heavily nearly every day, the signal/noise ratio of issues is something we care about a lot.
Please post this to rabbitmq-users.
Thank you.
This plugin only supports 3.8.x
at the moment and a backport to 3.7.x
is under consideration but not guaranteed.
RabbitMQ 3.6.x has been out of support for almost 18 months now. 3.6.1
specifically is 3.5 years old. Sorry but you have to upgrade. 3.7 goes out of support in March 2020.
I'll try the other method. Thank you.
This 3rd party exporter has a version that supports 3.6 but you won't be able to use some of our Grafana dashboards with it.
I currently have tested this method, but it is based on the management api, but our production environment requirements are not open to the management plugin, because it might at some point occur a lot of memory usage issues, currently don't know what the problem caused, the current node memory is 128+that. I am currently unclear how management of Troubleshooting, because it is in my company before it has been closed.
There is a doc guide for that. What you are looking it is a single node collecting all the stats, something that was addressed in 3.6.7
. 3.6.1
is 15 patches behind even in the out-of-support 3.6.1
version.
Are investigation whether there is a known issue. Thanks!
A Blue/Green Deployment upgrade to 3.8.1
(when it is out which should be very soon) sounds like the most pragmatic approach.
@slzcc I'm not sure I understand your comment but see release notes for 3.6.7
. Statistics DB memory consumption has been effectively a solved problem since then (assuming connections and queues are reasonably evenly distributed between nodes). The only workaround for pre-3.6.7
(other than upgrading) is to bump the statistics collection interval to 60 seconds or higher (if necessary).
There's also a pretty extensive guide on monitoring which compares this plugin to the management one in Management UI and External Monitoring Systems
The team did not want to use the upgrade version of the method to solve this problem, because there is no so much energy to do this thing, is to use the most simple solution is by writing a service exposed some of the indicators to solve the problem, so that the current service without any perception. May then over a period of time before upgrading to 3.8. x releases, but also through the many environmental checks before they can upgrade. Thanks!
Currently don't want to by the upgrade version to solve the plug-in support, what better way? I have put the plugins copy the contents to the old version but not properly installed.