ホワイトペーパー
企業組織は、サイトの稼働時間を確保し、ビジネスを継続するために監視が必要であることを知っています。 それでも、多くのサイトは、顧客から最初に報告された停止に苦しんでいます。 これは多くの場合、監視システムで行われた小さな間違いが原因です。 これらの監視ミスは簡単に見落とされがちですが、結果は有害です。 最も一般的な監視ミスのいくつかと、LogicMonitorがそれらに対処する方法を次に示します。
このガイドの内容は次のとおりです。
- 最も一般的なXNUMXつの監視ミス
- 停止を防ぎ、暴風雨を警告するための最良の監視方法
- 監視のためのプロアクティブな戦略
ガイドをダウンロードする
以下に、このガイドの最初の XNUMX つの誤りを示します。 完全なガイドを読むには、上記のフォームに記入してダウンロードしてください。
間違い＃1：個人と人間主導のプロセスに依存する
私たちが何度も見た状況は、次のように少し流れます。
- それは危機の真っ只中です-あなたはスラッシュドットを得るのに十分幸運でしたか？
- データセンター機器に変更が加えられました。新しいボリュームがNetAppに追加され、Web層の高速ストレージとして機能できるようになりました。
- すばやく移動すると、NetAppモニタリングに新しいボリュームを追加するのを忘れます。
危機後、誰もがその新しいボリュームについて心配するのに安堵のため息をつくのに忙しすぎます。 IO操作が高いため、ゆっくりではありますが確実にいっぱいになるか、遅延が発生し始めます。 誰にも警告は出されず、顧客が最初に気づき、電話をかけ、不平を言います。 おそらく、CTOが次に電話をかけます。
人間の構成を可能な限り削除します。これは、人の時間を節約するだけでなく、監視、つまり監視対象のサービスの信頼性を大幅に向上させるためです。
ソリューションの機能を検討するときは、次のことを考慮してください。
- 監視対象のデバイスの変更を継続的に調べ、新しいボリューム、インターフェース、Dockerコンテナー、Kubernetesポッド、ロードバランサーVIP、データベース、およびその他の変更を監視に自動的に追加します。 次に、インスタントメッセージを介して、リアルタイムまたはバッチ通知で通知します。
- アラートの過負荷を回避するために、検出された変更のフィルタリングと分類を提供します。
- サブネット、さらにはハイパースケールクラウドアカウントをスキャンし、新しいマシンまたはインスタンスを監視に自動的に追加します。
- グラフを作成し、インテリジェントなダッシュボードを自発的に作成します。 サービスの状態を表示するために使用されるXNUMX台のWebサーバーでのセッションの合計に基づくダッシュボードグラフは、さらにXNUMX台のサーバーを追加すると自動的に更新されます。 この収集と表現の自動化により、ビジネス概要の継続性が保証されます。
追加、移動、および変更をカバーするために、手動の監視更新に依存しないでください。
間違い＃2：監視で再発を検出できない場合に解決された問題を検討する
適切な監視方法に従っている場合でも、停止が発生します。 ただし、監視によって根本原因が検出されるか、早期警告を提供するように変更されていることを確認しないと、問題は解決されません。
たとえば、多数のユーザーがシステムに過負荷をかけているためにサービスに影響を与える停止が発生しているJavaアプリケーションでは、ビジースレッドの数が増加している可能性があります。 この増加を監視するようにJMXモニタリングを変更します。 このメトリックでアラートしきい値を作成するか、動的しきい値をサポートする監視プラットフォームを使用すると、次回、事前警告を受け取ることができます。 早期警告は、少なくとも停止を回避するためのウィンドウを提供します。負荷を共有するために別のシステムを追加する時間、または負荷制限メカニズムをアクティブにする時間です。 ダウンタイムに応じてアラートを設定することで、次回は積極的に対応できます。 次に停止が発生した場合、根本原因が繰り返し防止可能なイベントを指していることはありません。
これは非常に重要な原則です。 サービスの復旧は最初のステップであり、問題を解決または却下する必要があるという意味ではありません。 監視ソリューションが問題の前に出した警告、および問題の間にトリガーされたアラートの種類とエスカレーションの内容に満足する必要があります。 問題は、事前に警告する方法がない場合（壊滅的なデバイス障害が発生する場合）ですが、この評価プロセスは、サービスに影響を与えるすべてのイベントに対して実行する必要があります。