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
aliveness-test does still work when memory high watermark is reached and publishing is blocked #23
Comments
Publishers are blocked on per-connection basis. Since aliveness test cannot use your apps connection, it cannot know that they are blocked. A new monitoring endpoint may be worth adding but aliveness-test cannot provide information for your connections, |
"when I put my queue into a state where it will not allow publishing new items" this is not a correct statement. Connections can be in that (blocked) state but not queues. |
There are already HTTP API endpoints for connection info. If you'd like something to be added there, please start a discussion on rabbitmq-discuss. |
Thanks for the clarification, got the point it is of course not my apps connection and it can't know the app is blocked for publishing.
Tells me as a user, that no publisher should be able to publish anything onto this RabbitMQ host, doesn't it? So the aliveness-test should not be able to do that as well? Anyway - as a user tagged for monitoring, is there any way I can get the information, that RabbitMQ is in the alarm state where publishers will possibly be blocked? |
Aliveness test is part of a RabbitMQ plugin which can do/use things AMQP 0-9-1 clients cannot:
and so on. Aliveness test is mean to test key broker infrastructure and not every possible failure scenario. I need to take a look if management API can provide any information about alarms. Will get back to you. |
As a user I agree with @LarsFronius that the aliveness check should fail when publishing is blocked by the watermarks being exceeded. That the aliveness check passes when the queue cannot process messages is both surprising and disappointing. |
@CVTJNII only specific connections are blocked, so your claim that "the queue cannot process messages" is factually untrue even when alarms are in place. Like I said, we are VERY far from having a consensus about how the aliveness test should work. Everybody wants it to work the way their company's monitoring work. Sorry, we cannot accommodate all requests. |
@michaelklishin I respectfully disagree. Per Rabbit's output when the watermark is breached:
Per the API documentation at http://hg.rabbitmq.com/rabbitmq-management/raw-file/rabbitmq_v3_3_4/priv/www/api/index.html:
So per the check's documentation it should publish and consume a message. However, per Rabbit's log in this scenario publishers are blocked. So I disagree that this is ambiguity in how the check should work, in my opinion the check is not operating as documented. That is the spirit of my objection, based on the documentation I've found I would not expect a 200 response when publishers are blocked. Furthermore, when I hit this issue I had the watermark set to zero, and per the memory documentation at https://www.rabbitmq.com/memory.html I would expect all publishing to be stopped as per the log message above:
If there is better documentation for the API please let me know, that was the best I found and aligned with other searches for how the endpoint should function. So again, I disagree with the assertion that this is an issue with consensus on how the check should operate, and instead believe the check is not operating as documented. As the check is supposed to publish and then consume a message it should not pass when publishing is disabled. |
@CVTJNII publishers are blocked after they publish at least one message, which can (although not guaranteed and typically won't) be accepted fully, e.g. if it has a blank body. How would RabbitMQ know that a connection is publishing otherwise? The aliveness check uses a regular RabbitMQ client and the only thing that could be missing is a timeout — which again, everybody has their own ideal default for. So instead of assuming that the aliveness test should cover everything, please stop suggesting that we make it do A, B, C, …, X, Y, Z. Use multiple monitoring checks, the HTTP API provides a ton of data, and so does |
I'm locking this because this is getting ridiculous. I cannot think of a data service where a single request can discover every possible issue there might be (given that definitions of "healthy" varies from company to company, or even project to project). Yet somehow RabbitMQ is expected to provide it. |
Filed rabbitmq/rabbitmq-management#137 for one specific improvement we can make. |
@CVTJNII furthermore, you assume that when a publish method returns, the message is published. That's wrong: it simply means that the data was written to the socket. It absolutely does not meant that it has reached RabbitMQ, was read, parsed, and routed. When alarms are in place, connections that see a |
Hi,
from the docs it seems if I call /api/aliveness-test I can be 100% sure my apps are able to publish and consume messages from my MQ.
So, when I put my queue into a state where it will not allow publishing new items, for instance through setting
rabbitmqctl set_vm_memory_high_watermark 0.01
and I can see
Publishers will be blocked until this alarm clear
in the logs and my application can't actually publish new messages, I'd consider the aliveness-test to tell me that.What I actually see is
This is not correct, considering this API call should really "publish and consume a message. Intended for use by monitoring tools."
This is what I run at the moment
The text was updated successfully, but these errors were encountered: