地理的に分散した、フォールトトレラントで「インテリジェントな」アプリケーション/ホスト監視システム


12

ご挨拶、

分散監視システムに関する集団の意見と見解を尋ねたいのですが、何を使用し、どのボックスが私のボックスにチェックマークを入れるのかを知っていますか?

要件は非常に複雑です。

  • 単一障害点はありません。本当に。私は真剣です!「マスター」と「ワーカー」の両方の単一/複数ノード障害に耐えられる必要があり、監視場所(「サイト」)に複数のノードが存在しないか、同じネットワーク上にあると想定できます。したがって、これはおそらく、DRBDやキープアライブなどの従来のHA技術を排除します。

  • 分散ロジック、複数のネットワーク、複数のデータセンター内、複数の大陸に5つ以上のノードを展開したいと思います。顧客の視点からのネットワークとアプリケーションの「鳥の目」ビュー、50以上のノード、さらには500以上のノードがある場合でも、監視ロジックが動かなくなることのないボーナスポイントが必要です。

  • 球場の数値では1500〜2500のホストとホストあたり30のサービスを想定しているため、かなり合理的な数のホスト/サービスチェック、la Nagiosを処理できる必要があります。監視ノードを追加することで比較的直線的にスケーリングできるようになり、5年後には5000ホストとホストあたり40サービスを監視できるようになると思います。上記の「分散ロジック」についてのメモに追加して、次のように言ってください。

    • 通常の状況では、これらのチェックは監視ノードの$ nまたはn%で実行する必要があります。
    • 障害が検出された場合、ノードの別の$ nまたはn%でチェックを実行し、結果を相関させてから、それらを使用して、アラートを発行する基準が満たされているかどうかを判断します。
  • グラフと管理しやすい機能。SLAを追跡し、「高可用性」アプリケーションが24時間365日稼働しているかどうかを知る必要があります。理想的には、提案されたソリューションは最小限の労力で「箱から出して」報告する必要があります。

  • オーダーメイドチェックを開発するための堅牢なAPIまたはプラグインシステムが必要です。

  • アラートについて賢明である必要があります。1つの監視ノードがコアルーターがダウンしていることを認識していることを(SMSを介して、午前3時に!)必ずしも知りたくありません。私はないそれらの定義された割合があれば知りたい同意何かファンキーが起こっていること。)基本的に私はおよそここで話していることは、「定足数」の論理、または分散狂気への正気のアプリケーションです!

私は商用とオープンソースの両方のオプションを検討したいと思いますが、数百万ポンドかかるソフトウェアを避けたいと思います:-)また、これらすべてのボックスをチェックするものが何もないかもしれないことを受け入れます集団にそれを尋ねたかった。

ノードとその配置を監視することを考えるとき、これらのほとんどはランダムISPネットワーク上の専用サーバーであり、そのため主に私の制御範囲外になることに留意してください。BGPフィードやその他の複雑なネットワークのふるまいに依存するソリューションはおそらく適切ではありません。

また、Nagios、Zabbix、友人など、過去のほとんどのオープンソースのフレーバーを評価、展開、または頻繁に使用/カスタマイズしたことも指摘しておく必要があります。特に、私の質問で説明されているロジックと「インテリジェント」アラートに関して。

必要な点を明確にしてください。乾杯のみんなとギャル:-)


2
それは本当に奇妙です、私は同様の質問をしようとしていました。今週、サイトの停止に関する顧客からの苦情がいくつかありましたが、特定の場所からのみでした。アラートシステムはこれらの問題を検出しませんでした。私たちはプロバイダーに連絡し、一部のバックボーンに問題があることを確認しました。だから私も解決策に興味があります。ありがとう!
飛び散る

そして、最終的な解決策は何でしたか?
ewwhite

回答:


4

実際には答えではありませんが、いくつかのポインタ:

  • nagios @ goldman sachsについてのプレゼンテーションを明確に見てください。彼らはあなたが言及した問題に直面しました-冗長性、拡張性:数千のホスト、自動構成生成。

  • 冗長なnagiosセットアップがありましたが、規模ははるかに小さく、80サーバー、合計で約1kサービスです。1つの専用マスターサーバー、1つのスレーブサーバーが1日に数回、定期的にマスターから設定を取得します。両方のサーバーが同じマシンの監視をカバーしており、互いのヘルスクロスチェックがありました。私は主にカスタム製品固有のチェックを呼び出すためのフレームワークとしてnagiosを使用しました['人工的なフロー制御'を実行するスクリプトを実行するcronジョブの束、SQLに記録される結果ウェア、最後のx分間で実行の成功/失敗を確認するnrpeプラグインウェアチェック)。すべてが非常にうまくいきました。

  • クォーラムロジックは良さそうです-私の「人工の流れ」に少し似ています-基本的には続行し、自己を実装します;-]。そして、nrpeに何らかの種類のフラグ[またはtimestamp-statusのsql db]をチェックするだけです。

  • おそらく、いくつかの階層をスケールして構築する必要があります-他のノードの概要を収集するノードがいくつかあります。最初の点からプレゼンテーションを見てください。単一のチェックごとのデフォルトのnagiosフォークは、より多くの監視対象サービスでは過剰です。

いくつかの質問に答えるには:

  • 私の場合、監視対象の環境は一般的なマスター/スレーブ設定[プライマリSQLまたはアプリサーバー+ホットスタンバイ]で、マスター/マスターはありませんでした。
  • 私の設定には「ヒューマンフィルタリングファクター」が含まれていました。これは、SMS通知の「バックアップ」であるリゾルバーグループです。他の理由で24時間5分シフトしている有償の技術者グループがすでにいて、追加のタスクがあまり負荷をかけないように「nagiosメールをチェックする」ことができました。そして、db-admins / it-ops / app-adminsが実際に立ち上がって問題を修正することを確認する責任を負います;-]
  • zabbixについての良いことをたくさん聞いたことがあります-トレンドを警告してプロットするためですが、使ったことはありません。私にとっては、muninがトリックを行います。muninサーバーのリストに「任意の赤」[重大]色があるかどうかをチェックする単純なnagiosプラグインをハックしました-追加チェックだけです。munin rrdファイルから値を読み取って、監視対象マシンに送信するクエリの数を減らすこともできます。

1
@astinus-賢明なアラートには、カスタム通知スクリプトを使用しました。nagiosに依存する代わりに、メール/ポケットベルiでメッセージをfifo queに保存し、カスタムロジック[非常に柔軟なオンコールスケジュールなどに基づく]に基づいてメッセージをディスパッチするコンシューマーを追加しました。 50のsmsesを短時間で取得しません。私は同様のアプローチを大規模で見ています-nagiosは単なるスケルトンであり、人々はスクリプトを作成し、実際にはその機能の使用を減らしています。
pQd 2009

1
階層に関して、現時点で私が持っているのは、あなたのetc /ディレクトリにすべてのホストで共有(および同一)され、次にetc / modules / $ NAME(すなわち、 :メール、Web、ネットワーク、DNS)。サーバー間で100%移植可能です。cfg_dirに含める=)モジュール固有のコマンド、プラグイン、すべてをそのディレクトリに入れます。必要な数のNagiosボックスにモジュールをコピーするだけなので、1台以上のサーバーでこれらのチェックを実行するのは非常に簡単ですが、もう一度、アラートロジックが問題を引き起こします:
nixgeek 09

1
@ astinus#2。私の場合、config replication master-> slaveは6時間ごとに発生します。マスターが死んだ場合[停電など]-スレーブはマスターが死んでいることを全員に警告します[サーバー間のクロスチェック]。他のシナリオを想像できます-マスターが設定ミスのために死ぬとき。それがスレーブへの設定同期の最大5分前に発生した場合-通知があります。構成同期の直前の場合-残念ながら、監視システムがありません。「誰が番人を見ますか」おそらく、もう1つの非常に単純なnagiosです。
pQd 2009

1
@pQd-興味深いことに、カスタム通知スクリプトにロジックを実装するのがおそらく道であることに同意します。ただし、50台の監視ホストがある場合、2つ以上のホストからの重複した通知を避けることは非常に難しくなります。共有ロジックをRabbitやAmazonなどの適切な「メッセージ」パッシングシステムに配置する人はまだいません。 SQS。
nixgeek

1
私の場合、@ astinus#3は「iso osiモデルの」レベル8ソリューションでした:プライマリnagiosは通話中の人にSMSを送信し、24/5の「リゾルバグループ」にメールを送信しましたが、セカンダリnagiosはメールのみを送信していましたレゾルバグループ」。エスカレートする前に重複をフィルタリングするのはそのグループ次第でした。
pQd 2009

1

あなたが求めていることは、シンケンがNagiosのためにしたこととよく似ています。

ShinkenはNagiosの書き換えです。

  • 現代言語(Python)
  • 最新の分散プログラミングフレームワーク(Pyro)
  • レルム(マルチテナンシー)、HA、スペアの監視
  • Livestatus API
  • Nagiosプラグイン互換
  • ネイティブNRPE実行
  • オブジェクトのビジネス上の重要性
  • ビジネスルールはオブジェクトの状態に適用できます(クラスターまたはプールの可用性の管理)
  • グラフ作成には、GraphiteまたはRRDtoolベースのPNP4nagiosを使用できます
  • 大規模環境で安定してデプロイされている
  • 大規模な展開では、レポートのためにSplunkとペアリングすることを検討するか、RRDtoolが適さないGraphiteを調べることができます。

これは思考の糧になるはずです。

乾杯

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.