Мне в RabbitMQ всегда казалось странным, что продюсеры и консьюмеры должны декларировать exchange, при этом указывая ее тип. То есть если мы внедряем мониторинг и меняем тип на fanout, то мы должны сделать исправления во всех консьюмерах и продюсерах, когда они декларируют эту exchange. Хотя они не должны знать, как она работает внутри. Это не критика вашей статьи, просто вещь, которая мне кажется странной.
Уже созданный эксчендж не будет пересоздан. Таком образом можно поменять тип эксченджа не меняя код. А то что указано в коде будет использоваться по умолчанию.
Ребят спасибо за комментарии, fanout был изначально в очереди хоть она и одна была — такой вот пример))) — статья подразумевает что нужно встроиться в то. что есть и тем более не претендует на то как нужно настраивать очереди
Кстати на тему мониторинга RabbitMQ я настраивал экспортер для него в prometheus а потом нескучные дашборды в grafana. Если этот стек используется, то мне кажется вполне подойдет.
Подскажите как сделать непрерывный цикл мониторинга сообщений.
А то я делаю channel.BasicQos(prefetchSize: 0, prefetchCount: 1, global: false);
while (true)
{
var consumer = new EventingBasicConsumer(channel);
consumer.Received += Consumer_Received;
channel.BasicConsume(queue: queueName,
autoAck: true,
consumer: consumer);
}
И через пару итераций у меня вылетает Already closed: The AMQP operation was interrupted: AMQP close-reason, initiated by Peer, code=406, text='PRECONDITION_FAILED — unknown delivery tag 1', classId=60, methodId=80
Мониторинг сообщений в RabbitMQ