あなたの組織がやっているかもしれないインフラ監視の間違い5つ

あなたの組織がやっているかもしれないインフラ監視の間違い5つ

ほとんどの組織は、サイトの稼働時間を確保し、ビジネスを継続するために監視が必要であることを知っています。 それでも、多くのサイトは、監視システムの小さなミスが原因で、顧客から最初に報告された停止に苦しんでいます。 監視の間違いは簡単に犯し、見落としがちですが、その結果は有害な場合があります。 ここに最も一般的なもののいくつかがあります モニタリング 間違いとそれらに対処する方法。

間違い#1:個人と人間主導のプロセスに依存する

私たちが何度も見た状況は、次のように少し流れます。 

  • それは危機の真っ只中です-あなたはスラッシュドットを得るのに十分幸運でしたか? 
  • データセンター機器に変更が加えられました。新しいボリュームがNetAppに追加され、Web層の高速ストレージとして機能できるようになりました。 
  • すばやく移動すると、NetAppモニタリングに新しいボリュームを追加するのを忘れます。

危機後、誰もがその新しいボリュームについて心配するのに安堵のため息をつくのに忙しすぎます。 IO操作が高いため、ゆっくりではありますが確実にいっぱいになるか、遅延が発生し始めます。 誰にも警告は出されず、顧客が最初に気づき、電話をかけ、不平を言います。 おそらく、CTOが次に電話をかけます。 

人間の構成を可能な限り削除します。これは、人の時間を節約するだけでなく、監視、つまり監視対象のサービスの信頼性を大幅に向上させるためです。

ソリューションの機能を検討するときは、次のことを考慮してください。 

  • 監視対象のデバイスの変更を継続的に調べ、新しいボリューム、インターフェース、Dockerコンテナー、Kubernetesポッド、ロードバランサーVIP、データベース、およびその他の変更を監視に自動的に追加します。 次に、インスタントメッセージを介して、リアルタイムまたはバッチ通知で通知します。 
  • アラートの過負荷を回避するために、検出された変更のフィルタリングと分類を提供します。
  • サブネット、さらにはハイパースケールクラウドアカウントをスキャンし、新しいマシンまたはインスタンスを監視に自動的に追加します。 
  • グラフを作成し、インテリジェントなダッシュボードを自発的に作成します。 サービスの状態を表示するために使用されるXNUMX台のWebサーバーでのセッションの合計に基づくダッシュボードグラフは、さらにXNUMX台のサーバーを追加すると自動的に更新されます。 この収集と表現の自動化により、ビジネス概要の継続性が保証されます。 

追加、移動、および変更をカバーするために、手動の監視更新に依存しないでください。

間違い#2:監視で再発を検出できない場合に解決された問題を検討する

適切な監視方法に従っている場合でも、停止が発生します。 ただし、監視によって根本原因が検出されるか、早期警告を提供するように変更されていることを確認しないと、問題は解決されません。 

たとえば、多数のユーザーがシステムに過負荷をかけているためにサービスに影響を与える停止が発生しているJavaアプリケーションでは、ビジースレッドの数が増加している可能性があります。 この増加を監視するようにJMXモニタリングを変更します。 このメトリックでアラートしきい値を作成するか、動的しきい値をサポートする監視プラットフォームを使用すると、次回、事前警告を受け取ることができます。 早期警告は、少なくとも停止を回避するためのウィンドウを提供します。負荷を共有するために別のシステムを追加する時間、または負荷制限メカニズムをアクティブにする時間です。 ダウンタイムに応じてアラートを設定することで、次回は積極的に対応できます。 次に停止が発生した場合、根本原因が繰り返し防止可能なイベントを指していることはありません。 

これは非常に重要な原則です。 サービスの復旧は最初のステップであり、問​​題を解決または却下する必要があるという意味ではありません。 監視ソリューションが問題の前に出した警告、および問題の間にトリガーされたアラートの種類とエスカレーションの内容に満足する必要があります。 問題は、事前に警告する方法がない場合(壊滅的なデバイス障害が発生する場合)ですが、この評価プロセスは、サービスに影響を与えるすべてのイベントに対して実行する必要があります。

間違い#3:アラートの過負荷

過負荷と疲労を警告する 最も有害な状態のXNUMXつです。 トリガーされるアラートが多すぎると、すべてのアラートが調整されます。 管理者が別の誤ったアラートであると想定したために、重大な本番サービスの停止アラートがXNUMX時間のスケジュールされたダウンタイムにプッシュされる状況に遭遇する可能性があります。

これを防ぐには、次の方法が必要です。 

  • 警告とエラーまたは重大なアラートレベルを区別する賢明なエスカレーションポリシーを採用します。 NTPが同期していない場合、ユーザーをウェイクアップする必要はないかもしれませんが、プライマリデータベースボリュームで200ミリ秒の遅延が発生し、エンドユーザーのトランザクション時間が18秒である場合、これは重要です。 いつでも、あなたはそれに参加する必要があります。 
  • 適切なアラートを適切な人にルーティングします。 ネットワークの問題についてDBAに警告したり、ハングしたトランザクションについてネットワークグループに通知したりしないでください。 
  • しきい値の調整。 すべてのアラートは、現実的で意味のあるものでなければなりません。 監視を調整して、テストシステムでトリガーされた誤検知やアラートを取り除きます。 
  • すべてが正常であると思われるときにトリガーされるアラートの調査。 外向きの問題がない場合は、しきい値を調整するか、アラートを無効にします。
  • アラートが確認、解決、およびクリアされるようにします。 何百もの未確認のアラートは、当面の問題を簡単に解析するには難しすぎます。 アラートフィルタリングを使用して、担当するシステムのグループのみを表示します。 
  • ホストまたはアラートタイプごとに上位のアラートを分析します。 監視、システム、または運用プロセスの問題を修正することで、これらのアラートの頻度を減らすことができるかどうかを調査してください。

間違い#4:システムの無秩序な増加の監視

必要な監視システムはXNUMXつだけです。 Windowsサーバー用、Linux用、MySQL用、ストレージ用の監視システムをデプロイしないでください。 各システムが高度に機能し、機能している場合でも、複数のシステムを使用すると、データセンターのパフォーマンスが最適化されないことが保証されます。 チームは、できるだけ多くの異なるテクノロジーを監視するためのXNUMXつの場所を必要とし、「同じ賛美歌シートから歌っている」ことを確認し、お互いに指を向けないようにします。 テクノロジーベンダーから入手できるツールを使いたくなることがよくあります。これは、チームがさまざまなプラットフォームにログインして、状況の偏った見方を確認することを意味します。

チームの連絡先の詳細を保存する中央の場所も重要です。 XNUMXつのシステムのエスカレーション方法に最新の情報は必要ありませんが、他のXNUMXつのシステムには必要ありません。 XNUMXつの監視システムでメンテナンスを正しくスケジュールする必要はありませんが、同じシステムの他のコンポーネントを追跡するために使用するものでは必要ありません。 誤ってルーティングされたアラートが発生し、最終的にアラートが過負荷になります。 認識できない問題について人々に通知するシステムは、「ああ…携帯電話の通知をオフにしました」につながります。 

この問題の変形は、SysAdminsとDBAがcronジョブまたはストアドプロシージャを記述して問題をチェックして警告することにより、物事を自動化する場合です。 最初の部分は素晴らしいです–チェック。 ただし、アラートは監視システムを介して発生する必要があります。 監視システムにスクリプトを実行させて出力を確認するか、ストアドプロシージャを呼び出すか、Webページを読んでください。 しきい値の調整、アラートの確認、エスカレーションの処理などを行うための別の場所は必要ありません。 ローカルで実行されるXNUMX回限りのアラートハックには、これらの監視システム機能は組み込まれません。 さらに、このアプローチでは、監視サイロが作成されます。チームメンバーの中には、データとアラートがあるものとないものがあります。

間違い#5:監視システムを監視していない

監視ソリューションが失敗する可能性があります。 この事実を無視すると、あなたは露出したままになります。 企業は、監視を設定し、スタッフの時間の経常コストを理解するために多額の資本を投資しますが、システムの監視に失敗します。 ハードドライブまたはメモリの障害が発生したとき、OSまたはアプリケーションのクラッシュが発生したとき、ISPでネットワークが停止したとき、または電源障害が発生したときを誰が知っていますか? 監視システムがインフラストラクチャの残りの部分の状態を知らないままにしないでください。 監視システムには、アラートを送信する機能を含むシステム全体が含まれます。 送信メールとSMSメッセージ配信接続がダウンしている場合、監視システムが停止を検出する可能性がありますが、それはコンソールを監視しているスタッフにのみ明らかです。 アラートを送信できないシステムは役に立ちません。

偽のセキュリティは、監視システムがまったくない場合よりも悪いです。 監視システムがない場合は、手動でヘルスチェックを実行する必要があることがわかります。 監視されていないシステムがダウンしている場合は、ヘルスチェックを実行しておらず、無意識のうちにビジネスを検出されない停止にさらしています。 チームが監視ツールの信頼性に対する信頼を失った場合、チームはそれが生成するアラートの有効性に疑問を呈し始める可能性があります。

監視システムの到達範囲外の場所から監視システムのチェックを構成することにより、リスクを最小限に抑えます。 または、別の場所でホストされているだけでなく、複数の場所から独自の監視ソリューションの状態をチェックする監視ソリューションを選択します。

これらすべての間違いに対処する最善の方法は、あなたに代わって機能する包括的な監視プラットフォームを見つけることです。 LogicMonitorは、組織が発生する前に何が起こっているかを確認できるようにするクラウドベースの監視プラットフォームです。 高度なAIOps機能により、 LMIntelligence(LMインテリジェンス)、LogicMonitorは、チームがビジネスクリティカルなシステムとエンドユーザーのパフォーマンスに悪影響を与える前に、ITインフラストラクチャの問題をプロアクティブに特定して解決するのに役立ちます。 LogicMonitorの機能について詳しく知りたい場合は、 プラットフォームのデモを見る or 無料トライアルをリクエストしてください。 

スチュアート・カリソン

技術スペシャリスト

Stuart Carrisonは、LogicMonitorの従業員です。

LogicBlogを購読して、LogicMonitorの最新の開発に関する最新情報を入手し、ITエキスパートとエンジニアのワールドクラスのチーム、およびITプロフェッショナルが愛する製品。

LogicBlogの他の記事

アンペアロボット 影

お店の話をしましょう。

STARTED GET