これは、監視ソフトウェアに関する正規の質問です。
サーバーを監視する必要があります。監視ソリューションを決定する際に何を考慮する必要がありますか？
関連：サーバーの監視に使用するツールは何ですか？
—
クリスS
これは、監視ソフトウェアに関する正規の質問です。
サーバーを監視する必要があります。監視ソリューションを決定する際に何を考慮する必要がありますか？
回答:
そこには多くの監視ソリューションがあります。誰もが好みを持ち、各ビジネスには独自のニーズがあるため、正しい答えはありません。ただし、監視ソリューションを選択する際に何を探したいかを理解するのに役立ちます。
一般に、監視システムは2つの主要な目的を果たします。1つ目は、長期にわたってデータを収集して保存することです。たとえば、CPU使用率を収集し、経時的にグラフ化することができます。2番目の目的は、物事が応答しないか、特定のしきい値内にない場合にアラートを出すことです。たとえば、pingで特定のサーバーに到達できない場合、またはCPU使用率が特定の割合を超えている場合にアラートが必要になる場合があります。Splunkなどのログ監視システムもありますが、私はこれらを別個のものとして扱っています。
これらの2つの主要な役割は、単一の製品に含まれることもありますが、より一般的なのは、各目的専用の製品を用意することです。
ポーラー：
すべての監視システムには、データを収集するために何らかのポーラーが必要です。すべてのデータが同じ方法で収集されるわけではありません。環境を見て、必要なデータとその収集方法を決定する必要があります。次に、選択した監視システムが必要なものをサポートしていることを確認してください。一般的な方法には次のものがあります。
環境に主に1つのOSまたはプライマリOSがある場合、特定のシステムには他のシステムよりも多くのオプションがある場合があります。
構成：
監視システムでは、多くのオブジェクトが再利用される傾向があります。たとえば、多数のサーバー上のApacheやIISなどの特定のアプリケーションを監視する必要があります。または、サーバーのグループに特定のしきい値を適用する必要があります。また、特定のグループの人々が「通話中」になる場合もあります。したがって、モニターシステムには、適切なテンプレートシステムが不可欠です。
通常、構成はユーザーインターフェイスまたはテキストファイルを介して行われます。ユーザーインターフェイスオプションは一般に簡単ですが、テキストファイルは再利用や変数の方が優れている傾向があります。そのため、ITスタッフによっては、電力よりも単純さを好む場合があります。
ユーザーインターフェイス：
最近の監視システムの最も一般的なインターフェイスは、Webインターフェイスです。Webインターフェースに関して評価するいくつかの事項は次のとおりです。
アラートエンジン：
アラートエンジンは、柔軟性と信頼性が必要です。以下を含むさまざまな通知方法があります。
他に探す機能は次のとおりです。
何か問題が発生した場合にアラートを受け取ることを信頼することが重要です。これには次の2つがあります。
データストア：
システムがデータを保存するよりも、システムがデータを収集および保存する場合（つまり、グラフを含むシステム）。ストアとグラフ作成の両方の非常に一般的な実装は、たとえばRRDです。
データストアから検索する機能は次のとおりです。
グラフライブラリ：
グラフは、傾向をすばやく特定し、その履歴に基づいて何かの現在の状態にコンテキストを与えるのに役立ちます。発生する前に物事を予測するのに役立つ傾向があります（つまり、ディスク領域が不足している）。グラフが明確な方法で必要になると思われる情報を提供することを確認してください。
アクセス制御：
大規模な組織の場合、特定の管理者のみが特定のものを調整できるため、アクセス制御が必要になる場合があります。また、一般向けのダッシュボードが必要になる場合があります。これが重要な場合は、監視システムに必要な制御があることを確認する必要があります。
レポート：
優れたレポートを提供するシステムは、長期にわたって改善する必要があるものを特定するのに役立ちます。たとえば、「どのシステムが最もダウンしますか？」などに適切な回答を提供できます。これは、経営者に特定のことにお金を使うように説得しようとしているときに重要になります。
特殊な機能：
一部の監視システムは、特定の製品を対象としているか、他のシステムよりも多くのサポートを提供しています。たとえば、監視する必要がある主なものがSQLサーバーである場合、またはVMWare製品を多用する場合は、これらがどの程度サポートされているかを確認する必要があります。
事前定義された監視テンプレート：事前定義
された多くのテンプレートを備えた（または多くのテンプレートを作成したユーザーベースを備えた）システムは、時間を大幅に節約できます。
ディスカバリー：
大規模な環境または変化する環境がある場合。一部のシステムでは、APIを介して新しいシステムを追加したり、スキャンを実行して新しいサーバーやコンポーネントを検索したりする機能を提供しています。
分散監視：監視
する場所が複数ある場合、多くの独立したシステムがWANを介して監視する代わりに、各場所に監視ポーラーを配置すると便利です。
そこには多くの監視システムがあります。この古い質問の概要を記載したリストがあります。クイックリファレンスについて、私が最もよく耳にするものは次のとおりです。
使用するものを説明できない理由は、すべての組織に独自のニーズがあるためです。適切な選択をしたい場合は、上記のすべてのコンポーネントを検討し、組織にとって重要な機能を把握する必要があります。次に、必要なものを提供すると主張するシステムを見つけて、試してください。これらのいくつかは、少し、たくさん、または無料です。そのすべてを考慮に入れて、選択を行うことができます。私が使用したものから、それらはすべて完璧とはほど遠いですが、少なくともあなたは適合するものを手に入れることができます。
監視と警告を区別すると便利です。監視とは、データを収集してグラフを作成することです。アラートとは、深夜にサーバーがダウンしたときにSMSを送信することです。
Nagiosはアラート用です。サボテンとムニンはモニタリング用です。他の製品は、2つの機能を組み合わせています。ZenossとZabbixは例です。
いくつかの質問に答えることから始めます。
サーバー、ネットワークデバイス、アプリケーション、または3つすべてを監視する必要がありますか？
監視に使用できる方法に制限はありますか？NRPEのような監視クライアントをサーバーにインストールできますか、それともSNMPを使用しますか、あるいはその両方ですか？
誰がグラフを使用し、誰がアラートを使用しますか？最終結果をどのように見せたいですか？インターフェイスのルックアンドフィールは重要ですか（ビジネスの人々はこれを使用しますか、それとも技術スタッフのみを使用しますか？）
時間、スキル、ハードウェアの両方の面であなたのリソースは何ですか？少なくとも控えめなスクリプト作成能力はありますか？すぐに使えるソリューションが必要ですか？
私の意見では、警告と監視の両方の最初のルールはシンプルに保つべきです！組織は、データをどのようにアラートおよび収集するかについて生きたり死んだりする可能性があり、ほとんどの場合、組織はそれ自体で複雑になります。基本から始めて、そこからビルドします。
ソフトウェアが提供するサービスについて考え、これらのサービスが失敗した場合、またはこれらのサービスの失敗のリスクが増加した場合にアラートを送信します。
監視戦略の背後にある理論は、監視と警告をある種のサービスレベル合意に結びつけることです。結局のところ、nji0019.myserver.comへのTCP接続の数が急増しているとは限らず、お金を失っているという事実に注意を喚起したいのです。大量のアラートを提供し、アラート間の依存関係を定義するさまざまなツールがありますが、これらのチェックの多くは、誰かに提供するサービスに直接関係しません。
Webサイトを提供する機能や、そのWebサイトを変更する機能（ある種のCMSなど）など、提供する重要なサービスを特定します。それらをチェックする必要があります（たとえば、Webページを取得できること、およびできることを監視することによって）。これら2つのサービス（ここでは大文字のSで使用）が失敗すると、アラートがトリガーされて通知されます。
サイトが妥当な時間内に応答することが重要な場合は、それもアラートをトリガーする必要があります。「SLAの違反」の並べ替え。
通常、サービスが失敗するという固有のリスクがあり、多くの場合、2番目のサーバー、スレーブデータベース、追加のネットワークカードなどの冗長性を導入することでリスクを軽減できます。
その冗長性が失われた場合でも、サービスは問題ありませんが、サービスが失敗するリスクは上がりました。
これは、アラートをトリガーする2番目の主要な理由です。その冗長性がなくなった（たとえば、2番目のサーバーが停止した）、またはリスクが増大する差し迫った危険がある（たとえば、ディスクの空き容量が500Mbしかない、またはディスクの傾向がディスクが約5時間でいっぱいになることを示している）
しかし、check_mkはホストごとに50〜60のチェックを提供します。これらはすべて価値がないのですか？
いいえ。これは、たとえばcheck_mkで取得する多数の自動チェックを捨てたいという意味ではありませんが、何かが失敗した場合に影響を受ける可能性のあるサービスに各チェックを分類する必要があることを意味します。
/ var /パーティションがいっぱいになると、どのサービスが影響を受けますか？eth0インターフェイスがダウンした場合、どのサービスが影響を受けますか？...アウトバウンドTCP接続が何らかのファイアウォールによってブロックされている場合 ...スレッドの数が800を超える場合 ...データベースがダウンした場合
2つのWebサーバーと、所有していないロードバランサー（ISPなど）の背後にあるサイトにサービスを提供するデータベースサーバーがあります。提供するサービスは2つのサーバーのポート80であり、データベースのダウンタイム（3番目のサーバー上のデータベース）などに耐えられる巨大なキャッシュがあります。
このシナリオでは、Webサーバーの完全な障害によってサイトがダウンすることはありません。何が起こったのかというと、冗長性がなくなり、障害のリスクが上がっただけです。 それがアラートをトリガーするはずです。
データベースの完全な障害は、適切に調整されたキャッシュがあるため、サイトを提供する機能にまったく影響しない場合があります。これは、Webサイトを提供するサービスには影響しませんが、別のサービス、つまりWebサイトの更新、または注文の受け入れに影響する可能性があります...
各サービスには、サービスの復元または停止を回避することがどれほど重要かを指定する独自のレベルのサービスがあります。
アラートが発生するたびに、次のいずれかを実行する必要があります。-監視対象のシステムを変更して、アラートの原因となった問題を修正します（たとえば、ドライブの交換またはlogrotateその状況が次に発生したときに送信されます。（たとえば、「ディスク空き容量」のレベルを変更して、ディスクが80％だけでなく最大90％までいっぱいになるようにします）
私はNagiosとその詳細な構成にほとんど精通しており、それ以来Check-mkのマルチサイトに夢中になっています。私は最近、check_mkにこの考え方とよく一致するように見えるビジネスインテリジェンス（1.11以降）の概念があることを学びました。nagiosのチェックはより大きなサービスの一部であり、「サービス」の状態を多くのチェックの状態の関数として定義し、最悪または最良の状態に集約するルールを定義できます。
監視ソリューションを選択する際に企業が忘れる最も重要なポイントの1つは、即時の運用上の問題を解決することではなく、明日の予期しない問題に関することです。もちろん、差し迫った問題を解決することは重要ですが、私を信じてください。多くの場合、この近視眼的な戦略は企業の存続を保証するものではありません。
市場には多数の優れた監視ソリューションがあります。要件を満たすソリューションの小さなセットを候補リストに追加するのは難しく、長いタスクです。さらに、予算に合ったソリューションを見つけることはさらに困難です。興味深い部分は、あなたの現在と未来に合ったものを見つけることです。そして、それを検出するための評価プロセスはありません。それは経験の問題+直感+非常に重要な要因です：信頼、これはハッキングするのは簡単なことではありません。
経験則として、特にあなたのセクターの企業に影響を与える場合は、監視ソリューションの最終候補リストの成功事例を検索して掘り下げます。ベンダーに成功事例を尋ね、さらに顧客の1人と話す許可を求めます。このことを恐れていない企業は、顧客と本当の関係を持っていることを示しており、それを隠していません。これは、最近では非常にまれなことです。
Zabbix、Icinga、Pandora FMS、op5、Datadog、New Relic ...これらにはすべて長所と短所がありますが、本当の問題はどちらがあなたの将来により良く適合するかを見つけることです。
リモートシステムの監視を検討している場合、テストの実行元の実際の場所を探すことをお勧めします。接続の問題は過去のものではなく、ハードウェアが特定の地域のグループにサービスを提供している場合は、その特定の場所でリソースが利用可能であることを確認したい場合があります。