RabbitMQがダウンしたときにSensuが通知しない
APIとサーバーを1つのインスタンスで実行し、RabbitMQを別のインスタンスで実行するようにSensuをセットアップしました。これは私たちにとって非常にうまく機能しています。ただし、サーバーまたはAPIがRabbitMQへの接続を失った場合、Sensuサーバーは通知を送信しません。このシナリオでは、サーバーがクライアントごとにNo keep-alive sent from client in over 120 seconds通知を送信することを期待します。現在のセットアップでは、RabbitMQが失敗した場合（またはRabbitMQへの接続が失敗した場合）、すべての監視がサイレントに失敗します。
サーバーまたはAPIがトランスポート（RabbitMQ）への接続の緩みを処理するときに通知を送信するようにSensuを構成するにはどうすればよいですか？一般に、監視ソフトウェアを監視するためのベストプラクティスは何ですか？
同様のセットアップがあり、1つのクラスター層にSensuサーバー、API、およびUchiwaがあり、RabbitMQノードのクラスターがあり、Redisのマスター/スレーブセットアップがあります。
私の理解では、すべてのクライアントメッセージは処理のためにキューに入れられます。キューが使用できない場合、サーバープロセスはキューに到達できず、クライアントプロセスがキューに到達できないことを確認できません。
私が解決した方法（会社と環境のプロパティにとって意味があります）は、環境ごとに1つずつ、複数のSensuクラスターを用意することです。各クラスターは、他のRedisクラスターの主要な可用性ポイントを監視します。反対側のクラスターのコンポーネントロードバランサーエンドポイント。
これを解決するもう1つの方法は、サーバープロセスが認識し、SensuサーバーのSensuクライアントが通信するSensuサーバーインスタンスに小さなRabbitMQインスタンスをインストールすることです。 （これは、Sensuサーバーが複数のキューを監視できるかどうかに依存します。）
私たちの監視システムが少なくとも監視しているものと同じくらい利用可能であるという合理的な保証を私たちに提供するので、私は私たちが持っているセットアップに満足しています。複数のクラスターをスピンアップする能力がある場合は、絶対にお勧めします。 （使用する監視製品に関係なく、これをお勧めします。）そうでない場合でも、エンジニアリングの時間がある場合は、追加のローカルRabbitMQが可能かどうかを調査することをお勧めします。