web-dev-qa-db-ja.com

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

ご挨拶、

分散監視システムについての意見や見解をまとめて聞きたいのですが、何を使用していて、どれが私のボックスをチェックする可能性があるかを知っていますか？

要件は非常に複雑です。

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

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

  • 野球場の数値では、1500〜2500のホストとホストあたり30のサービスを想定しているため、かなり妥当な数のホスト/サービスチェックを処理できる必要があります。監視ノードを追加することで、比較的直線的に拡張できるようになれば、本当に素晴らしいでしょう。おそらく5年後には、ホストごとに5000のホストと40のサービスを監視することを検討しているかもしれません。上記の「分散ロジック」に関するメモに加えて、次のように言っておくとよいでしょう。

    • 通常の状況では、これらのチェックは監視ノードの$ nまたはn％で実行する必要があります。
    • 障害が検出された場合は、別の$ nまたはn％のノードでチェックを実行し、結果を相互に関連付けてから、それらを使用して、アラートを発行するための基準が満たされているかどうかを判断します。

  • グラフと管理しやすい機能。 SLAを追跡する必要があり、「高可用性」アプリケーションが24時間365日稼働しているかどうかを知ることはある程度役に立ちます。理想的には、提案されたソリューションは、最小限の手間で「箱から出して」レポートを作成する必要があります。

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

  • アラートについて賢明である必要があります。 one監視ノードがコアルーターがダウンしていると見なしていることを（SMS経由で午前3時に！）必ずしも知りたくありません。私doそれらの定義されたパーセンテージが同意する何かファンキーなことが起こっているかどうか知りたい;）本質的にここで話しているのは「クォーラム」ロジック、または分散狂気への正気の適用！

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

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

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

必要なポイントを明確にしてください。乾杯男とギャル:-)

monitoringnagiossla
12
nixgeek

実際には答えではありませんが、いくつかの指針があります。

  • nagios @ goldman sachs についてのプレゼンテーションを間違いなく見てください。彼らはあなたが言及した問題に直面しました-冗長性、スケーラビリティ：何千ものホスト、また自動化された構成生成。

  • 私は冗長なnagiosセットアップを持っていましたが、はるかに小規模で、80台のサーバー、合計で最大1,000のサービスです。 1つの専用マスターサーバー、1つのスレーブサーバーが1日に数回定期的にマスターから構成をプルします。両方のサーバーが同じマシンの監視をカバーし、相互にヘルスクロスチェックを行いました。私は主にカスタム製品固有のチェックを呼び出すためのフレームワークとしてnagiosを使用しました[「人工フロー制御」を実行するスクリプトを実行する一連のcronジョブ、SQLに記録された結果ウェア、過去x分間の実行の成功/失敗をチェックするnrpeプラグイン]。すべてが非常にうまく機能しました。

  • あなたのクォーラムロジックは良さそうです-私の「人工フロー」に少し似ています-基本的に続けて、あなたの自己を実装してください;-]。 nrpeに、ある種のフラグ[またはtimestamp-statusを指定したsqldb]をチェックさせます。

  • スケーリングする階層を構築することをお勧めします。他のノードの概要を収集するノードがいくつかあります。最初のポイントからプレゼンテーションを見てください。すべてのチェックに対するデフォルトのnagiosフォークは、監視対象サービスの数が多いとやり過ぎです。

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

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

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

真剣はNagiosの書き直しです。

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

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

乾杯

1
xkilian