データセンターの開発者であるLogicMonitorはできますか サーバー監視、あらゆる方法ですべてを監視している場合、検出されていない顧客が問題に影響を与えていますか？ はい。 技術チームが気付く前に、一部の試用版のお客様から報告された問題が発生しました。 さらに悪いことに、技術者が問題に対処したと考えた後も、顧客は依然として影響を受けていました。 どうやって？
この場合、問題は、一部の顧客にとって、UIのパフォーマンスが低下し、ページのレンダリングに数十秒かかることでした。 それでも紛らわしいことに、UIが同じサーバーによって提供され、同じMySQLサーバーにアクセスしていた他の顧客は、応答時間が長かった。 （影響を受けたアカウントには多くの謝罪があります。）
私たちの監視では、CPU負荷、アプリケーション固有の統計、クエリキャッシュの使用状況に関するMySQL統計、トランザクション数、完全なテーブル結合など、すべて正常に見えました。 リクエストごとのTomcatの応答時間でさえ、サーバーにとっては素晴らしく高速なままでした。
では、何が起こっていたのでしょうか。
かなり掘り下げてみると、一部のアカウントのMySQLで同じクエリを実行するのに50秒かかったことがわかりました。 他のアカウント（同じMySQLエンジン上の異なるMySQLデータベース）でのまったく同じクエリは、ほんの数ミリ秒しかかかりませんでした。 まったく同じスキーマ。 ただし、高速データベースとは異なるクエリプランが低速データベースに対して生成されました。 まったく同じクエリ、まったく同じスキーマ、桁違いに異なるパフォーマンス。 （そして、遅いクエリプランは、正しいクエリプランのデータベースと比較して、非常に小さいデータベースと大きいデータベースの両方に対して生成されたため、オプティマイザが時々間違っていた理由がわかりません。）これで修正できますMySQLがクエリを誤って最適化していたという事実（正しい最適化を強制するためにSTRAIGHT_JOINに切り替えており、テストではMySQL 5.6に問題がないことが示されています）–しかし、これが再発しないようにするにはどうすればよいですか？ （結局のところ、私たちはトップの監視ミスのXNUMXつを犯したくありません…。）
この問題は少数のアカウントにのみ影響を及ぼしたため、平均的なデータベース、Tomcat、およびその他の集約されたメトリックはほとんど影響を受けませんでした。 したがって、それらを監視することは役に立ちませんでした。 （注：Tomcat、MySQLなどが、平均だけでなく、応答時間やその他の統計の分布を追跡していたら、その分布を監視することで警告が表示された可能性があります。）
しかし、MySQLには遅いクエリログがあります。 一部のサーバーではこれを有効にしていますが、コードの改善や問題が特定された後のトラブルシューティングに役立つ最適化およびトラブルシューティングツールと見なされています。 しかし– MySQLがクエリを完了するのに数秒かかるときはいつでも、それは私たちの顧客のXNUMX人に影響を与えるでしょう。 全体として、応答時間は速いですが、一部の顧客のパフォーマンスが低い場合は、それを知って警告する必要があります。
その結果、Tech Opsチームは現在、LogicMonitorによる低速クエリログのアクティブな監視をすべての本番MySQLインスタンスに展開しており、クエリログに指定されたしきい値を超えるクエリが含まれている場合はいつでもアラートを出します。
レッスン？ できる限り監視しますが、それでも十分に検出できない問題が発生する可能性があります。 このような問題が発生した場合は、監視を調整して警告を発し、再発しないようにしてください。 ことわざを言い換えると、次のようになります。 検出されない問題をXNUMX回ください-恥ずかしいです。」