目次 表示
このセクションでは、開発者のガイドとして、Foundation Data Store 内の統合監視データについて説明します。
Foundation は、IT 管理データ抽象化の層であり、開発プラットフォームです。Foundation のデータモデルはデータを作成する監視アプリケーションから独立したステータス、イベント、性能データの統合を可能にします。これはオープンソースと商用の監視システム、データベース、検知システムやセンサーのようなハードウェアを含む追加システムのためのデータを保存する可能性を提供します。これは、MBeans として知られるアプリケーション監視データの統合も可能にします。
Foundation の意図は、IT インフラストラクチャが求める監視のコンポーネントを統合するデータモデルを提供することです。統合データを保存する柔軟な方法により、さまざまのツールやアプリケーションおよびデータベースが Foundation にデータを送り込めるようにします。Foundation はそのデータを正規化するので、データは一定の方法で検索することができます。そして Foundation は正規化されたデータを取得することができる多様な API を提供します。Foundation のパッケージはメインの監視システムとして、Foundation に統合された Nagios や Foundation API が、リアルタイムの画面やリポートを提供するために使用するアプリケーション群を含んでいます。
WEB サービスインタフェースが、既存の Foundation フレームワークに新たに追加されました。以前の API コンポーネントは WEB サービスインタフェースを使うために再パッケージされており、置き換えられてはいません。下のポップアップ図は、さまざまな Foundation コンポーネントとそれらの関連性を示します:
Perl、PHP、Webサービスの API はツールキットの一部分です。Perl API は Perl プログラムが Collage からデータを取得することを可能にする CollageQuery と呼ばれるモジュールです。GroundWork のPHP API は 、Foudation データベースソースへのアクセスとそのソース内にある情報へアクセスするためのオブジェクトライブラリを提供します。ライブラリはコネクションとクエリタイプのクラスに分けられます。ウェブサービス層の追加は、より多くのアプリケーションの使用、既存のFoundationフレームワークへの統合を可能にします。
さらに Foundation1.5 の統合機能は同じようなメッセージに対するエントリーの作成、メッセージカウンターの増加、date フィールドの調整により、LogMessages の数を減らすことができます。API の実際の実装は、GroundWork Monitor インストールの一部です。
プログラマーは、以下の目的でPHP、Perl、WebサービスAPIやサードパーティ製品を使用できます:
カスタマイズされたリアルタイムでの監視情報表示画面の作成
監視情報履歴からのカスタムレポートの作成
監視情報をシステムに提供することによる機器やシステム監視の追加
種々のシステムからの情報を単一画面へ統合
中継システムとして GroundWork Monitor Foundation を使用することによるさまざまなシステムの統合
Foundationは、Jetty サーブレットコンテナへの Web アプリケーション(.war)としてパッケージ化され、配置されています。Jetty は、完全に Java で構築されたオープンソースで標準ベースの、フル機能を持った軽いサーブレットコンテナです。Foundation アプリケーションに加えて、Groundwork のインプリメントには、以下の Web アプリケーションを含んでいます:
GroundWork レポートサーバと Eclipse BIRT Report Designer で作成された BIRT レポートの起動と管理を可能にするEcliplse BIRT Viewer
GroundWork JMS。オープンソースプロジェクトである JORAM を基にしたフル機能の持続性のあるトピックサーバです。
GroundWork Monitorのプロフェッショナルバージョンは、Web アプリケーションとして構築されたコンソールを含んでいます。
Monarch ツールは、Nagios システムを設定するために使用される Web アプリケーションです。それ自体のデータベースを持ち、Nagios の構成設定データを保存します。この時点では、Monarch データベースは Foundation データベースと分かれています。Monarch の設定を承認したとき、新しい構成設定は Foundation と同期を取ります。
Nagios はこのパッケージに統合されているため、Nagios プラグインによって収集された情報はシステムに統合されます。Nagios Feeders(オープンソース版)、Event Broker(GWMP)は Nagios から情報を取得し、それを Foundation のデータベースに入れます。Foundation が持っているデータオブジェクトは 、Nagios オブジェクトに近い形でマッピングされ、含まれます:
表:データオブジェクト
Host Groups |
メンバとしてのホスト |
Hosts |
通常Nagiosが物理機器にマッピングされる監視エンティティを表します。 |
Service |
これは、特定のホストに対する Nagios サービスチェックの典型的な表現です。ホストとサービスの組み合わせは監視インスタンス上、ユニークなものです。 |
以下のような情報タイプが取得できます:
表:データオブジェクト
Host Status |
ホストオブジェクトの現在ステータスと属性を表します。 |
Service Status |
サービスオブジェクトの現在のステータスと属性を表します。 |
Events |
監視システムや管理機器から生成されたタイムスタンプが押されたメッセージです。 |
Host Alerts |
ホストの状態が変化した際に生成されるイベント。 |
Host Notifications |
Host Alert イベントを基にして通知が発生した際に生成されるイベント |
Service Alerts |
サービスの状態が変化した際に生成されるイベント |
Service Notifications |
Service Alertイベントを基にして通知が発生した際に生成されるイベント |
Nagios Acknowledge |
ユーザのメッセージを確認した際に既存の Host、Service Alert の状態がアップデートされます。 |
Foundation フレームワークの上部に作成された API によって、この情報の検索が可能になります。その API は、プログラムがオブジェクトやデータタイプでの問い合わせを行うことを可能にします。Java、PHP、Perl プログラムに対応した個別 API があります。提供されたサンプルに加えて、Foundation のステータスビュー(Overview, Netview, Trouble View, FilterView)は PHP Foundation API を使用して作成されています。
Foundation フレームワークは、5つの主要なコンポーネントから構成されています。上の図形表示アイコンを選択すると、Foundation コンポーネントが表示されます。
Feeders(フィーダー) - これらはFoundation リスナーに送られるデータセットを生成するスクリプトやプログラムのことです。プロトコルはXMLです。
Foundation Listener(Foundation リスナー) -これは色々なフィーダーからの XML を受信し、それらをアダプターと呼ばれるデータ正規機能に送るJava Message Service(JMS)リスナーかポートのことです
Foundation Adapters(Foundation アダプター) - ルールを適用し、入ってくるデータを正規化するFoundationフレームワーク内にあるプログラムです。
それぞれのアダプターはアプリケーション固有で(例:NagiosEvent、SNMP、Syslog)、フレームワークで簡単に追加や管理ができます。
Foundation Persistence Service(Foundation パーシスタンスサービス) - これはデータベースやデータベースクラスタの上部で、稼動する関係パーシスタンス層です。
Foundation API - これは、データの保存場所からデータを取得するのに使用される PHP および Perl に対する API のドキュメント化です。
通信のデータフローは、Foundation のフレームワークは入っている XML に応答しないので、単方向性です。
図: Foundation のコンポーネント
通信のデータフローは、Foundation のフレームワークは入っている XML に応答しないので、単方向性です。
図: Foundation データフロー
データを Foundation フレームワークに統合するために、ソースアプリケーション(例:Nagios、Java Management Extensions(JMX)サービス)によって生成されたデータは読み込まれ、XML としてリスナーの1つに送信される必要があります。この機能はフィーダーによって提供されます。Feeder はどのような言語ででも作成可能です。例えば、Nagios フィーダーは Perl で書かれています。XMLの出力プロトコルは簡単です:
<フィーダーName AttributeName='AttributeValue' AttributeName='AttributeValue' ... />
FeederName はアダプターの名前と一致し、その属性は単なる name 値のペアリストです。例えば、Nagios イベントフィーダーの XML は下記のフォーマットになります
<NAGIOSLOG MonitorServer='localhost' Severity='HIGH' TextMessage='Failed to check Host' />
フィーダーにデータの正規化ロジックを組み込ませることができますが、これは推奨しません。一番良いアプローチはデータを読み込み、それをリスナーに送るための簡単で汎用的なフィーダーを持つことです。正規化機能はアダプターで行うのが最も適切です。
XML 要素のシンプルなフォーマットは、同様にシステムにわたるひとつのトランザクションを象徴しています。高負荷の場合、トランザクションがオーバーヘッドによって、負荷がかかり、全ての通信スループットに影響を及ぼします。Foundation の最新バージョンは複数の通信を一つのトランザクションにまとめられる、より複雑な通信のサポートを含んでいます。それぞれのアダプターについて詳しくは "データ統合アプローチ" をご覧ください。
リスナーは 4913 番ポートか JMS トピックをリッスンする単純なサービスです。入ってきた XML メッセージは分析されて、XML 要素(例:FeederName と一致するアダプター)内での定義に従って該当するアダプターに送られます。
アダプターは、データ欠落がないことの妥当性チェックのために使用することができます。システムの性能に影響するので、パーシステント層で拒否される前に不完全なあるいは誤ったデータを受け付けないようにすることができますし、そのように使うべきです。
アダプターは Java で書かれ、jar ライブラリパッケージにコンパイルされます。パッケージには初期時に、Foundation フレームワークに読み込まれる Spring のアセンブリファイルを含んでいます。アセンブリファイルのシンタックスとアダプターの配置方法については、このドキュメントのチュートリアルを参照してください。
Foundation の統合機能により、同内容のメッセージについて単一エントリのみを作成し、カウンターをインクリメントして date フィールドを調整することによって LogMessages の数を減らすことができます。統合処理は、統合属性が定義されている Entity Type LogMessage のすべての入力メッセージに適用されます(例:consolidation='SNMPTRAP')。
統合の判断基準はデータベースに保存され、ユーザで定義可能な名前と判断基準から構成されます。判断基準はセミコロン(;)で区切った、LogMessage レコードのフィールドや PropertyNames のリストです。統合されるメッセージに対して定義された判断基準のフィールドのすべての値が既存のレコードと合致する必要があります。
入力メッセージは対応する統合判断基準の名前を定義しなくてはなりません。統合タグが欠けていた場合、システムのデフォルト動作として新しいログエントリーが作成されます。
デフォルトでは、統合は Nagios、SNMP、Syslogイベントに対して機能します。統合判断基準で定義されたフィールドが一致したとき、統合がおこります。上記の例外は、最後のイベントの監視ステータスが次のイベントの監視ステータスと異なり、新しいコンソールメッセージが作成された場合です。この方法によりコンソールメッセージが時系列にソートされ、以前のステータスの上に現在のステータスが表示されることを確実にします。
以下の統合判断基準は Foundation の ConsolidationCriteria テーブルで定義されています:
統合判断基準 |
使用されるフィーダー |
コメント |
NAGIOSEVENT |
nagios2collage_eventlog.pl |
Community Edition |
NAGIOSEVENT |
EventBroker |
Professional Edition |
SNMPTRAP |
snmptt forwarding traps to Foundation |
Professional only |
SYSLOG |
gw-syslog-feeder.pl |
Professional only |
GroundWork Monitor Community Edition と共に出荷されるフィーダーのための統合を無効にするために、Nagios イベントログフィーダー( nagios2collage_eventlog.pl )を編集して、統合を指定しないというメッセージを Foundation に通信を送ることができます。:
my $xml_message = "< NAGIOS_LOG consolidation='NAGIOSEVENT'"; # Start message tag. Consolidation is ON
以下のように変更してください:
my $xml_message = "< NAGIOS_LOG "; # Start message tag. Consolidation is now turned OFF
統合できるためには、イベントメッセージは下記のような形式で、その後に他の引数が続く必要があります:
<NAGIOS_LOG consolidation='NAGIOSEVENT'
NAGIOSEVENTのデータベース内の統合判断基準では、以下の基準を定義します:
Device;MonitorStatus;OperationStatus;SubComponent;ErrorType
あるイベントがシステムに取り込まれ、そして統合判断基準が定義されていたら、システムは、その Device、MonitorStatus、OperationStatus、 SubComponent や ErrorType について、既存のログメッセージがないか確認します:
一つの LogMessage オブジェクトのみ合致する場合
複数の LogMessage オブジェクトに合致する場合、その判断基準の定義を改善するべきである旨を示す警告がログされます。
既存の一つのメッセージとの合致する場合、既存メッセージに対するカウンターLogMessage.MsgCount がインクリメントされ、日付のフィールドが以下のようにアップデートされます:
データベースのフィールド |
適応される変更 |
FirstInsertDate |
変更なし |
LastInsertDate |
ReportDate |
ReportDate |
システム(現在の時間) |
TextMessage |
アップデートされたテキストメッセージ。ステータスとタイプが同じであっても、メッセージには変更するチェックの値(例:ディスク使用量85%)が含まれる可能性があります。 |
データをFoundationのデータ保存に統合する前に、以下のことを決める必要があります:
ソースアプリケーションからのデータ収集方法とFeederの書き方
データ正規化をどこに置くか(FeederかAdapter)
データモデルにあるデフォルトのフィールドが保存するのに充分なのか、それとも特定のアプリケーションプロパティを追加する必要があるかどうか。
データに対してどの ApplicationType を使用するか。ApplicationType は、単純なフィルターを使用してデータをアクセスすることを可能にするパラメータです。GroundWork Monitor では、このフィルターはコンソールアプリケーションビューの中に構築され、該当の ApplicationType でデータが存在する場合、自動的に提示されます。
複数メッセージを単一トランザクションにまとめるべきかどうかを考えます。ひとつにまとめると、より高いメッセージスループットを得られますが、関連する全てのデータが「全か無か」の状態になることを認めることになります。それにより、フィーダー開発の複雑さが増します。Foundation では XML スキーマ(ファイルへのリンク)の定義や SystemAdapter と呼ばれる新しいアダプターによってこの種のメッセージに対するサポートを提供します。Foundation の最新バージョンでは Nagios Status と Event Message の処理にこの手法を使用しています。
Foundation は、さまざまのデータフィードのタイプの一連のアダプター群を付属しています。アダプターは二つの異なったタイプに分類されます:
このタイプのアダプターは、XML のフィードフォーマット<ELEMENT atribute=value,.. />を受け取ります。それぞれの XML はトランザクションを表します。
Foundation は以下のアダプターをサポートします。
アダプタタイプ |
XML |
説明 |
NAGIOS Events |
<NAGIOS_LOG attribute,.. /> |
Nagios からのイベント |
Nagios Status |
<SERVICE_STATUS attributes,./> <HOST_STATUS attribute,../> |
ホストとサービスステータスのアップデート |
SNMP Trap events |
<SNMPTRAP attribute,.. /> |
SNMPTTデーモンから来るSNMPトラップのイベント |
SNMP Trap events |
<SNMPTRAP attribute,.. /> |
SNMPTTデーモンから来るSNMPトラップのイベント |
Syslog events |
<SYSLOG attribute,.. /> |
gw_syslogプラグインからのシスログメッセージ |
Generic Events |
<GENERIC_LOG attribute,../> |
属性をチェック無しで直接ダイナミックプロパティにマッピングする一般的なアダプター |
System messages |
<COLLAGE_LOG attribute,../> |
システムメッセージをコンソールへレポートします。 |
データフィードの好ましい方法は、異なるエンティティ(イベントやステータス)の複数のメッセージ送信を単一のトランザクションにすることができる SystemAdapter を使用することです。
この方法のメリット:
より高いメッセージスループット
SystemAdapter は、事前のフィード妥当性チェックのために XML スキーマを使用します。シンタックスエラーはサービス層で処理される前に検知されます。
Internet Exploere での 、XML スキーマ閲覧: SystemConfig.xsd
依存性のあるメッセージを、単一のトランザクションにまとめます。何らかのメッセージ障害の場合、全てがロールバックされ、データ氏得合成を保証します。
SystemAdmin アダプターを使用したフィードの使い方と設定方法についての情報は データフィーダーの構成設定 内の例を参照してください。
前の章で述べたように、フィーダーは Foundation のリスナーサービスの一つに送られる XML ストリームを作成しなくてはなりません。もしFeeder が正規化を行うか、インプットデータがシンプルでデータモデルプロパティと一致する場合、フィーダーはデータをGeneric アダプターに送ることができます。Generic アダプターは値を確認せずに、データベースプロパティに送られた属性値をマッピングします。
Generic アダプターへのデータのフィード方法の例は、LOG4Jのフィーダー作成とログアダプターの使用方法 で参照可能です。
あなたのアプリケーションのためにデフォルトの Status と Event データフィールドに加えて、より多くのプロパティを保存する必要があると判断した場合、以下のステップを行う必要があります:
PropertyType テーブルに新しいプロパティとタイプを追加します。
プロパティをLOG_MESSAGE、SERVICE_STATUS、 HOST_STATUSといった EntityType と関連付けます。
データに対する ApplicationTypeを定義してください。
GroudWork Foundation の現在のバージョンでは、上記のデータベース操作は SQL ステートメントで実行する必要があります。これらの方法は Admin Feeder の次のバージョンでサポートされます。それは、入力ストリームを介してのプロパティの動的追加を可能にします。
カスタマイズされたプロパティは、Generic アダプターを使用して追加することができますが、整合性チェックが行われないため、プロパティが不足している入力メッセージは拒否されます。
多数のデータフィードには入ってくるデータ(全ての要求されたフィールド、収集タイプ)の妥当性を確認するアダプターの構築が推奨されます。これにより、トランザクションのロールバック(負荷がかかるミドルレイヤーでの操作)を引き起こすエラーが事前に検知され、拒否されることを確実にします。
フィーダーはシンプルで、可能な限り汎用的であるべきです。データポイントを収集し、正規化のためにアダプターに送信します。Perl のようなインタプリタ言語で書かれている場合に非効率になる可能性があるフィーダープロセスの並行稼動による負荷を減らします。
SystemAdapter をできるだけ常時使用してください。パフォーマンスの強化と通信の検証はシステムをより強固なものにします。