Sensu 通知の原因となっている環境の 1 つでマシンを見つけようとしています。通知に記載されているホスト名と IP アドレスはすべてめちゃくちゃです。これは、マシンが作成された時点で異なるデータがあったためです。つまり、間違ったデータがスタックし、マシンはまだ生きていて、キックしています...つまり、どこかからSensuサーバーに間違ったデータを送信しています.
マシンのアドレスを突き止めようとしました。tcpdump の助けを借りて、探しているのと同じ種類のパケットが 2 つの場所で発生していることがわかりました。
1) Sensu クライアントを実行しているすべてのマシンで、適切なペイロードを持つパケットが Sensu サーバー マシンに送信されているのを確認します。Sensu 構成ファイルは、Sensu が Sensu サーバーと同じマシンで RabbitMQ を使用していることを示しており、パケットはそのマシンに向かっています。
2) Sensu サーバーでは、ローカル 10 から着信するすべてのパケットを確認します。.* あらゆる種類の異なるポートからの IP アドレス。その IP アドレスを wget で調べたところ、Sensu ダッシュボードの index.html がゲーム化されたので、Sensu が使用しているため、ローカル アドレスは同じマシンのように見えました。
私たちの環境ではおそらく最大 100 台のマシンで Sensu クライアントが実行されていますが、着信トラフィックの接続や送信元 IP アドレスの数はそれほど多くありません。そのため、ブルート フォースですべてのマシンを 1 つずつシャットダウンし、別の通知がいつ表示されるかを確認する以外に、適切なソース マシンを見つける方法がわかりません。
追加情報: 当社のマシンはすべて AWS にあり、作成後に Puppet によってプロビジョニングされます。Sensu はベース AMI に組み込まれているため、Puppet がすぐに失敗した場合にアラートを受け取ることができます。ただし、パペットは失敗した時点で自分が誰であるかさえ知りませんでした.
編集: また、考えてみると、Sensu サーバーが、すべての Sensu クライアントがデータを送信する Route 53 エントリの背後にある Elastic Load Balancer の背後にあることが重要かもしれません。