Imagine o seguinte: é segunda-feira de manhã. Seu site de comércio eletrônico está realizando uma “venda relâmpago de 48 horas”. Os pedidos estão chegando, os pagamentos estão sendo processados e sua equipe de suporte está excepcionalmente tranquila - uma coisa linda.

Então, de repente, o Slack explode.

• “O checkout está travado na rotação...”

• “As confirmações de pedidos não estão sendo enviadas.”

• “O inventário parece errado.”

• “Por que os reembolsos ficam na fila por horas?”

No início, tudo aparência saudável: A CPU está boa, seus servidores da Web estão funcionando e os gráficos do banco de dados não mostram nada de dramático. Mas o sistema ainda parece... congelado.

Após 45 minutos de combate ao fogo, você encontra o verdadeiro culpado: RabbitMQ. Algumas filas aumentaram, os consumidores ficaram mais lentos, as confirmações se acumularam e a memória atingiu o limite máximo. O RabbitMQ começou a aplicar o controle de fluxo, os editores começaram a atingir o tempo limite e sua lógica de negócios parou silenciosamente de mover mensagens por fluxos de trabalho críticos.

É exatamente por isso que Monitoramento do RabbitMQ não é opcional. Se o RabbitMQ é o “sistema circulatório” da sua arquitetura, o monitoramento é o monitor cardíaco que informa que algo está errado antes de o paciente entra em colapso.

(mais…)