最近、LogicMonitorの新しいリリースを公開しました。 ユーザーが目にした多くの改善と修正の中で、監視データを保存するLinuxシステムへのバックエンドの変更もいくつかありました。
ロールアウトはスムーズに進み、アラートはトリガーされませんでしたが、何かが変更されたことを確認するのは非常に簡単でした。
SSDドライブがビジー状態だった時間は劇的に増加しました。 ディスクへの物理的な書き込み操作（書き込み、下のグラフ）と物理的な読み取りの両方の量がほぼXNUMX倍になったため、その理由がわかります。 また、ソリッドステートディスクのアレイの場合でも、XNUMX秒あたりの操作量は多くなります。
ドライブの使用率が警告しきい値をわずかに下回っていたため、アラートはトリガーされませんでした。IO完了時間はそれよりも高速でしたが、それでも十分に高速でした（特に、アラートの対象である読み取りでは、書き込みはアプリによってバックグラウンドで非同期に実行されます） 、したがって、ユーザーエクスペリエンスに影響を与えないでください。ただし、読み取り時間は影響を与える可能性があります。）
したがって、ここでは差し迫った問題はありませんが、変更（より積極的なキャッシュ管理アルゴリズム）は、特定のハードウェアセットのスケーラビリティに明らかに影響します。 ですから、これからもう一度見ていきます。
しかし、私が引き出したいのは、定期的にグラフを目で確認する必要があるということです。 特にリリース後。 アラートがトリガーされなかったという事実は、すべてが順調であることを意味するわけではありません。それは、正しいことに関するアラートがないことを意味している可能性があります。 主要な指標（OS、アプリケーション、データベースの指標）をプロットしてダッシュボードを作成し、定期的にスキャンすると、異常を簡単に見つけることができます。 そして、それらに対処する方法を決定します。 （高レベル、データベース、ストレージなど、さまざまなクラスのシステムに焦点を当てて、いくつかのダッシュボードを作成します）
補足として：LogicMonitorに、そのようなメトリックを「目で確認」して「異常な」変更を探すことができる自動化された異常検出がないのはなぜですか？ まあ–それは難しいからです。 🙂実際、異常検出器を作成するのはそれほど難しいことではありません。難しいのは、ノイズから意味のある変化を分類して検出できるものを作成し、異常通知を送信しすぎることです。 これは私たちがまだ取り組んでいる分野です。