Проверьте версию в RabbitMQ
Как я могу проверить, какая версия rabbitmq работает на сервере?
есть ли команда, чтобы проверить, что rabbitmq работает?
11 ответов:
и искать строку, которая выглядит так:
вы можете просто выполнить из commandilne:
sudo rabbitmqctl status / grep rabbit
Если rabbitimq не может запуститься, я нашел единственный способ определить версию через систему установки.
как Марек сказал, что на локальном сервере или на удаленном сервере (используя amqplib):
Сохранить как checkVersion.py и запускать с python checkVersion.py dev.rabbitmq.com :
поскольку я хотел сделать это в C# на машине Windows, и все текущие ответы предназначены для *nix, я опубликую код, который я использовал:
чтобы получить версию RMQ с помощью C#
в вероятном случае, если вы используете плагин «управление» (web), версия RabbitMQ появляется в правом верхнем углу каждой веб-страницы вместе с версией времени выполнения Erlang.
войдите в пользовательский интерфейс управления и в правом верхнем углу вы можете найти версию. Также используйте следующую команду, чтобы найти версию
# rabbitmqctl status | grep rabbit
в системах debian вы можете просто запустить:
Я использую следующую команду, чтобы обрезать вывод до версии
Если у вас нет доступа к rabbitmqctl или rabbitmq-сервер не работает, на linux do:
RabbitMQ: Verify version of rabbitmq
How can I verify which version of rabbitmq is running on a server?
Is there a command to verify that rabbitmq is running?
11 Answers 11
and look for line that looks like that:
You can simply execute from the command line:
If rabbitimq can not start I found the only way to determine version is via installer system.
As Marek said on a local server, or, on a remote server (using amqplib):
Save as checkVersion.py and run with python checkVersion.py dev.rabbitmq.com :
If you have no access to rabbitmqctl or rabbitmq-server is not running, on linux do :
On debian systems, you can just run:
Since I was looking to do this in C# on a Windows machine and all the current answers are for *nix, I’ll post the code that I ended up using:
In the likely event you’re using the «management» (web) plug-in, the RabbitMQ version appears in the upper-right corner of every web page, along with the version of the Erlang run-time.
To get RMQ version using C#
I use following command to trim output down to version,
Output:
Login to management ui and in top right you can find the version. Also use the following command to find the version
# rabbitmqctl status | grep rabbit
Not the answer you’re looking for? Browse other questions tagged rabbitmq or ask your own question.
Linked
Related
Hot Network Questions
Subscribe to RSS
To subscribe to this RSS feed, copy and paste this URL into your RSS reader.
site design / logo © 2021 Stack Exchange Inc; user contributions licensed under cc by-sa. rev 2021.9.14.40215
By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.
Release Series
Overview
This guide explains what release series of RabbitMQ are currently covered by general or extended support policies, which release series is coming next, and what series are no longer supported.
For guidance on upgrades, see the Upgrade and Blue/Green Deployment Upgrade guides.
Currently Supported Release Series
| Version | Latest Patch | First Release | End of General Support 1 | End of Extended Support 2 | In service for |
|---|---|---|---|---|---|
| 3.9 | 3.9.5 | 26 July 2021 | |||
| 3.8 | 3.8.22 | 1 October 2019 | 31 January 2022 |
1 General Support means patch releases that are produced regularly based on feedback from all users.
2 Extended Support means security patches and high-severity issues reported by users with a commercial license.
Next Release Series
As of 26 July 2021, the next release series has not been announced yet.
Release Series That are Out of Support
| Version | Final Patch | First Release | End of Life | In service for |
|---|---|---|---|---|
| 3.7 | 3.7.28 | 28 November 2017 | 30 September 2020 | 34 months |
| 3.6 | 3.6.16 | 22 December 2015 | 31 May 2018 | 29 months |
| 3.5 | 3.5.8 | 11 March 2015 | 31 October 2016 | 20 months |
| 3.4 | 3.4.4 | 21 October 2014 | 31 October 2015 | 12 months |
| 3.3 | 3.3.5 | 2 April 2014 | 31 March 2015 | 12 months |
| 3.2 | 3.2.4 | 23 October 2013 | 31 October 2014 | 12 months |
| 3.1 | 3.1.5 | 1 May 2013 | 30 April 2014 | 12 months |
| 3.0 | 3.0.4 | 19 November 2012 | 30 November 2013 | 12 months |
To learn more about individual releases, please see the change log.
Versions prior to v3.x
RabbitMQ v2.0.0 was released on 24 August 2010.
It reached end of life on 31 December 2012 as v2.8.7.
RabbitMQ v1.0.0 was released on 1 July 2007.
It reached end of life on 31 December 2010 as v1.8.1.
Getting Help and Providing Feedback
If you have questions about the contents of this guide or any other topic related to RabbitMQ, don’t hesitate to ask them on the RabbitMQ mailing list.
Help Us Improve the Docs <3
If you’d like to contribute an improvement to the site, its source is available on GitHub. Simply fork the repository and submit a pull request. Thank you!
RabbitMQ tutorial 1 — Hello World
RabbitMQ позволяет взаимодействовать различным программам при помощи протокола AMQP. RabbitMQ является отличным решением для построения SOA (сервис-ориентированной архитектуры) и распределением отложенных ресурсоемких задач.
Под катом перевод первого из шести уроков официального сайта. Примеры на python, но его знание вовсе не обязательно. Аналогичные примеру программы можно воспроизвести практически на любом популярном ЯП. [так выглядят комментарии переводчика, т.е. меня]
Вступление
RabbitMQ ‒ это брокер сообщений. Его основная цель ‒ принимать и отдавать сообщения. Его можно представлять себе, как почтовое отделение: когда Вы бросаете письмо в ящик, Вы можете быть уверены, что рано или поздно почтальон доставит его адресату [видимо, автор ни разу не имел дела с Почтой России]. В этой аналогии RabbitMQ является одновременно и почтовым ящиком, и почтовым отделением, и почтальоном.
Наибольшее отличие RabbitMQ от почтового отделения в том, что он не имеет дела с бумажными конвертами ‒ RabbitMQ принимает, хранит и отдает бинарные данные ‒ сообщения.
В RabbitMQ, а также обмене сообщениями в целом, используется следующая терминология:
Поставщик, подписчик и брокер не обязаны находиться на одной физической машине, обычно они находятся на разных.
Hello World!
Первый пример не будет особо сложным ‒ давайте просто отправим сообщение, примем его и выведем на экран. Для этого нам потребуется две программы: одна будет отправлять сообщения, другая ‒ принимать и выводить их на экран.
Общая схема такова:
Поставщик отправляет сообщения в очередь с именем «hello», а подписчик получает сообщения из этой очереди.
Библиотека RabbitMQ
RabbitMQ использует протокол AMQP. Для использования RabbitMQ необходима библиотека, поддерживающая этот протокол. Такие библиотеки можно найти практически для каждого языка программирования. Python ‒ не исключение, для него есть несколько библиотек:
Отправка сообщений
Наша первая программа send.py будет просто отправлять одно сообщение в очередь.
Мы подключились к брокеру сообщений, находящемуся на локальном хосте. Для подключения к брокеру, находящемуся на другой машине, достаточно заменить «localhost» на IP адрес этой машины.
Перед отправкой сообщения мы должны убедиться, что очередь, получающая сообщение, существует. Если отправить сообщение в несуществующую очередь, RabbitMQ его проигнорирует. Давайте создадим очередь, в которую будет отправлено сообщение, назовем ее «hello»:
Теперь все готово для отправки сообщения. Наше первое сообщение будет содержать строку и будет отправлено в очередь с именем «hello».
Вообще, в RabbitMQ сообщения не отправляются непосредственно в очередь, они должны пройти через exchange (точка обмена). Но сейчас мы не будем заострять на этом внимание, точки обмена будут рассмотрены в третьем уроке. Сейчас достаточно знать, что точку обмена по-умолчанию можно определить, указав пустую строку. Это специальная точка обмена ‒ она позволяет определять, в какую именно очередь отправлено сообщение. Имя очереди должно быть определено в параметре routing_key:
Перед выходом из программы необходимо убедиться, что буфер был очищен и сообщение дошло до RabbitMQ. В этом можно быть уверенным, если использовать безопасное закрытие соединения с брокером.
Получение сообщений
Наша вторая программа receive.py будет получать сообщения из очереди и выводить их на экран.
Также как и в первой программе сначала необходимо подключиться к RabbitMQ. Для этого следует использовать тот же код, как и ранее. Следующий шаг, как и прежде ‒ убедиться, что очередь существует. Команда queue_declare не будет создавать новую очередь, если она уже существует, поэтому сколько бы раз не была вызвана эта команда, все-равно будет создана только одна очередь.
Вы можете задаться вопросом, почему мы объявляем очередь снова, ведь она уже была объявлена в первой программе. Это нужно, чтобы быть уверенным в существовании очереди, так будет, если сначала будет запущена программа send.py. Но мы не знаем, какая программа будет запущена раньше. В таких случаях лучше объявить очередь в обеих программах.
Мониторинг очередей
Если Вы хотите посмотреть, какие очереди существуют в RabbitMQ на данный момент, Вы можете сделать это с помощью команды rabbitmqctl (потребуются права суперпользователя):
(для Windows ‒ без sudo)
[в нашей компании используют более удобный скрипт мониторинга:]
[скрипт выводит и обновляет каждые 2 секунды таблицу со списком очередей: имя очереди; количество сообщений в обработке; количество сообщений готовых к обработке; общее количество сообщений; устойчивость очереди к перезагрузке сервиса; является ли временной очередью; количество подписчиков]
Получение сообщений из очереди более сложный процесс, чем отправка. Получение осуществляется при помощи подписки с использованием callback функции. При получении каждого сообщения библиотека Pika вызывает эту callback функцию. В нашем примере она будет выводить на экран текст сообщения.
Далее, нам нужно обозначить, что callback функция будет получать сообщения из очереди с именем «hello»:
Здесь необходимо быть уверенным в том, что очередь, на которую мы хотим подписаться, была объявлена. Мы сделали это ранее с помощью команды queue_declare.
Параметр no_ack будет рассмотрен позже [во втором уроке].
И, наконец, запуск бесконечного процесса, который ожидает сообщения из очереди и вызывает callback функцию, когда это необходимо.
Ну а теперь все вместе
Полный код receive.py:
Теперь мы можем попробовать запустить наши программы в терминале. Сначала отправим сообщение при помощи программы send.py:
Выполнение этой программы будет завершаться после отправки каждого сообщения. Теперь сообщение нужно получить:
Отлично! Мы отправили наше первое сообщение через RabbitMQ. Как Вы могли заметить, выполнение программы receive.py не завершилось. Она будет ожидать следующих сообщений, а остановить ее можно, нажав Ctrl+C.
Попробуйте запустить send.py снова в новом окне терминала.
Мы изучили, как отправлять и получать сообщения через именованные очереди. В следующем уроке мы создадим простую очередь задач [ресурсоемких].
UPD: библиотеку, работающую с RabbitMQ, для своего любимого ЯП Вы можете найти на официальном сайте тут.
Мониторинг сообщений в RabbitMQ
Рассмотрим классическую схему построения конвейера сообщений в RabbitMQ состоящую из элементов Producer, Exchange, Queue и Consumer.
Задача состоит в том, что бы организовать мониторинг происходящего в очереди и не затронуть основное программное обеспечение (ПО), добавить гибкую возможность построения отчетов и при этом избежать дополнительных затрат. Итоговая конструкция должна позволять быстро строить отчеты для анализа потока данных на конвейере без использования основных мощностей серверов (что позволит избежать дополнительной нагрузки) и основного ПО. Подход должен быть легко переносимым на более сложную архитектуру.
Прежде всего организуем демонстрационный стенд, для этого внесем следующие изменения в работу конвейера:
Изначально для Exchange (faust) была задана следующая конфигурация, которая не меняется в рассматриваем примере при модификации:
Важным является настройка типа fanaut — которая позволяет создать две равноправные очереди и дублировать весь поток сообщений в новую очередь Statistics:
без какого бы то ни-было вмешательства в основной процесс в очереди Logs. Приступим к обработке потока сообщений. Прежде всего создаем таблицу на MS SQL сервере для хранения статистической информации. Вы можете использовать любой другой подход, например, сохранить сообщения в файл в xml формате или любой другой способ, в рассматриваемом примере выбран SQL сервер для того чтобы избежать дополнительного программирования
Как видно из SQL запроса это таблица с номером записи, некоторым текстом и датой вставки записи в таблицу.
Создадим клиента, который будет обращаться к RabbitMQ в очередь Statistics, забирать полученные данные и перекладывать их в таблицу RabbitMsg
Посмотрим, как это работает в режиме реального времени
