ボストンのデータセンターから（通常は）収容されているお客様が知っているように、東海岸から西海岸のデータセンターへのフェイルオーバーを実行する必要がありました。 （なぜですか？短いバージョン–コロケーションプロバイダーの下請け業者がサーバーの間違ったラックを移動しました。）
そのため、フェイルオーバーに自信がありました。他のデータセンターでは同じサーバーがアイドル状態で、引き継ぐのを待っているだけで、プロセスをテストしたので、問題は発生しませんでした。 フェイルオーバーは順調に進み、イベントからXNUMX時間以内にすべてのお客様が問題なく稼働していました。 しかし..問題がありました。 一部の顧客は、UIが断続的な「アクセス拒否」エラーを報告したと不満を漏らしました。
LogicMonitorからアラートトリガーを受信していませんでしたが、Javaアプリケーションサーバー内から例外に関する電子メールを受信していました。
また、少し調べてみると、Tomcatによるデータベース接続の監視に明確なスパイクが見られました。
スレッド使用のMySqlモニタリングのスパイクによってミラーリングされます：
したがって、明らかに何かがDBの速度を低下させ、制限に達するまでスレッドに一時的なスパイクを引き起こしていました（この場合、通常は非常に少なくなるため、デフォルトの100であるため、増やす必要はありません）。スパイクの周期性にあります–それらはサーバー間でデータを複製するバッチジョブと一致しました。
ボストンを引き継いだLAのサーバーは、アクティブなLAサーバーのレプリカを取得するサーバーでもありました。 これが問題になるとはまったく考えていませんでした。レプリケーションはSASドライブで行われ、顧客のデータストレージはSSD（ソリッドステートディスク）ドライブ上にありました。MySQLインスタンスには十分なメモリがあり、innodbが実質的にディスクにアクセスする必要はありません。
しかし、明らかにそれは重要でした。 定期的な仕事との相関関係が近すぎました。 そこで、MysqlデータベースもSSDに移動しましたが、問題は解決しました。
それで、レッスン？
システムが実稼働負荷で動作するかどうかをテストできるのは、実稼働負荷以外はありません。 ただし、問題が発生した場合は、適切な監視が必要です。アラートがトリガーされなくても、グラフは問題をすばやく特定するのに役立ちます。 そしてもちろん、監視が再発を警告しない場合、問題はクローズされたとは見なされないという慣行に従って、次回この状況を警告するように監視を調整しました。