ゼノスの最も単純なモデラーまたは明るい未来への汚い道

モニタリング

（緯度モニター -思い出させる、警告する人から）-否定的な変化を特定し、それらの除去または緩和のための勧告を行うために、環境の状態の変化を評価および予測する、規制された定期的な観測の包括的なシステム。

はじめにと一般的な言葉

この監視システムは、競合他社のほとんどの機能よりもはるかに優れていますが、驚くべきことに、このハブに関するzenossの記事はほとんどありません。 システム自体の説明は、常にZenossの公式Webサイトで見つけることができます。



Zenossが競合他社よりも優れていると思うのはなぜですか？ 必要な監視システム、アラート、およびアラートへの応答を簡単に構成および受信できるためです。 Zenossは、柔軟性、機能、および複雑さをインテリジェントに組み合わせます。 後者はニーズに比例して大きくなります。ハードドライブのスペースを追跡するのは光よりも簡単で、独自のメトリックを使用してハードウェアとソフトウェアシステムを監視するのははるかに困難です。



ネットワークには、システムの初期セットアップに関する多くのガイドがあります。 これらのガイドを読んだ後、主要なパラメーターに従ってサーバーまたは通信機器の監視を簡単に開始できます。

ハードウェア上のsnmpサーバーでzenossを使用することを好みます。 SNMPサーバー-構成が簡単（名前がプロトコル自体だけでなくシンプル）;信頼性が高く、提供された情報および一般的なソフトウェアへの基本的なアクセス権をマークできます-一般的なソフトウェア。 さらに、snmpは、何らかの形で、ほとんどのハードウェアでサポートされています。

エージェントを使用したシステムの監視は、私を少し緊張させます。このエージェントで何が行われているか、そしてどれだけうまくやっているかはわかりません。

必要なパラメーター用の標準SNMPエージェントがない場合は、net-snmpに組み込まれたagentxメカニズムに基づいて独自のSNMPエージェントを実装できます。 Agentxエージェントの詳細については、ガイドwww.net-snmp.org/tutorial/tutorial-5/toolkitを参照してください（同僚の提案： code.google.com/p/linux-administrator-tools/source/browse/#svn%を参照することをお勧めします2Fsnmpd-agent％2Ftrunk ：ドキュメントは不十分ですが、コード全体が機能しています。）少しの努力で、システムからステータスをプログラムで取得し、標準のsnmpサーバーを介してsnmpでこの情報を送信できるすべてを監視できます。



したがって、このエントリでは完全と見なすことができます。 要約：zenossとsnmpが好きです。 より密度の高いゼノスに移りましょう。

自分用にZenosを構成する

最も単純なzenoss構成パスは、他の監視システムの構成パスに従います。

• デバイスを追加
• 制御された主要パラメーター
• デバイスごとに繰り返す

2つのスイッチと5つのサーバーがある場合、これは簡単に一度だけ実行されます。 数十台のサーバーがあり、一部が「回転」している場合（たとえば、ネットワーク上に仮想マシンがあり、不要になったらオフにする）、デバイスの追加と削除とパラメーターの監視は大変な労力になります。



したがって、zabbixやzenossなどの最新の監視システムには、デバイスを自動的に検出する機能があります。検索するIPアドレスの範囲を設定し、パラメーターにアクセスし、見つかった機器をシステムに追加します。 監視テンプレートをハングさせることは残っています。

テンプレートを切ることも悲しいことです。 ホストをグループまたはクラスにマークし、それらにテンプレートをハングアップします。 その後、デバイスのクラスを判断するだけで十分であり、対応する監視ルールがデバイスに適用されます。



「ランダムに」ホストにハングする12個のルールがある場合はどうなりますか？ そのため、デバイスクラスを明確に構成することはできません。 さらに進んで、システムに監視テンプレートを割り当てるためのルールを説明できます。 Zenossでは、監視構成を決定するプロセスは「 デバイスシミュレーション 」と呼ばれます。zenossはsnmpサーバーをポーリングし、使用可能なパラメーターを決定し、監視ルールがある場合はそれらを監視します。



監視ルール自体はZenPackによって提供されます。 Zenpackは、標準機能のネイティブ拡張を配布する方法です。 イベントクラス、監視テンプレート、モデラープラグイン、インターフェイスボタンの説明などが含まれます。



監視機能を拡張する正しい方法は、ホスト上の特定のコンポーネントの存在を判断し、それらにスケジュールとイベント（イベント）をバインドすることです。 右のzenpackはそれほど複雑ではありませんが、ボリュームがあります。 誰もが長い間何かを発明することに同意するわけではありません。 物事を成し遂げるための「迅速で汚い」方法を示します。

基本コンセプト

モデラーによる独自のコンポーネントとプラグインの作成は困難です。 監視パターンをどこでも手でハングアップ-長時間。 これらの2つのアプローチを組み合わせましょう：それらの短所は利点を提供します：モデラーはシンプルになり、私は彼のコードを与えます、そして一度作成されたテンプレートは自動的にデバイスにハングアップします：監視テンプレート。



なぜ速いのか ：2つのテンプレートと1つのモデラーを作成し、デバイスの最初のクラス（デバイス->サーバー）のモデラープラグインを構成する必要があります。 高速、シンプル、簡単、ポータブル（ZenPackを使用）。

なぜ「汚れている」のか ：LSI RAIDコントローラを監視します。 最初で唯一。 そのようなコントローラーが多数ある場合、それらは監視システムでカバーされず、別個のテンプレートとモデラーを作成する必要があります。 独自のコンポーネントを作成するアプローチはより柔軟です。「lsiディスクコントローラー」コンポーネントを記述し、そのようなコントローラーをすべて検出して監視します。

実装

SNMPパート

そのため、LSI RAIDコントローラーを備えた複数のLinuxサーバーがありました。 それらの一部はメガレイドドライバーに取り組み、一部はmptsasに取り組みました。 いくつかの苦労の後 、アレイの状態に関する情報を取得するSNMPエージェントを見つけました： sas_snmp-3.17-1123.i386.rpmとsas_ir_snmp-3.17-1126.i386.rpm （はい、32ビット、他はありませんでした）。 それらをインストールした後、snmpサーバーはツリーからoidを与えることができます

.1.3.6.1.4.1.3582.4および.1.3.6.1.4.1.3582.5それぞれ。

これらのツリーの中には次のものがあります。

1.3.6.1.4.1.3582.4.1.4.1.2.1.19.0 -megaraidアダプターの劣化した論理ボリュームの数

.1.3.6.1.4.1.3582.5.1.4.1.1.3.1.20.0 -mptアダプターの劣化した論理ボリュームの数。



これらは、問題が発生した場合にシステム管理者がサーバーに注意を払うことを可能にする優れた「統合」メトリックです。ディスクが流出した-含まれる論理ボリュームが劣化し、メトリックをゼロから引き上げます。



パッケージのインストールについては説明しません。パッケージの名前と、sas_snmpとsas_ir_snmpの違いを知っていれば簡単です。

ゼノス部

Zenossでは、megaraidおよびmptドライバー用の2つのテンプレートを作成し、それらに対して2つのしきい値を構成する必要があります。



[詳細]-> [監視テンプレート]に移動し、下の[+]ボタンを押します。 表示されるウィンドウで、名前「lsiArray」を入力し、パス「Server in Devices」を選択します。



その後、ウィンドウは3つの部分に分かれて表示されます。データソース、しきい値、グラフ定義です。 最初の2つが必要です。

• データソースを作成します。 mibのように「vdDegradedCount」という名前です（ただし、可能です）。 ソース-SNMP
• 新しく作成したデータソースを編集しています。最初のOIDを入力します。 同じウィンドウで、任意のサーバーでテストできます
• しきい値を作成し、「LSI Degraded virtual drive count」という名前を付けて、MinMaxTresholdと入力します
• 作成したしきい値を編集します。唯一のデータポイントを選択し、最小値と最大値を0に設定し、イベントのクラスを指定します（I selected / HW / Store）。 アラートを設定するときに必要なイベントクラス

これらすべてのアクションの後、megaraidコントローラーを監視し、問題が発生した場合にイベントを生成するテンプレートがあります。

2番目のテンプレートの構成は読者の演習として残しておきます。これについて複雑なことは何もありません。

このイベントのメッセージ送信を設定できます。 [詳細設定]-> [設定]-> [ユーザー]-> [$ユーザー]-> [アラートルール]に移動し、そこに新しいルールを追加します。 私たちは精神で何かを修正し、取得します：





イベントの「重要性」の兆候と、アラートが生成されるイベントのクラスチェーンの始まりに注意してください。



この段階で、結果のテンプレートを特定のクラスのデバイスにハングアップして落ち着かせることができます。 しかし、これは私たちの方法ではありません。 さらに、最も興味深いのは、その最も単純なモデラーとzenpakです。

モデラープラグインの作成。

これが最も興味深いです。 独自のZenpackを作成してください！ Zenpackは、モデラーのプラグインのソースコードを配置するために必要なディレクトリ構造を作成します。 さらに、このZenpackの一部としてシステムからプラグインをアンロードできます。

そこで、[詳細設定]-> [設定]-> [Zenpacks]に移動して、ギアをクリックします。 表示されるメニューで、「Zenpackの作成」を選択します。 ウィンドウに名前が表示されます。 ZenPacks.HW.Store.LSIArrayを選択しました。 ただし、後で判明したように、これはまったく正しい名前ではありません。少なくともHWの前にコミュニティという単語を入力する必要がありました。



zenpakaを作成すると、ネジに標準のファイルツリーが表示されます。 次の内容でファイル/opt/zenoss/ZenPacks/ZenPacks.HW.Store.LSIArray-*egg/ZenPacks/HW/Store/LSIArray/modeler/plugins/LSIArray.pyを作成する必要があります（作成されたクラスのアスタリスクを修正します）。

__doc__="""LSIArray LSIArray modeller maps sas and sasir (mptsas) specific templates $Id: LSIArray.py,v 2.00 2012/04/15 16:01 Exp $""" __version__ = '$Revision: 2.15 $' from Products.DataCollector.plugins.CollectorPlugin import SnmpPlugin, GetTableMap, GetMap from Products.DataCollector.plugins.DataMaps import ObjectMap class LSIArray(SnmpPlugin): deviceProperties = SnmpPlugin.deviceProperties + ('zDeviceTemplates',) mibDesc = { '.1.3.6.1.4.1.3582.4.1.4.1.2.1.19.0': 'lsiArray', '.1.3.6.1.4.1.3582.5.1.4.1.1.3.1.20.0': 'lsiirArray', } snmpGetMap = GetMap( mibDesc ) def process(self, device, results, log): """collect snmp information from this device""" log.debug(str(self.deviceProperties)) log.info('processing %s for device %s', self.name(), device.id) getdata, tabledata = results log.debug(str(device.zDeviceTemplates)) newTemplates = [] rmTemplates = [] log.debug('getdata %s mibDesc %s', str(getdata),str(LSIArray.mibDesc)) if len(getdata.keys()) == getdata.values().count(None): log.info('no data') return for each in LSIArray.mibDesc.values(): if getdata.has_key(each) and getdata[each] != None: newTemplates.append(each) log.debug('newTemplates append: %s' % each) else: rmTemplates.append(each) log.debug('rmTemplates append: %s' % each) log.info('Current zDeviceTemplaces: %s' % str(device.zDeviceTemplates)) for each in device.zDeviceTemplates: if each not in newTemplates and each not in rmTemplates: newTemplates.insert(0,each) log.debug('adding to newTemplaces: %s' % str(each)) device.zDeviceTemplates=sorted(newTemplates) log.info('New zDeviceTemplates: %s' % str(device.zDeviceTemplates)) om = self.objectMap({'bindTemplates': newTemplates}) return om
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ソースコードでは、すべてが非常に単純です。

最初は、クラスが何をするかを説明するコメントです。

次に、いくつかのzenossクラスをインポートして、デバイスモデルを記述します。

mibDescオブジェクトが最も興味深いです。 OIDのリストとそれに対応する監視テンプレートが含まれています。 デバイスのポーリング中に正しいOIDが見つかった場合、新しい監視テンプレートがデバイスでハングします。

サンプルを自分で編集するときは、テキスト内のすべての句読点を見逃さないようにしてください。

次は、すべてのチェックと比較を実行し、以前のすべての監視テンプレートを保存してリストに追加するメソッドです。 このメソッドの結果はオブジェクトモデル（om）です。

プラグインチェック

モデラーのテキストをコピー、修正、保存した後、zenoss（詳細->設定->デーモンのzopectlプロセス）を再起動し、LSIArrayと呼ばれるモデラープラグインのリストに新しいデバイスが表示されることを確認する必要があります（デバイスクラスのモデラープラグインまたは任意のデバイスで）。 プラグインをアクティブなプラグインに転送して、デバイスのモデリングを開始する必要があります。

画面に表示されるウィンドウで、モデラーがデバイスに使用されるリストにあることを確認する必要があります。 さらに、LSIArray.pyファイルがハードディスク上に作成され、スクリプトのコンパイルが成功したことを示します。

スクリプトがコンパイルされていない場合は、Pythonコードの正確さを確認してください。

スクリプトがアクティブまたは利用可能なモデラーのリストに表示されない場合は、zenossを再起動します。



シミュレーションプロセスの後、新しい監視テンプレートをデバイスに追加する必要があります。 これで、テストサーバーからハードドライブを取り外して取り外すことができます。これにより、アレイの状態が「通常」から「劣化」に変換されます。 （もちろん、RAID0がない場合）。 劣化した論理ボリュームの数が増え、しきい値を超え、システムがイベントを生成します。 アラートを設定した場合、アラートが送信されます。

おわりに

上記の方法により、いくつかの重要な結果を得ることができます。

• Zenossで自動構成監視の使用を開始する
• モデラー用の独自のプラグインの作成方法の理解を開始します
• より柔軟で最新の監視システムとしてzenossの使用を促進します。

Zenpackとモデラーを作成するための、より完全で「正しい」ガイドがあることをよく知っています。 ただし、このテキストが多くのシステム管理者がシステムでzenossの研究と使用を開始するきっかけになることを願っています。