OpenNMS監視システム

少しでも愛国心がないように思われたくはありませんが、歴史的には、ネットワークインフラストラクチャを監視するための企業システムを選択すると、OpenNMSが当社を打ち負かし、Grandma Cactiをこのポジションから排除し、同胞Zabbixを追い抜いたことが判明しました。 Open Source監視システムの比較分析は私の計画に含まれていません。したがって、OpenNMSについてはHabrについては書いておらず、あまり情報がないので、OpenNMSについて一般的な用語で概説します。



OpenNMS（Open Network Monitoring System）の主な機能は、さまざまなサービスとネットワークおよびサーバー機器の内部システムの監視です。 情報を収集するために、いわゆる「コレクター」が使用され、SNMP、HTTP、ITDITPプロトコルを介して動作します。 OpenNMSには個別のサーバーエージェントはありません。 情報が必要であることが判明した場合、「使用例」セクションの次の資料で「ラッパー」の実装例を説明します。 著者と読者の両方が理解するのが難しい巨大なテキストシートの発行で間違いを繰り返したくありません。

簡単な説明

OpenNMSは動的に開発されており、十分に文書化されていますが、コミュニティは断片化されており、無数のXMLファイルを編集するように構成すると、多くの人が怖くなります。 システムはJavaで書かれており、Perlの付録があり、さまざまなプラットフォーム用のかなりの量のディストリビューションがリリースされています。 必要に応じて、Java SDKおよびPostgreSQLサーバーがインストールされている任意のマシンで実行できます。

1 GHz Pentium III（または同等のプロセッサ）以上。 最小256 MBのRAM。ただし、512 MBを強くお勧めします。

公式のドキュメントに記載されているこれらのシステム要件は、控えめに言っても、 最小限のものであり、システム自体を起動するだけのものです。 したがって、64ビットCPU、2 Gb RAM（これは非常に最小限）、高性能ハードドライブなど、少し修正することができます。



システムの大食いは、監視するノードの数に依存します。 1,500以上のノードと5,000以上のインターフェイス（VLAN、ポート、サービスなど）を備えたシステムは、12 GbのRAMとSASハードを搭載したXeon E5520で快適に感じます。 同時に、rrdファイルを保存するための2Gb tmpfsパーティションが提供されました。 パワーリザーブは2回以上割り当てられています。これは、ネットワークの成長と、更新および開発のプロセスにおけるシステムの欲求に影響を与えています。

設置

ntp, net-snmp, net-snmp-utils, postgresql, postgresql-server, perl



事前インストールしntp, net-snmp, net-snmp-utils, postgresql, postgresql-server, perl



。 基本的に、示されているすべてのサービスを構成して実行します。 次に、Oracleサイトから最新バージョンのJDKをダウンロードしてインストールします。最後に、OpenNMSリポジトリに接続してシステム自体をインストールできます。

 rpm -Uvh http://yum.opennms.org/repofiles/opennms-repo-stable-rhel6.noarch.rpm yum install opennms iplike
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最新のパッケージは、IPNIKEストアドプロシージャの形式でのOpenNMS開発者からのPostgreSQLのアドオンで、 192.168.4-255.*



などのマスクを使用してIPアドレスとネットワークアドレスによるクエリを処理するのに役立ちます192.168.4-255.*



は、システム自体でアクティブに使用されます。



[！]システムがインストールされているホスト名が、resolv.confに登録されているDNSサーバーで解決しない場合は、ホストに書き込みます。 そうしないと、システムは起動しません。 また、PostgreSQLの初期設定にも注意を払う必要があります。 /var/lib/pgsql/data/pg_hba.conf



にサーバーをデフォルトでインストールした後、3つのローカル接続すべてにメソッドtrustを配置します。

 /opt/opennms/bin/runjava -S /usr/java/latest/bin/java /opt/opennms/bin/install -dis /etc/init.d/opennms start
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

起動後、システムは次の場所で利用可能になります。 hostname:8980



hostname:8980



別のWebサーバーをインストールする必要はありません-OpenNMS WebインターフェイスはJettyサーバーを介して機能します。 ただし、必要に応じて、Jetty自体を再構成するか、ポート80でmod_proxyを使用してNginxまたはApacheをハングアップし、すべての要求でproxy_passを実行できます。



システム全体を再インストールする場合、データベースを削除して/var/opennms



を削除する必要があります。 そうしないと、グラフやレポートとの衝突が発生します。 完全な再インストールの場合、部分的に/opt/opennms/bin/install -dis



ために、 yum reinstall opennms



および/opt/opennms/bin/install -dis



yum reinstall opennms



をyum reinstall opennms



/opt/opennms/bin/install -dis



2回目のみ）。



OpenNMSの起動時に、OpenNMSの開始メッセージが表示されますが、 Started OpenNMS, but it has not finished starting up



。 まず、構成エラーが発生し、すべてのサービスが実行されているかどうかを確認する必要があります（ opennms -v status



コマンド）。 そして、すべてのサービスが実行されている場合、悪いニュースがあります。OpenNMSには十分なリソースがなく、安心が必要です。 内容がSTART_TIMEOUT=20



のファイル$opennms/etc/opennms.conf



作成します。 パラメータの数値は、すべてのサービスの無視をチェックするための5秒間隔に乗算される係数です。 デフォルトでは、このパラメーターは10であり、50秒以内にすべてのサービスに正常な開始を報告する時間がない場合、エラーが返されます。 つまり、 START_TIMEOUT=20



は、すべてのシステムが起動するまでの100秒の待機です。

インターフェースとセットアップ

おそらく、Webインターフェースの詳細な説明のある部分をスキップします。一般的に、システムはセクションを10分歩くと明らかになりますが、XMLファイルでWebインターフェースを操作するだけでは済まないことに注意してください。XMLファイルを深く掘り下げる必要があります。







そのため、たとえば、 Admin → Configure SNMP by IP



セクションのWebインターフェースを使用して、特定のサブネットのSNMPコミュニティを簡単に追加できます 。 ただし、対応するXMLファイルでのみ、既に追加されているコミュニティを表示および編集できます。 同時に、監視対象のサブネットの範囲（ network discovery



）をWebインターフェイスから完全に編集できます。



構成ファイルを多く編集する必要があるため、使い慣れたCVSを接続して変更を追跡することをお勧めします。 また、構成ファイルを編集した後、 xmllint --noout filename.xml



としてチェックする習慣を身に付けることをお勧めします。 最後の仕上げ：設定ファイルへの変更は、opennmsデーモンを再起動することで適用されますが、これにはかなり時間がかかります。

内部力学

データ収集の基本単位は、特定のサービスを統合するインターフェースです。 1つのデバイス上のすべてのインターフェイスは、ノードにグループ化されます。 インターフェイスは必ずしもネットワークであるとは限りません。OpenNMSの観点からは、温度センサーもインターフェイスです。 バージョン1.9以降、同様のインターフェースは個別のグループに編成されています。



新しいインターフェイスがnewSuspect



と、 newSuspect



イベントがnewSuspect



ます。その後、システムはこのインターフェイス上のサービスを検出し、チェーン内のデバイス上の他のインターフェイスを見つけ、受信した情報をノードにグループ化します。 OpenNMSは、新しいインターフェイスに関するデータを自動的に（特定の頻度で特定の範囲を検索して）、手動で（perlスクリプトを呼び出して）、またはSNMPトラップを受信して​​受信できます。

 #    ,      : perl /opt/opennms/bin/send-event.pl --interface 192.168.11.11 uei.opennms.org/internal/discovery/newSuspect
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、イベント→すべてのイベントで、新しいノードの誕生の妖艶なプロセスを観察できます。 表示の速度はデバイスによって異なり、数秒から数分です。







特に興味深いのは、リソースグラフ-システムリソースのグラフです。 新しいノードを追加すると、各サービスのデフォルトデータのみが表示されます（たとえば、後者が存在する場合のICMPおよびHTTP応答時間）。 ただし、受信する情報の量を増やすことは非常に可能です。 たとえば、CentOSを実行している別のサーバーからより多くのデータを取得する必要があります。 SNMP経由でデータを受信するため、ターゲットサーバーにnet-snmpをインストールし、/ etc / /etc/init.d/snmp/snmpd.conf



/ snmp / snmpd.confを編集します

 #       com2sec, group, view  #  read-only  rocommunity stat #  location  contact syslocation Datacenter N1, Rack 2 syscontact admin@domain.tld #     disk / 10000 disk /var 10000 #    load average load 12 14 14
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

iptablesで161 UDPポートを開き、snmpdを実行し、OpenNMSで新しいSNMPコミュニティを開始します（管理→操作→IPによるSNMPコミュニティ名の構成）。 その後、追加したノードを開いて再スキャンすることができます。 スキャンが完了すると、より多くの情報が表示され、グラフはディスク容量、iノード、システムの負荷に関するデータを提供します。



管理パネルからSNMPコミュニティを追加するときにopennmsを再起動することは、正式には必要ありません。 ただし、このファイルの更新や新しい検出グループの追加が大幅に遅れることがあり、opennmが単独で起動するのを待つよりも、opennmを再起動する方が速い場合があります。

もう少し内部の仕組み

もちろん、OpenNMSはネットワークをスキャンして、ネットワーク上の新しいデバイスの出現を検出できます。 検索プロセスは、管理→ディスカバリーの構成のWebインターフェース、またはファイル$opennms/etc/discovery-configuration.xml



。

oopsmonkからの画像

新しいインターフェイスの発見とnewSuspectの操作後に開始されるOpenNMSのサービス間の接続について詳しく見ていきましょう。 さまざまなサービスの可用性を決定する2つのサービスがあります。capsd（機能デーモン）とprovisiond（プロビジョニングデーモン）です。 デフォルトでは、両方とも起動されますが、私にとってこれがなぜ行われるのかは謎のままです。 結局、capsdはバージョン1.8.0から非推奨になりましたが、provisiondよりも高い優先順位を保持しています。



したがって、私の個人的な推奨事項は、capsdを無効にして、サービスを検索するすべての注意をプロビジョニングの肩に移すことです。 後者を使用すると、プロビジョニング要求へのアクセスが提供されます。これにより、定義済みのサービスを柔軟に構成したり、ノード上の必要なインターフェースの監視を自動的に有効にしたり、カテゴリ別にノードをソートしたりできます。



サービスは、プロビジョニングの一部である検出器によって直接定義されます。 検出器は、インターフェースのフレームワーク内でのサービスの検出と登録のみを処理し、pollerdは情報の収集を担当します。 システムの以前のバージョンでは、collectdとpollerdはデータの収集と処理に関与していました。 グラフの最初の収集値、および要求に応じて2番目の値の処理。 その後、ColleddはPollerdに統合され、構成の手間が小さくなりましたが、いくつかの場所では両方の概念に出くわすことがあり、混乱を招く可能性があります。



データ処理チェーンを閉じることは、特定の初期化条件に該当するノードに適用されるルールを定義するポリシーです。 現在、MatchingIpInterfacePolicy、MatchingSnmpInterfacePolicy、NodeCategorySettingPolicyの3つが利用可能です。 それらの名前はそれ自体を表しており、ポリシーの適用により、目的のインターフェイスから情報を取得する仕組みを制御できます。 例として：

• MatchingSnmpInterfacePolicyを使用して、説明に特定の単語（たとえば[mon] ）があるインターフェースからの情報の強制収集を有効にできます。
• NodeCategorySettingPolicyを使用して、すべてのD-Linkスイッチを別のカテゴリに送信します。
• MatchingIpInterfacePolicyを使用して、同じサブネットにあるすべてのスイッチからのポート80からの情報の収集を無効にしました。 スイッチの場合、HTTP応答のタイムラインは必要ありません-マジックワード[mon]を指定するインターフェイスからのICMP応答とデータが常に存在します

おわりに

安定性。 システムの唯一の重大なグリッチは、「うるう秒障害」の間に検出されました。 そして、OpenNMS自体ではなく、データベースシステムに影響しました。 それ以外の場合、数年間の安定性に対する不満はありません。



複雑さ システムは複雑で複雑です。 サポートの観点から使用するのは簡単です-すべてが美しく、明確であり、iPhone [x]のクライアントもあります。 しかし、チューニングプロセス（特に初めて）は、多くの神経細胞を簡単に燃やすことができます。 ドキュメントはシステムの基本的な側面のほぼすべてをカバーしていますが、不快な機能に注目する価値があります。多くの記事には以前のバージョンに関する情報が含まれています。 論理的には、この理由は理解できます。このような統合システムの関連性を維持することは簡単な作業ではありません。 しかし、これは私たちの生活をまったく簡素化しません。



柔軟性。 システムを理解したら、イベント、ラダー、および監視用モジュールを接続できます。 機器がSNMPまたはHTTPを介してパラメータを提供する場合、監視することができます。 RRDのデータストレージを使用すると、通常のRRDTool構文でグラフの外観を柔軟にカスタマイズすることができます（デフォルトでは、見栄えがよくありません）。 しきい値を超えると、通知とアラームの形式で処理されます。 外部システムは、OpenNMSからReSTを介して、またはデータベースから直接データを受信できます。







「なぜシステム名％ではないのか？」という質問に答えることはできません。異なる監視システムの比較分析は意図的に行いませんでした。仕事に時間がかかりすぎます。 システム自体に関する質問に喜んでお答えします。トピックが多かれ少なかれ関連している場合は、この入門資料の中でユーザーケースの例を作成できます。