ここLogicMonitorでは、独自のサービスを使用してインフラストラクチャのさまざまな部分を監視しています。これにより、LogicMonitorがもたらす経済的価値が実証されます。
LogicMonitorを使用して計測するほど、より強力になります。 以下のケースでは、LogicMonitorが提示した情報とアラートにより、より多くのハードウェアにお金をかけることを回避できました。LogicMonitorの可用性要件により、各ハードウェアの購入は通常、ハードウェアの3倍を意味します（問題のデータセンターでアクティブ/パッシブ、およびフェイルオーバーハードウェア別のデータセンターに存在します。）
XNUMXつのケースは比較的単純でした–レビュー MySQLパフォーマンスモニタリング メトリックは、read_rnd_next操作によって読み取られた行数が非常に多く、XNUMX秒あたり数万であることが明らかになりました。 （DBAでない方の場合、これは、読み取り要求を満たすためにMySQLが順次読み取る行数です。これはインデックスが使用されていないことを示します。）プログラマーによる簡単な調査により、このようなで記述されたクエリが明らかになりました。 MySQLが既存のインデックスを使用していなかった方法。 これは書き直され、私たちのリリースでは、MySQLテーブルスキャンが劇的に減少しました。
これにより、システムのCPU負荷、ディスク負荷が節約され、ユーザーの応答時間が改善されました。
ただし、XNUMX週間ほど後に、XNUMXつのクラスターがディスクにバインドされ始めたときに、より劇的なデモンストレーションが行われました。 顧客の増加と、追加の負荷を追加するいくつかの新しくリリースされた機能が組み合わさって、XNUMXつのクラスターがハードウェアの容量に達していることを意味しました（またはそう思っていました）。平均応答時間は、私たちが限界と見なしたものに達していました。問題にハードウェア（つまりお金）を投入する必要があります。
ただし、LogicMonitorシステムが公開するカスタムアプリケーションメトリックを使用する（この場合は JMXモニタリング、私たちのシステムはJavaで書かれていますが、データはperfmonカウンターから、Webページのコンテンツ、ログファイルまで、さまざまなメカニズムのいずれかによって収集された可能性があるため、負荷はXNUMXつの特定の原因のみによるものであることが明らかでした。処理キュー。 CTOは、このキュー内のデータに適用されるキャッシュアルゴリズムを調査し、以下のグラフからわかるように、はるかに効果的になるように調整することができました。
これにより、クラスターのCPU負荷が低下しました。
また、サーバーの応答時間も改善されました。
したがって、LogicMonitorは問題を直接解決しませんでしたが、 アプリケーション監視 問題が発生していることを警告し、システムのどこにボトルネックがあったかを特定し、スタッフがシステムのすべてのコンポーネントではなく、特定のXNUMXつのキューに調査を集中できるようにしました。 また、本番環境にリリースする前に、ステージングシステムの変更の有効性を確認することもできました。
LogicMonitorのアプリケーション監視により、数千ドルと何時間ものエンジニアリング時間を節約できました。 どちらの会社でも供給が限られています。