Привет! Вопрос безотносительно языка программирования по кролиководству - как вы

выходите из ситуации с блокировкой соединений по watermark (RAM/диск) ? На официальном сайте написано что блокируются publish-еры. Но и consumer-ы также не могут переполненную очередь разгрести. В одном из cообщений в maillist 10+летней давности писали, что разделить connetion 'паблишера' или 'консумера' - невозможно (ссылаясь на 'ограничения/специфику' AMQP протокола) со стороны сервера - поэтому RMQ превращается в тыкву по всем параметрам.

Сразу скажу - у меня имеется понимание о необходимости заблаговременных алертах, коротких очередях + партиционировании, достаточном количестве шустрых консумеров, consume вместо get.. (и прочих best practices по RMQ), но мой вопрос - что можно (и можно ли) сделать, если очереди до watermark насыщаются крайне быстро ( 64 GB RAM одной ноды при определенных обстоятельствах заваливаем за 10 минут и алерты мало помогают).

Вообще, блокировка publish-еров это хорошо, но то что консумеры уже не способны обработать очередь при watermark и лочатся также как publish-еры - это больно - приходится 'будить' в себе админа и в CLI дропать врукопашную все.

Напрашивается какой-то сигнальный канал или опрос publish-еров состояния кроликов, чтобы искусственно самим до наступления watermark заблокироваться. Но может это велосипед, если существуют изящнее решения?

я поэтому и написал что понимание есть (да, в моем случае проблема архитектуры), но ввиду опеределнных нетехнических сложностей, она изменится не быстро. Вот и интересно кто как решает. Кроме того, даже в идеальной архитектуре уместно подстраховаться на этот случай.

Ну решается прометеем и алертами с запасом до наступления вотерморка

хех, знакомо. (про пол года бюрократии) и не понял - вы логи железок разгребаете через реббит?

да, почти. inventory оборудования, где размер message может быть от пары килобайт до 5 метров.