square.gif Auto Discovery(自動検出)

homeicon.gif Print Page commentsicon.gif

Automation Subsystem (自動化サブシステム)

目次 表示

自動化サブシステムについて

検出サブシステムから独立して(上記セクションで説明したように)、自動検出サービスは、GroundWorkMonitorの構成データベースに構造化された情報を取り込むのに使用する"Automation(自動化)"サブシステムも提供します。このサブシステムを使って、管理者は自動検出サービスに簡単なテキストファイルからの入力データを読み込ませ、そのデータで構成データベースを同期させることができます。

実際、自動化サブシステムは、検出プロセスの結果を構成データベースに取り込むことが必要な時はいつでも、検出サブシステムによって、この目的のために使用されます。しかし、自動化サブシステムはこのような使われ方だけに限定されず、適切な入力ファイルを生成できるどのようなデータソースでも構成データベースの同期に使用することができます。

GroundWork Monitorは検出プロセスのために、オプションと変数を保存するのに検出定義を使用するのと同様な方法で、特定の自動化プロセスに対する構成オプションを保存するためにスキーマ定義を使用します。このモデルで管理者は、個別の自動化プロセスを上手く実施するために、必要なオプションを保存する個別のスキーマ定義によって、必要となるであろうデータ取り込み、プロセスそれぞれのために異なる自動化定義を作成することができます。

例えば、管理者は自動化サブシステムにホスト名とサービス定義のために検出ログを読み、検出されたデータで既存の構成データベースのエントリを更新するよううに指示するスキーマ定義を作成することができます。一方、他のスキーマ定義を作ることができます。自動化サブシステムに入力データを元に構成データベース全体を再生成させるスキーマ定義を作成することができます。これは、構成情報を外部の管理システムから取り込む場合などに便利でしょう。ひとたび、これらのスキーマ定義が作成されたら、管理者は、業務にもっとも適したスキーマ定義を選ぶことで、適したオプションが既に選ばれた状態で、すぐに関係付けられた自動化プロセスを開始することができます。

検出定義と同様、スキーマ定義は、最初から最後までの取り込み処理全体を記述し、全体プロセスを完了させるのに必要なすべてオプションを盛り込みます。より具体的に言えば、各スキーマ定義は実行される同期の形式、入力ソースファイル、入力ファイルのレイアウトについての記述、および入力ファイルに適用する処理ルールを規定するオプションを含みます。これら要素については、以降のセクションで詳しく説明します。

自動化プロセス

簡潔にいうと、自動化サブシステムは入力ファイルのテキスト形式の行を読み、各行をデータのフィールドに分けます。各フィールドは入力ファイルから抽出されるので、次にそのデータに何をするか(GroundWork Monitor の構成データベースのフィールドの中にマッピングするか、廃棄するか、など)のひとつ以上のマッチングルールが記述されます。すべての入力データが構文解析と分析され終えたら、自動化サブシステムは最終結果をオペレータに確認してもらうために表示し、そして、その最終結果で構成データベースを更新します。

この処理を正しく機能させるため、GroundWork Monitor は入力テキストが行で区分された形式で、各行がロー(データベースの行:raw)に対応することを要求します。GroundWork Monito rは入力データが固定幅のカラムを必要するのではなく、その代わり、固定数の可変長フィールドを持つデータであることを前提としています。このモデルでは、入力ファイルの各フィールドは、隣のフィールドとユーザが定義した文字列(CSVファイルから取り込んだ際のコンマなどの一文字や、複数文字、あるいは必要ならば正規表現も使えます)で、分離されていることが必要です。

管理者は、各ローのデータ内にあるフィールドと、取り込まれたデータの各フィールドに対して適用する処理ルールを定義する必要があります。自動化サブシステムが各フィールドを読んで、そのデータを概念的なスプレッドシートと同じようなテンポラリのロー枠とカラムにマップします。このモデルでは、各ローのデータは、ひとつのレコードを含み、各カラムは、各レコードからの各データ部分を含むローとカラムの交点(セル)によって、特定のデータの一部を特定します。

一方、各論理カラムはそれに割り付けられたひとつ以上の処理ルールを持ち、それらが自動化サブシステムに入力ファイルから指定されたフィールドが取り込まれた時に何が起こるべきかを指示します。これらのルールはデータを取り扱ったり、廃棄したり、GroundWorkMonitorのデータベースのフィールドにマッピングなどをするでしょう。各カラムは、複数の処理ルールを持つことができ、各ルールはそのカラムのすべてのルールが実施終わるまで順番に実行されます。

すべての入力データが取り込まれて処理された後、最終結果が、オペレータの確認のために表示され、そしてGroundWork Monitor の構成データベースに挿入されます。

どのように動くかについて、下記のサンプル入力を使って説明します:

cisco-router, 192.168.10.1, snmp

windows-server, 192.168.10.21, wmi

linux-server, 192.168.10.34, ping

上記のサンプルの中には3ロー(行)のテキストのデータがあり、各ローにはホスト名、IPアドレスおよびホストプロファイルを含んでおり、それぞれは隣とコンマで区分されています。このデータを自動化サブシステムで活用するため、入力ファイルの位置、使用するフィールド分離記号(ひとつのコンマ)、ソースデータ(ホスト名、IPアドレスとプロファイル)の論理カラムと各カラムについての処理ルールを指定するスキーマ定義を作成する必要があります。

適切なスキーマ定義が作成されたら、自動化サブシステムは自動化プロセスを実施するためにそれらの設定を使います。このやり方の中では、自動化サブシステムは分離記号を見つけるために、指定された入力ファイル内の各ローのデータを確認し、各フィールドから対応するデータを取り込み、各カラムに対して定義されているマッチングルールを適用し、そして各ローのデータに対してこの処理を繰り返します。入力ファイル全体をすべて読み込み終えたら、自動化サブシステムは最終的に取り込んだデータで構成データベースをアップデートする前に、その結果を管理者のレビューのために表示します。

上述の簡単な例はいくつかの限定的な応用でしか活用できませんが、GroundWork Monitor で提供しているデフォルトのスキーマ定義はもう少し複雑で、ホストとサービスのプロファイルを構成データベースと同期する必要がある処理のために使われるべきものです。具体的にいうと、デフォルトのスキーマ定義は、下記のカラムレイアウトを使い、各フィールドは隣と二つのセミコロン文字で区切られます:

name;;address;;alias;;hostgroup;;contactgroup;;parent;;profile;;service

注意:ホストのレコードには、そのレコードを特定のデバイスと関連付けるために、必ずホスト名と IP アドレスフィールドが含まれていなかればなりません。入力レコードにこれらのデータが含まれない場合、前のレコードの更新情報であると解釈されてしまい、カレント(現在)レコードとなっているそのデータは前のレコードとして収集されたデータに追加されたり、上書きしたりされます。このやり方は意図的なものであり、複数の検出方式で補足データを追加したり、データが検出されたら追加の詳細をホストデータに書き込むことができるようにします。

実例を提供する目的で /usr/local/groundwork/core/monarch/automation/data/sample-multiline.txt にこの概念を実地説明するサンプルの入力データを入れています。このファイルは、デフォルトのスキーマ定義を使って検出方式によって作成される入力データの典型です。

同期方式

自動化プロセスの重要な特徴は、入力データと構成データベースが相互に同期する方法です。通常の筋書きでは、管理者は、単に新規レコードを追加したり、既存レコードを更新したりすることを望むでしょう。しかし時には、とりわけ異なる管理ツールがネットワーク資源や資産の主要な管理ポイントである場合は、構成データベース全体を壊して再生成することが望ましい、あるいはその必要があるかもしれません。

同期行動は、スキーマタイプのオプションで規定されます。あるスキーマタイプは、すべてのスキーマ定義のために設定する必要があります。この設定は他の構成オプションに影響を与えるため、スキーマタイプは新しいスキーマ定義が最初に作成されたときに必ず設定される必要があり、スキーマ定義に関係付けられたスキーマタイプは、それが作成された以降は変更できません。

自動化サブシステムの中では、下記の3つのスキーマタイプが使用できます:

表:スキーマタイプ

host-import

host-import スキーマタイプは、新規の構成エントリを構成システムに追加し、既存のホスト構成エントリを更新することができますが、それ以外の既存の構成エントリを変更することはできません。

host-import スキーマタイプ は、検出プロセスのためのみに使われるスキーマタイプであり、他のスキーマタイプがより適切であると分かっていない限り、通常ほとんどの自動化タスクで使われるべきです。

host-profile-sync

host-profile-sync スキーマタイプは、スキーマ定義が実行されるたびに破壊的に入力ファイルの内容で構成データベースを同期し、効果的に構成データベース全体の再生成を行います。このスキーマタイプは、(Cactiなどの)異なる管理ツールがプライマリの構成情報源である場合を意図しています。このスキーマタイプの破壊的な性質を考慮して、非常に用心して使う必要があります。

other-sync

other-sync スキーマタイプは、既存の構成エントリを変更するのみで、新しいエントリを追加しませんし、破壊的に構成データベースの再生成を行いません。これは構成エントリをまとめて変更するのに使用することを意図しています。例えば、指定したホストエントリに対するコンタクトグループを変更したり、コンタクトグループ自体を変更するのに使用できます。

マッチングルール

入力ファイルが自動化プロセスに読まれたとき、各入力レコードは分析されて個別のデータフィールドに分割されます。そしてそれは取り込まれ、中間構造体の中の対応するカラムに割り当てられます。各フィールドがそれらのフィールドに割り当てられると、ひとつ以上のマッチングルールがそのデータに何が起こるかを宣言したルールがデータに適用されます。

最も簡単な筋書きでは、カラムの中のデータは、構成データベースの中のエントリを作成したり、更新したりするのに使われる GroundWork Monitor 構成データベースのフィールドにマップされます。しかし、これは非常に簡略された筋書きであり、さまざまの異なった実現可能なアクションがあります。例えば、デフォルトのスキーマ定義は、コメントと重複ホストを廃棄するオペレーティングシステム識別子に従って、デバイスタイプをホストグループにリンクするなどのマッチングルールを含んでいます。この仕事すべては、異なるマッチングルールによって実施されます。

技術的には、マッチングルールは条件付き処理ルールであり、伝統的な"if-then"ルールに似ています。条件付き処理は、事前に定義されたアクションの文字列比較機能を使うことによって実施されます。例えば、「もしデバイス識別子が'linux'であれば、そのデバイスをホストグループ'Linux Servers'に関連付ける」というルールを書きつつ、他の「もし最初の文字が'#'であればレコード全体を廃棄する」というルールを書くことができます。

条件付処理のフィルタが一致したら、マッチングルールのアクション部分が実行されます。これが自動化システムが実際に行うことです。最も一般的なアクションは、そのフィールドの値をホスト名に割り当てるなどの単純な作業に便利な、GroundWork Monitorにそのフィールドのデータを直接使うように指示する簡単な宣言文です。しかし、それらの一部がそれ自体の追加の条件付き処理フィルタを含む、より複雑なアクションも提供されます。例えば、いくつかのルールでは、構成オブジェクトが既に存在するかを確認し、その二次評価の結果に依存して異なるアクションを行が行われます。

各マッチングルールは、ただひとつだけの文字列比較機能とただひとつのアクションを持ちますが、複数のマッチングルールを単一のカラムに定義できます。この筋書きでは、異なるそれぞれのマッチングが順番に、すべてのルールが処理されるまで行われます。

より具体的に言うと、各マッチングルールはいくつかのルールでは追加の構成データが必要で、より多くのオプションがありますが、最低限4つの構成オプションから構成されます。しかし、マッチ・フィルタとルール・ディレクティブが最も重要な二つです。

一致フィルタ

マッチ属性は、現在のマッチングルールのため、条件付処理フィルタを保存(つまり、if-then 宣言文の "if" の部分を保存)します。マッチングルールの残り部分はこの比較が「真」の結果であった場合に処理されるだけです。フィールドデータがフィルタに一致しなかったなら、それより先の他のマッチングルールでそのデータがそのルールのフィルタに合致して処理されたとしても、そのデータは現在のマッチングルールでは処理されません。使用可能な比較タイプは以下のとおり:

表: 比較タイプ

use-value-as-is

比較は行われず、フィールドが空であってもマッチングルールは常に実行されます。これは、条件付処理が常に「真」を返すのと基本的に同じです。

is-null

データがない場合のみ、マッチングルールが実行されます。これは、元の入力が空のフィールドを渡したときか、そのカラムのために先行のマッチングルールによって内容が削除されたために発生します。

exact

フィールドと指定された文字列に完全に一致した場合のみ、マッチングルールが実行されます。マッチングルールは、大文字小文字を区別しないことに注意ください。

begins-with

フィールドが指定された文字列で始まる場合のみ、マッチングルールが実行されます。

ends-with

フィールドが指定された文字列で終了する場合のみ、マッチングルールが実行されます。

contains

フィールド内にが指定された文字列が含まれる場合のみ、マッチングルールが実行されます。

use-perl-reg-exp

文字列比較に、あなた自身のPerl正規表現を指定したい場合にこの比較タイプを使用します。これはあなたが大文字小文字を区別する比較を強制したい場合や入力データが特別ごちゃごちゃしている場合に必要でしょう。注意として、通常Perlコーディングシンタッの通り、戻りのサブ文字列を指定するのに一組の括弧を使うことができます

service-definition

これは、現在のデータ内の従属するフィールド構造を探して、その従属するデータに従ってサービス定義を作成する、特別の比較タイプです。これは、デバイスがフィールド固定のデータ構造によって簡単に表すことができないサービスの変数値を持つとき、必要となるでしょう。この一致タイプとフィールドのシンタックス要求についての「詳しい情報はオンラインヘルプを参照してください。

マッチングルールが、上述のひとつの文字列比較テクニック("contains" や"begins-with" など)を使用するか、Perl 正規表現を使用する場合、その比較操作に使用するマッチング文字列を規定する必要があります。マッチングルールが文字列比較テクニックを使わない("use-value-as-is" と"is-null" の場合)なら、この属性は無効です。

ルール・ディレクティブ

ルール属性は、現在のマッチングルールのために処理宣言文を保存(つまり、if-then 宣言文の"then"の部分を保存)します。そのルールは(先のセクションで記述したように)マッチ・フィルタが「真」の結果を戻したときのみ実行されます。

注意:有効なルール・ディレクティブは、使用されているマッチングフィルタによって定義されます。例えば、"is-null"比較タイプは、現在のフィールドがデータを含んでいない場合にのみ結果が真となります。そのため、それはフィールドのデータを構成エントリとして登録するルール・ディレクティブと一緒に使用できません。管理者がすべての必要とする値を指定するルール・ディレクティブとのみ一緒に使用できます。

使用できるルールのタイプを書きに示します:

表:ルールのタイプ

Assign value to

このルールは、単純に現在のフィールドの値を指定された属性に割り当てるものです。しかし、このフィールドは現在のホストオブジェクトをユニークに識別するために使用する属性と一緒ににのみ機能します。このルールが選択されると、フィールドのデータで占めるための属性タイプを選ぶ必要があります。サポートされる属性タイプは、ホスト名、ホストエイリアス、ホストアドレス、プライマリレコード、ホストの説明とホストプロファイルです。

Convert dword and assign to

これは、"二単語"のフィールド値を通常のテキストに変換し、その結果の値を指定された属性に割り当てる特別のルールです。このフィールドは、現在のホストオブジェクトをユニークに識別するために使用する属性と一緒ににのみ機能します。このルールが選択されると、フィールドのデータで占めるための属性タイプを選ぶ必要があります。サポートされる属性タイプは、ホスト名、ホストエイリアス、ホストアドレス、プライマリレコード、ホストの説明とホストプロファイルです。

Assign host profile

このルールは、単純に指定されたホストプロファイルを現在選択されているホストオブジェクトに割り当てます。このルールを選択したら、使用されるホストプロファイルも選ぶ必要があります。

Assign host profile if undefined

これは、二つのパートを持つルールで、最初に現在選択されているホストオブジェクトが既に他のマッチングルール定義されたホストプロファイルを持っているかを確認します。もし持っていなければ、現在のフィールド値がその属性に使用されます。このルールを選択したら、使用されるホストプロファイルも選ぶ必要があります。

Assign service

このルールは、単純に指定されたサービスエントリを、サービスエントリ名として使用されているフィールドデータと共に、現在選択されているホストオブジェクトに割り当てます。このルールを選択したら、新しいサービスエントリのために使用されるサービスタイプも選ぶ必要があります。

Resolve to parent

このルールは、現在のカラムが現在のデバイスのネットワーク・ペアレントの名前を含んでいることを意味します。このルール・ディレクティブは、マッチングフィルタ"use-value-as-is"が選択された場合のみ有効であることに注意してください。

Assign object(s)

このルールは、単純に指定された指定された構成属性を現在選択されているホストオブジェクトに割り当て、その属性を指定された値にします。このルールは、入力データが必要な属性値を提供しないで、それ自体が"is-null"のマッチングフィルタが選択だけが有効になる場合に使用されることを意図しています(そのフィールドのデータを値として使用したい場合は、代わりに"assign object if exists"を使用します)。このルールが選択されたら、使用される属性タイプと値も選ぶ必要があります。サポートされる属性タイプは、構成グループ、コンタクトグループ、ホストグループ、ペアレントとサービスプロファイルです。

Assign object if exists

これは、二つのパートを持つルールで、最初に現在選択されているフィールドにデータがあるかを確認します。もしあれば、属性の値としてそのフィールドのデータが使用され、指定された構成属性が現在選択されているホストオブジェクトのために生成されます。このルールは、先に検出を行わずに空のフィールドを提供することができる唯一のフィルタなので、マッチングフィルタ"use-value-as-is"が選択された場合のみ有効であることに注意してください。このルールが選択されたら、生成される構成属性タイプ値も選ぶ必要があります。サポートされる属性タイプは、構成グループ、コンタクトグループ、ホストグループ、ホストプロファイル、ペアレント、サービスプロファイルとサービスエントリです。

Assign value if undefined

これは、二つのパートを持つルールで、最初に現在選択されているホストオブジェクトが他のマッチングルールで規定された指定された構成属性を持つかどうかを確認します。もしなければ、現在のフィールドの値がその属性に使用されます。このルールが選択されたら、値を埋める属性タイプも選ぶ必要があります。サポートされる属性タイプは、ホスト、名前、ホストエイリアス、ホストアドレス、プライマリレコード、ホストの説明とホストプロファイルです。

Add if not exists and assign object

これは、特別の二つのパートを持つルールで、必要に応じて、あるタイプのグローバル構成オブジェクトを生成するために使用することを意図しています。このルールは、最初に、フィールドデータとして指定された構成オブジェクトが同一名称ですでに存在するかを確認します。そのオブジェクトが存在しない場合、その名称で構成オブジェクトが生成されます。このルールが選択されたら、比較を行うために、構成オブジェクトタイプも選ぶ必要があります。サポートされる構成オブジェクトタイプは、構成グループ、連絡先グループとホストグループです。

Discard record

このルールは、単純に現在のレコードを完全に廃棄するために、自動化処理機構を起動します。このルールは、単に"#"文字で始まるすべてのローを廃棄することによって、入力ファイルの中にあるコメントを無視するためにデフォルトのスキーマ定義で使用されます。

Discard if match existing record

これは、二つのパートを持つルールで、最初に同一名称のホスト構成オブジェクトがフィールドのデータとして存在すいるかどうかを確認します。もし存在すれば、現在のレコードは単に廃棄されます。このルールは、新しいデバイスを構成データベースに追加したいだけで既存のホストエントリを上書きしたくない場合に便利です。

Skip column record

このルールは、カラムに複数の従属フィールドがある場合(特に、SNMPのインタフェースが列挙されている場合)に、いつでも使用され、、現在のカラム中の現在の従属レコードをスキップするために自動化処理機構を起動します

マッチングルールを組み合わせることによって、総合的な処理ルールを作り上げることができます。例えば、デフォルトのスキーマ定義は、最初のカラムのデータについて下記のステップで処理を行う3つのマッチングルールを含んでいます:

  1. フィールドデータが"#"文字で始まる場合、それはコメントでレコードではないので、レコードを廃棄する。

  2. フィールドデータを新規レコードのホスト名属性として使う。

  3. フィールドデータが構成データベース内にホストエントリと一致したら、重複しているのでそのレコードを廃棄する。

カラムが複数ルールを持つ他の良い例は、デフォルトのスキーマ定義の中の"Description"カラム下で見られます。

自動スキーマ定義の管理

自動スキーマ定義は自動化コンソール画面で管理されます。自動化コンソール画面をアクセスするにはAuto-Discovery(自動検出)メニュー項目を選択してから、上部のメニューバーから自動化メニュー項目を選びます。

デフォルトの自動化コンソール画面を下図に示します。下記の例から分かるように、GroundWork Monitorはインストレーション中に作成される GroundWork Community Discovery というデフォルトのスキーマ定義を提供します。

図:自動化コンソール

Automation Console

既存のスキーマ定義を編集するには、一覧からそれを選んで、Next>>(次へ)ボタンをクリックします。すると、スキーマ定義エディタ画面がロード表示されます。ここで、スキーマ定義を編集したり実行したりできます。これらのトピックスについては、後述のスキーマ定義の編集とスキーマ定義の実行のセクションで説明します。

新規の検出定義は、New Schema(スキーマ作成)ボタンをクリックすることで作成できます。このトピックについては、後述のスキーマ定義の作成のセクションで説明します。

スキーマ定義の作成

新規のスキーマ定義を作成するには、自動化コンソール画面上の New Schema(スキーマ作成)ボタンをクリックします。下記のような新しい画面が表示されます。

図:スキーマタイプ

Creating Schema Definitions

あなたの要求に適するようにフィールドを埋めてください。各フィールドは下記のようになります:

表:スキーマのフィールド

Name(名前)

新しいスキーマ定義の名前を入力します。

Schema type
(スキーマタイプ)

ドロップダウンリストで使用可能な3つのスキーマタイプを表示します。スキーマタイプを必ずひとつ選択する必要があります。

Create from template
(テンプレートから作成する)

[任意] スキーマ定義は、一部を再利用することが可能な"テンプレート"として保存することができます(詳しくは次セクションの説明を参照ください)。

もし、すでにスキーマ定義をテンプレートとして保存している場合、それをドロップダウンリストの中から選んでそのオプションや変数を再利用することができます。もし他の定義からいかなるオプションも引き継ぎたくない場合、ドロップダウンリストを空のままにしておきます。スキーマテンプレートを選ぶことは、スキーマタイプを含む、すべての定義されたオプションを引き継ぐことになることに注意してください。ですから、ドロップダウンリスト中で選ばれたスキーマタイプは無視されることになります。

スキーマテンプレートを選ぶことは、スキーマタイプを含む、すべての定義されたオプションを引き継ぐことになることに注意してください。ですから、ドロップダウンリスト中で選ばれたスキーマタイプは無視されることになります。

フィールドが満足する内容で満たされたら、処理を継続するために Add(追加)ボタンをクリックします。この時点で、新しいスキーマ定義の値がロードされたスキーマエディタ画面が表示されるでしょう。新しい検出定義の作成を続けたくない場合は、メイン自動化コンソール画面に戻るために Cancel(キャンセル)ボタンをクリックします。

スキーマ定義の編集

スキーマ定義に関係付いたオプションと変数を編集するには、自動化コンソール画面上のスキーマ定義を選択して Next(次へ) ボタンをクリックします。すると、下図の画面のような、すでに設定されているスキーマ定義変数を含むスキーマ定義エディタ画面が表示されます(先のセクションで説明したように、この画面は新規スキーマ定義が作成されたときにも表示されます)。

ふたつのフィールドを除き、すべてのスキーマタイプでレイアウトが共有されていることに注意してください。実際、すべてのスキーマタイプがフィールドのセパレータとルール定義などの属性の設定とオプションを共有しています。しかし、host-import と host-profile-sync スキーマタイプは、デバイス名と IP アドレスが定義されるべきかどうかを示す追加のフィールドおよび、 指定されてない要素に対して使用されるデフォルトのホストプロファイルを定義するためのもうひとつのフィールドを持ちます。一方、other-syncスキーマタイプは、プライマリ同期キーとして使用される属性を定義するための、ひとつの分離フィールドを持ちます。

下記の図は、デフォルトの GroundWork-Discovery-Pro スキーマ定義からの値を使用した、host-import スキーマのための自動化スキーマエディタを示します:

図:デフォルトの自動化スキーマ

Automation Schema Default

下図は、あらかじめ設定された変数を持たない other-sync スキーマタイプの自動化スキーマエディタを示します:

図:自動化スキーマ Other Sync

Other Sync

記の図は、あらかじめ設定された変数を持たない other-sync スキーマスキーマタイプの自動化スキーマエディタを示します:

表:スキーマ定義のオプションとフィールド

スマート名 (SmartNames)
(host-import と host-profile-sync のみ)

GroundWork Monitor  の構成データベースは、デバイスのショート名、デバイスのエイリアス名(これは通常、FQDN: Fully Qualified Domain Nameです)およびデバイスのIPアドレスを含む、複数のホスト固有の属性を保存します。スキーマ定義がhost-importやhost-profile-syncスキーマタイプを使用していて、入力ファイルがこれらの属性を提供していない場合、GroundWork Monitor は多様な検索クエリを使って自動的にデータを検出しようと試みることができます。このプロセスが正しく働くために、入力データはこれら3つの属性の少なくとも1つを提供しなければならないことに注意してください。また、関連する属性はスキーマタイプによって変更されないので、このフィールドがスキーマ定義エディタ画面の中に存在しないことにも注意してください。これらの検索実施に必要なオーバヘッドのため、このオプションはデフォルトでは無効になっていますが、GroundWork-Discovery-Pro スキーマ定義では有効にされています。

プライマリ同期オブジェクト

(Primary Sync Object) (other-sync のみ)

other-sync スキーマタイプの挙動を正しく操作するため、入力データを既存のエントリとマッチできるが必要です。このドロップダウンリストはこの目的のために利用可能なフィールドを表示します。デフォルトではエントリはホスト固有のショート名とマッチングされますが、構成エントリを更新することが必要ならば、ホストグループやコンタクトグループなど広いカテゴリーでもマッチング可能です。

データソース

(Data Source)

このフィールドは、自動化プロセスで読み込んで構文解釈する入力ファイルのパスを指定します。このフィールドは、検出プロセスによって起動される自動化プロセスのために使用されるのではないことに注意ください。そうではなく、それらのジョブは、現在の検出定義の名称からダイナミックに生成されたファイル名を使い、/usr/local/groundwork/automation/dataディレクトリの中に入力ファイルを保存します(これにより、複数の検出ジョブが検出データを相互に独立して保存できるようにします)。

デリミタ

(Delimiter)

このフィールドは、入力データ内で複数のフィールドが提供された場合に入力フィールドを相互に分離するためのデリミタを指定します。先述のように、入力ファイル中の各行のデータは、単一のレコードを指定するのみかも知れませんが、共通のデリミタを持っていれば各レコードは複数のフィールドを含むかもしれません。ユーザは、ここでデータ入力をするのに二つの方法があります。まず、いくつかの共通フィールドのデリミタ文字から選ぶのに、ドロップダウンリストが便利な方法を提供します。一方、エディタボックスは、管理者が彼自身の文字列を指定すために使われます。ドロップダウンリストとエディットボックスの間にあるチェックボックスは、後者が使用されるべきであることを示しますが、デフォルトでは選ばれていません。デフォルトの GroundWork-Discovery-Pro スキーマ定義の場合、セミコロンのペアがフィールドデリミタとして使われています。

データカラム
(Data Columns) (と それ以降のフィールド)

このスキーマエディタ画面のセクションは、フィールド順序の指示や、そのフィールドの内容がどのように構成エントリにマッピングされるかなど、スキーマ定義のための構文解析とマッチングルールを定義するのに使われます。このサブシステムの複雑さのため下記に分けて文書化します。

スキーマ定義の変更が終了したら、変更を恒久化するために Save(保存)ボタンをクリックします。

将来の定義で適用できるようにするためのスキーマ定義のテンプレートを作成したい場合、Save As Template(テンプレートとして保存)ボタンをクリックします。テンプレートは、XMLテキストファイルとしてGroundWork Monitor サーバ上の /usr/local/groundwork/core/monarch/automation/templates ディレクトリの中に保存されます。テンプレートファイルは、他のGroundWork Monitor サーバの同じディレクトリにコピーすることができ、それにより即時にそのシステムで使用できるようになります。

現在の値で自動化プロセスを開始したいが、変更を恒久化したくない場合、Process Records(レコードの処理)ボタンをクリックします。変更をキャンセルしてメイン自動化コンソール画面に戻りたい場合、Close(閉じる)ボタンをクリックします。

データカラムとマッチングルールの管理

前述のように、自動化処理機構は入力ファイルから行単位でデータを読み、ユーザ定義された分離文字列を探すことで、入力からフィールドのデータを取り込みます。1行(ロー)ごとに1レコード、1フィールドごとに1カラムというように、これらのフィールドが一時的なローとカラムの交点に割り付けられます。各カラムは、フィールドデータが取り込まれた時に実行され、そのデータになにが起こるか(例えば、そのデータは、GroundWork Monitor構成データベース内のフィールドに割り付けられる、あるいは廃棄されるなど)を最終的に定義するひとつ以上のマッチングルールを持ちます。

この処理を機能させるため、管理者は、すぐそこで入力ファイルから見出されたカラムのデータを定義する必要があり、そして各カラムがどのように自動化サブシステムで処理されるかを宣言したマッチングルールを定義する必要があります。これらのタスクは、まさにこの目的のための Data column(データカラム)セクションを含む、スキーマ定義エディタ画面の中で行われます。

下図は、デフォルトのGroundWork-Discovery-Proスキーマ定義のためのこの画面の一部を示します:

図: デフォルトのスキーマ定義

Data Columns Default

下図は、まだカラムやマッチングルール定義がされていない、新規のスキーマ定義のためのこの画面の一部を示します:

図: 新規のデータカラム

Data Columns New

注意:データカラムは、そのカラムにマッチングルールを割り当てる前に定義されていなければなりません。これは、カラムが表示されていない、上記2つ目の図で示されており、それゆえに、マッチングルールの作成/編集のための機能の表示がされていません。

複数のカラム定義やマッチングルールがあるとき、現在選択されている定義は、濃い黄色の背面色で強調表示されています。ひとつの定義のみがある場合は、それが常に選択されるため、常に強調表示されます。

データカラムの管理

新規のデータカラムのマッピングを生成するには、その画面の Define Column(カラムの定義)の部分内のフィールドをあなたの要求条件と合うように埋めてください。フィールドを書きに示します:

表: カラムの定義フィールド

Position(位置)

入力ファイル内のデータフィールドの順番を示す数値を入力します(最初のフィールドが番号 "1" で、以下それに続きます)。

Column name(カラム名)

データカラムを説明する名称を入力します。

フィールドに満足する値を入力し終えたら、処理を続けるために Add Column(カラム追加)ボタンをクリックします。ここで、スキーマ定義エディタ画面が再表示され、新しいカラムが自動的に選択されて表示され、そのカラムのためにマッチングルールを作成するための機能が有効になるでしょう。作成されたばかりの"Test Column"ひとつだけを持つ新しいスキーマ定義を示す、下図でこれが示されています:

図: マッチングルール

Matching Rules

データカラム定義のフィールド位置を変えたい場合、Position(位置)フィールドの数値を書き換え、スキーマ定義エディタ画面の上部にあるSave(保存)ボタンをクリックしてください。

データカラムの名称変更をしたい場合、削除して再生成する必要があります。しかし、この手順は、データカラムに関係付けられたマッチングルールを削除することにもなるでしょう。

データカラム定義を削除するには、エントリの横にあるremove(削除)ハイパーリンクをクリックします。

マッチングルールの管理

新しいマッチングルールを作成するには、データカラムの名称をクリックして、画面の Define Match(一致定義)の部分を埋めてます。そのフィールドは下記のとおりです:

表: マッチングルール

Order(順番)

マッチングルールの優先順を示す数値を入力します。ひとつのデータカラムに複数のマッチングルールを関連付けることができ、各ルールは、その優先順に従って実行されます(マッチングルール"1"は、マッチングルール"2"の前に実行され、以下同様です)。

Match task name(一致タスク名)

マッチングルールを説明する名称を入力します。

フィールドに満足する値を入力し終えたら、処理を続けるために Add Match(条件追加)ボタンをクリックします。ここで、スキーマ定義エディタ画面が再表示され、新しいマッチングルールが自動的に選択されて表示されます。下図は、ひとつの"Test Column"と作成したばかりのひとつの"Test Rule"を持つ新しいスキーマ定義を表示している図です:

図: 新規マッチングルール

Matching Rules New

注意:上記の手順では、マッチングルールの枠を作っただけにすぎず、マッチングルールの中身(セマンティックス)がまだ定義されていません。それらのパラメータを設定するためには、マッチングルールを編集する必要があります。

マッチングルールを編集するには、ハイパーリンクされた名前をクリックします。これにより、新たにMatch Detail(一致詳細)ダイアログボックスが表示され、優先順位、名前、ルールの記述(セマンティックス)を含む、マッチングルールのすべての属性を変更することができます。ダイアログボックスが表示される際には、そのルールにすでに設定されているオプションに内容が表示されます。

注意:このダイアログボックス内のフィールド数は、現在選択されているマッチングルールによって使用されるマッチングフィルタやルールディレクティブによって変わります。

下図に、新規(まだ未定義状態)のマッチングルールのダイアログボックスを示します:

図: マッチングルール編集

Matching Rule Edit

一方、下図では、すでに選択されたマッチングフィルタとルールディレクティブを反映した追加のフィールドを持つ、このダイアログボックスの別の例を示します:

図: マッチングルール入力済

Matching Rule Full

その画面の Match Detail(一致詳細)の部分のフィールドは以下のとおりです:

表: 一致詳細フィールド

Order(順番 )

マッチングルールの優先順のための数値を入力します。

 Name(名前)

マッチングルールを説明する名称を入力します。

Match(一致 )

このドロップダウンリストは、使用可能なマッチングフィルタのタイプを含みます。マッチングフィルタ・タイプはマッチングルールの条件分岐部分をコントロールし、また、下の"Rule(ルール)"フィールドで使用できるルールディレクティブを定義します。

Match String

(一致文字列 )

Match(一致)フィールドが上記の文字列比較フィルタ("exact" や "contains"など)であれば、新しいフィールドが表示され、一致条件で使用する文字列を入力できるようになります。このフィールドは、文字列比較フィルタが使用されない場合、表示されません。

 Rule(ルール)

ここのドロップダウンリストは、上のフィールドで選択されたマッチングフィルタ・タイプによって定義された、使用可能なルールディレクティブを含みます。ルールは、カラムにデータが読み込まれた際、実際に何がこのフィールドのデータに起こるか(例えば、フィールドに割り当てられる、廃棄される、など)を定義します。

Object(オブジェクト)

ルールディレクティブが構成オブジェクトへの値を定義することを認める場合(オブジェクトのタイプや定義される値に関わり無く)、"Match Detail(一致詳細)"ダイアログは、オブジェクトを変更することができる"Objectオブジェクト"ドロップダウンリストを表示ます。このフィールドはルールディレクティブが構成オブジェクトを変更できない場合は表示されません。

Object-specific value

(オブジェクト固有値)

定義済みの値を設定するオブジェクトを認めるルールディレクティブを選んだ場合、そのオブジェクトのためのすべての既知の値を含む複数アイテムのリストボックスが表示されます。上記の例では管理者は、現在のデバイスに与える"ホストグループ(host group)"属性の定義済みホストグループを選べるので、管理者が既存のホストグループのひとつを選ぶ追加のダイアログエレメントが表示されています。

フィールドが満足する内容で満たされたら、処理を継続するために Update(更新) ボタンをクリックします。この時点で、スキーマエディタ画面が再表示され、変更したマッチングルールの画表示されるでしょう。

マッチングルールを削除するには、そのエントリの隣にある remove(削除)ボタンをクリックします。

自動化プロセスの実行

スキーマ定義は検出プロセスの一部、あるいは独立したオペレーションとして実行することができます。前者の場合、自動化プロセスは検出コンソール画面、あるいは検出定義エディタ画面から起動されなければなりません。後者の場合、自動化プロセスはスキーマ定義エディタ画面中の Process Records(レコードの処理)ボタンをクリックことでのみ実行されます。

自動化プロセスが開始すると、上述の自動化プロセスのセクションで説明したように、入力ファイルの内容が構文解析されます。この処理が終了すると、検出されたすべての構成オブジェクトとそれらの主な属性を表示するサマリ画面が表示されるでしょう。下図に、サンプルのMulti-Line-Dataスキーマ定義とインプットファイルを使って、その画面がどのように見えるかの例を示します :

図: 自動化サマリ

ad_as_summary.gif

この画面は入力ファイル内で検出された構成エントリの要約表示を提供し、スキーマと個々のエントリを編集する機能、および将来処理のためのエントリのサブセットを選ぶオプションを提供します。

画面の中央には、何らかのアクションが保留されている構成オブジェクト(新しいレコードの追加を待っている、あるいは、更新や削除を待つ既存のレコードなど)が表示されるスクロール可能な子ウィンドウが表示されます。変更されない構成データベース内の既存エントリは表示されません。同様に、以前にペンディングされた操作があったが、すでに処理された、あるいは廃棄されたエントリは、それらの変化が起こった後にはもうペンディングにならず、サマリ画面から削除されます。

サマリ画面の各エントリには、操作を行う個々のレコードを選ぶためのチェックボックスが右側に付いています。同時に複数のエントリを操作したい場合は、それぞれのエントリのチェックボックスをクリックするか、すべてのエントリを選ぶために画面の右上角の Check All(全項目のチェック)ボタンををクリックすることができます。また、画面上部の色凡例のハイパーテキストの名称をクリックすることで、そのタイプのエントリすべてを選ぶことができます Delete(削除)フラグが付いた全レコードを選ぶなどは、しばしば、全同期処理の破壊的な効果を防止するのに有効です)。

望ましいエントリを選んだら、それらレコードをGroundWork Monitor構成データベースに統合するために画面上部の Process Records(レコードの処理)をクリックしたり、ペンディングリストからそれらレコードを外すために Discard(廃棄)ボタンをクリックします。

そのエントリを生成するのに使用したスキーマ定義を変更したい場合、画面上部の Edit Schema(スキーマの編集)ボタンをクリックすると、スキーマエディタ画面に戻ることができます(前述のスキーマ定義の編集セクションで説明しました)。自動化プロセスを完全にキャンセルしたい場合は、メインメニューに戻るために Close(閉じる)ボタンをクリックします。

サマリ画面の各エントリは、それぞれの状態を反映して色付けされます。例えば、構成データベース内に存在しないデバイスのためのホストレコードは緑で色付けられおり、すでに存在しているデバイスのためのホストレコードは、ライトブルーで色付けされています(デフォルトのスキーマ定義では、重複したホストレコードを外すので、デフォルトでは既存デバイスはサマリリストには表示されません)。ウィンドウ上部の色凡例は、これらの色とその意味を示します。

子ウィンドウ内のホストレコードは、Sort by(ソート)のドロップダウンリストから望ましいソート方式を選ぶことで、プライマリキー、ホスト名、ホストエイリアスやホストアドレスに従って並び替えることができます。

各エントリのための主要な属性は、各行(ロー)のハイパーテキストエレメントの上にマウスを移動することで参照することができます。例えば、 "bern" エントリの Alias(エイリアス)ハイパーリンクの上にマウスを移動すると、検出されているそのデバイスのエイリアスが"bern.alps.com"のように表示され、"router-1"エントリの Services(サービス)ハイパーリンクの上にマウスを移動すると、そのデバイスについて検出されたすべてのインタフェース固有のサービスエントリを表示します(この例を上記の図で示します)。

画面の左下角の Enable Overrides(上書き実行)ボタンをクリックすることで、複数のレコードの属性を同時に変更することができます。これにより、下図のような新しいダイアログエリアを画面下部に追加します:

図: 自動化上書き

ad_as_override.gif

この画面で、上書きする属性と選んだレコードに強制的に書き込む属性値を選択することができます。また、検出した値を完全に置き換える Replace(置換)か、選んだ値を検出した値に追加する Merge(マージ)かを選択することができます。属性名の隣のチェックボックスが選択された属性のみが変更されることに注意してください。

望ましい変更をが終わったら、サマリリストからひとつ以上のエントリを選んで、選んだエントリの変更を行うために画面上部の Process Records(レコードの処理)ボタンをクリックします。現時点では、どのレコードも上書きしたくないと判断した場合、Disable Overrides(上書き不可)ボタンをクリックし、ダイアログを閉じます。

エントリの個々の属性は、エントリの右側の edit(編集)ハイパーリンクをクリックすることで編集できます。このリンクをクリックすると、選んだエントリの主要な属性がロードされたレコードエディタ画面が表示されます。下図に"zurich"のデバイスエントリのエディタ画面を示します:

図: 自動化 エントリ編集

Automation Entry Edit

ご覧のとおり、レコードエディタ画面で、管理者は、そのエントリに対して割り当てられたそのような主要属性も上書きすることができます。これには、検出サービスと各サービス定義に関係付けられたアーギュメント(サービス定義を選ぶことで、そのアーギュメントを編集できます)が含まれます。

注意:あなたが行った変更は、Process Record(レコードの処理)ボタンをクリックして変更をコミットしたときのみ、認識されます。レコードの廃棄や、あなたが行った変更のキャンセル(結果として、あなたの編集内容がなくなります)が可能です。