これについては前に話しましたが、理由についての記事を読んだだけです アプリケーションのパフォーマンス監視は非常に面倒です、そして偶然にも、スケーラブルコンピューティングに関するUCSBの大学院クラスに行った講義でそれについて話していたので、言及する価値があると考えました。
この記事では、「企業は、アプリケーションが使用するリソースをそのパフォーマンスで監視するという概念を（ベンダーの助けを借りて）混乱させてきました」と述べています。 私が講義でそれを置いた方法はそれでした：
- システムは、ディスクIO、メモリ、そしてあまり一般的ではないCPUとネットワークによって制限されます。
- ユーザーはディスク/メモリ/ CPU /ネットワークを気にしません…彼らはウェブページと速度を気にします。
それで…どのように一方を他方に結びつけるのですか？
両方を監視します。
ユーザーが気にかけていること（ページの読み込み時間、リクエストごとの応答など）を監視します
また、すべての制限リソース（CPU、ディスクIO、さらに重要なことに、ドライブがビジー状態の時間の何パーセント、ネットワーク、メモリ）を監視します。
そして、限られたリソースに影響を与えるシステムのパフォーマンスを監視します。
したがって、InnoDBファイルシステムの読み取りを監視しても、エンドユーザーが気にすることは何もわかりませんが、Tomcat要求時間の監視でユーザーのパフォーマンスが低下していることが示され、論理ドライブが突然100％ビジーになり、要求サービス時間が増加している場合は、その理由を知っておくとよいでしょう。 InnoDBバッファーの欠落が原因であるか、他の原因である可能性がありますが、この中間データがあると、ユーザーが気にする問題を修正するための応答時間が大幅に短縮されます。
注意すべきもうXNUMXつのポイント：「ユーザーが気にかけていることを監視する」というフレーズの「ユーザー」は人間ではない可能性があります。 サーバーがサーバーの場合–このサーバーのユーザーはWebサーバーであり、memcachedの応答時間、可用性、およびヒット率を考慮します。 したがって、このクラスのマシンでは、サービスがユーザーのニーズを満たしているかどうかを判断するために監視する必要があります。
つまり、すべてのマシンについて、そのマシンの「気になるもの」を特定します。 それらを監視します。 制約されたリソースを監視します。 制約されたリソースに影響を与えるそのサーバー上のシステムのすべての側面を監視します。