13    Event Manager の使用方法

Event Manager は,高機能のイベント管理システムです。 これは,従来のイベント処理機能の他に,独自のイベントと他のチャネルからのイベントを統合して 1 つの情報ソースとすることで,システム動作のモニタリング作業を簡単にします。 Event Manager には,グラフィカル・イベント・ビューアと,コマンド行ツールのフル・セットがあります。 これらの機能は,SysMan Menu のアプリケーション群および SysMan Station に統合されています。

この章では,次のトピックについて説明します。

13.1    Event Manager の概要

UNIX のシステム管理者の仕事で重要なものとして,システムの状態を監視し,通常と異なる状態になったときに,適切な処置をとることがあります。 通常と異なる状態の例には,ディスクが一杯になったときや,プロセッサがハードウェア障害を報告したときなどがあります。 また,日常処理が毎日正常に実行されていることを確認することや,システム構成値を見直すことも重要です。 このような状態や,タスクの完了を,システムのイベントといいます。

イベントとは,関心のある事象が発生したことを表します。 たとえば,アクションが行われたこと,ある条件が満たされたこと,あるいはアプリケーションが使用できる状態かどうかを確認すべき時期であることなどがあります。 管理者にとって興味の対象となるイベントもあれば,別のクラスのユーザにとって興味の対象となるイベントもあります。 システム・イベントは,次のような他のシステム・エンティティにとっても重要です。

イベントに関心を持つエンティティは,ローカル・システムの一部であっても,リモート・システムの一部であっても構いません。

システム・コンポーネントは,レポートすべきものを検出したら,イベント・チャネルを通してその情報を利用可能にします。 イベント・チャネルとは,イベント情報を公表したり取得したりするための任意の機能のことです。 イベント・チャネルの例としては,次のものがあります。

イベント管理システムはアクティブなイベント・チャネルであり,イベント情報の配布,格納,および取り出しのサービスを提供します。

Tru64 UNIX では,システム・コンポーネントがイベントと状態に関する情報を報告するために使用できるチャネルを多数サポートしています。 各チャネルで得られる情報を定期的に検査し,システムが正常に動作していることを確かめる必要があります。 システム・ロガー syslog とバイナリ・エラー・ロガー binlog は,イベント管理システムの身近な例です。 これらのイベント管理システムでは,他のコンポーネントから使用できるように簡単なイベント配布機能を用意しています。 またそのデーモンは,受け取ったイベント情報をアクティブに管理します。

逆に,cron デーモンのログ・ファイル /var/adm/cron/log は,受動的なイベント・チャネルの例です。 cron デーモンは新しいイベント情報をそのデーモン用のファイルの末尾に書き込み,書き込み時に関連エンティティに通知する動作は特に行いません。

syslog および binlog の他にも,システム上のさまざまな場所にさまざまなログ・ファイルが格納されています。 これらのログ・ファイルの管理を容易にするために,Event Manager は,すべてのソースからのイベントを 1 つのイベント・ストリームに結合することで,複数のイベント・チャネルを 1 箇所で監視できるようにします。 システム管理者は,結合されたストリームをリアルタイムで見ることもできるし,記憶域から取り出したイベントの履歴として見ることもできます。 Event Manager の表示機構には,グラフィカル・イベント・ビューアがあり,SysMan Menu と SysMan Station に統合されています。 また,コマンド行ユーティリティのフル・セットが用意され,必要に応じてイベントをフィルタリングしたり,ソートしたり,フォーマットすることができます。 選択した状況を自動的にユーザ (または他システム・エンティティ) へ通知するように,Event Manager を構成できます。

Event Manager は,syslogbinlog などを置き換えるのではなく,これらをカプセル化します。 これらの既存のチャネルは同じ場所にあり,いままでと同じイベント・セットを扱っています。 Event Manager では,他のチャネルがよりアクセスしやすくなります。

13.1.1    Event Manager の機能

Event Manager には,次のような機能があります。

13.1.2    Event Manager イベントとは

Event Manager イベントは,バイナリ・データのパッケージであり,イベントの名前,タイムスタンプ,ポスタ (ポストする側のクライアント) についての情報などの標準データ項目が入っています。 イベントには,ポスタが用意する可変データが入っていることがあります。 たとえば,デバイスの障害を通知するイベントには,デバイスのパス名と型を含む変数が入っています。 イベントは,Event Manager のポスト側クライアントにより生成されてポストされ,Event Manager デーモンによって他のクライアントに配布されます。 受信したプロセスは,その後,イベントに含まれる情報を抽出したり処理したりできます。

Event Manager ロガーは,ポストされたイベントを捉え,システム・ログ・ファイルに格納しますが,ユーザは,自身のイベントのセットを捉えて自身のファイルに格納し後で分析に使うことも,容易にできます。 evmwatch モニタリング・ユーティリティを使用するか,ロガーを再構成して,自身のイベントを捉えるようにします。

図 13-1では,イベントをモデル化して示します。 「イベント内容」の箱がイベントに含まれている項目を示しています。 この項目には,プロセス識別子 (PID),イベントが生成され,イベントに含まれているホスト・システムの名前などがあります。 「イベント・アクション」の箱は,イベントに対して実行される可能性があるアクションを示しています。

図 13-1:  イベント・モデル

Event Manager には,イベントのフォーマットを理解するコマンド行ユーティリティがあります。 これを使って,コマンド・プロンプトやシェル・スクリプトから,基本的な操作を行うことができます。 イベントはバイナリ・データのパッケージであるため,テキスト・ビューア (more コマンドなど) で直接見ることはできません。 Event Manager コマンドを使用すると,次の操作が可能です。

これらの Event Manager コマンド行ユーティリティは,パイプで結合して使えるようになっています。 たとえば,ファイルからのイベントのセットをソート・ユーティリティにパイプし,その出力結果をフォーマッティング・ユーティリティにパイプし,その出力結果を more コマンドにパイプしたり,またはファイルにリダイレクトすることができます。 13.3 節では,Event Manager コマンドを使用してイベント動作の監視および表示を行う例について説明します。

イベント・ファイルをテキスト形式に変換した後は,他の標準的なユーティリティを用いて分析することができます。 たとえば,イベント名だけを表示させ,その表示を sort -u コマンドと wc -l コマンドにパイプして,ファイル内に異なるタイプのイベントがいくつあるかを調べることができます。

13.1.3    Event Manager のコンポーネント

この項では,Event Manager の各コンポーネントがどのようにやり取りするかを示します。 また,Event Manager を実行するのに用いるシステム・ファイルと,通常の動作で Event Manager が生成するファイルについても説明します。 システムのモデルを図 13-2に示します。

図 13-2:  Event Manager コンポーネントのモデル

図 13-2では,イベントをポストする側のクライアントのコンポーネントが左,Event Manager のシステム・コンポーネントが中央,イベントのサブスクライブおよび取り出しを行う側のクライアントのコンポーネントが右に示してあります。 アクティブ・イベント・チャネルは,Event Manager に直接イベントをポストします。 パッシブ・イベント・チャネルとは,イベントをポストせず,ポーリングによって情報が収集されるチャネルのことです。 これらのチャネルは,監視スクリプトによって処理されるログ・ファイルに記録されます。

Event Manager の主要なコンポーネントは,evmd デーモンです。 これは,システムがブートされ実行レベル 2 になるときに初期化されます。 実行レベルについては,第 2 章 を参照してください。 イベント管理がシステムのスタートアップ時に機能するように,デーモンとその子プロセスの初期化は次のように同期がとられます。

Event Manager ロガー・プログラム evmlogger は,常駐プロセスとして動作します。 このロガーは,選択した一連のイベントをサブスクライブし,後で取り出すことができるようにそれを管理対象のログ・ファイルに格納するように構成されています。 ロガーはまた,省略時の動作として次のように構成されています。

Event Manager ロガー evmlogger は他のシステム・コンポーネントの操作で必要とする必須のシステム・コンポーネントなので,システムの構成から外すべきではありません。

常駐のチャネル・マネージャ・プロセス evmchmgr は,チャネル内で注目すべき動作を検出した場合にイベントをポストする,チャネル監視スクリプトを定期的に実行するように構成されています。 チャネル・マネージャは,日常のログ・クリーンアップ機能も実行します。

get サーバ・プロセス evmget_srv は,非常駐 (デマンド) プロセスであり,さまざまなイベント・チャネルに対してイベント検索スクリプトを実行します。 ユーザが evmget コマンドを実行したときは必ず,evmd デーモンが evmget_srv のインスタンスを起動します。

モデルの左側のエンティティは,イベントをポストするために,デーモンへのポストのための接続 (posting connection) を確立します。 ポスト側からイベントを受け取ると,デーモンは,テンプレート・データベースの対応するイベント・テンプレートとそれらをマージし,サブスクライブしているクライアントに配布します。

モデルの右側では,以下の動作が行われます。

13.1.3.1    Event Manager のコマンド行ユーティリティ

Event Manager のコマンド行ユーティリティには,Event Manager システム自身の管理用のものと,イベントのポストおよび取得で使用するものがあります。 表 13-1では,一般ユーザ用のコマンドについて説明します。 詳細は,それぞれのリファレンス・ページを参照してください。 これらのコマンドを使用してイベント動作を監視して見直す方法の例については,13.3 節を参照してください。

表 13-1:  Event Manager のコマンド行ユーティリティ

コマンド 説明

evmget

構成済のログ・ファイルのセットとイベント・チャネルから,格納されているイベントを,チャネル固有の検索関数を使って取り出します。

evmpost

テキスト・イベント・ソースのファイルまたはストリームを受け取り,Event Manager デーモンにポストします。 デーモンはこれを配布します。

evmshow

1 つ以上の Event Manager イベントを受け取り,要求されたフォーマットで出力します。

evmsort

イベントのストリームを読み,指定された基準に従ってソートします。

evmwatch

指定されたイベントをサブスクライブし,それらが到着すると出力します。

表 13-2では,通常,システムの初期化時に起動される,Event Manager 管理のためのコマンドを示します。 個々のコマンドのリファレンス・ページでは,コマンドを使用する具体的な状況について説明しています。

表 13-2:  Event Manager の管理ユーティリティ

コマンド 説明

evmchmgr

Event Manager チャネル・マネージャは,Event Manager デーモンによって自動的に起動されます。 これは,個々のチャネルに定義された関数を定期的に実行します。

evmd

Event Manager デーモンは,ポスト側クライアントからイベントを受け取り,サブスクライブ側のクライアントにそれらを配布します。 サブスクライブ側のクライアントとは,イベントの受信を希望していることを表明しているクライアントです。

このデーモンは,システムの重要な機能であり,システムのブート時に自動的に起動されます。 このデーモンは終了させないでください。

Essential Services Monitor (ESM) デーモン esmd は,evmd を含む重要なシステム・デーモンを自動的に再起動することにより,その可用性を維持しています。 ESM デーモンの詳細は, esmd(8) を参照してください。

evmlogger

Event Manager ロガーは,Event Manager デーモンによって自動的に起動されます。 ロガーは,デーモンからイベントを受け取り,そのイベントをフィルタ文字列が一致するログにそれぞれ記録します。 evmlogger はまた,要求があれば動作を実行するように構成できる,イベント転送エージェントとして使うこともできます。

evmreload

このコマンドは,Event Manager のコンポーネントに構成ファイルを再ロードするように指示する制御イベントをポストします。 Event Manager 構成ファイルを変更した場合は,このコマンドを使用して新しい構成をロードしなければなりません。

evmstart

このコマンドは,Event Manager デーモンを起動します。 このコマンドは,システム・スタートアップ・スクリプト内で実行することを意図したものですが,何らかの理由で Event Manager が停止した場合には,再起動するために使うこともできます。

通常の運用では,esmd デーモンは,Event Manager デーモンを自動的に再起動します。

evmstop

このコマンドで,Event Manager デーモンが停止し,エンティティはイベントのポストやサブスクライブができなくなります。 このコマンドは,システム・シャットダウン・スクリプト内で使用することを意図しています。 Event Manager は,多くのシステム関数が適切に動作するために必要です。 このため,このコマンドは正常な運用状態では使用しないでください。

多くの場合,esmd デーモンは,Event Manager デーモンを自動的に再起動します。

13.1.3.2    Event Manager のアプリケーション・プログラミング・インタフェース

Event Manager API ライブラリ libevm.so には,幅広いイベント管理関数群があります。 このライブラリを使用すると,プログラマは,Event Manager とのインタフェースを持つプログラムを設計できます。 API 関数を使用すると,プログラムからイベントをポストしたり,デーモンに要求や通知を送信したり,デーモンから応答や情報を受信することができます。 これらのインタフェースの使用については,『プログラミング・ガイド』を参照してください。 (個々の API リファレンス・ページのリストについては, EVM(5) を参照してください。)

13.1.3.3    Event Manager のシステム・ファイル

Event Manager は,以下のシステム・ファイルを作成または使用します。 システム・ファイルには,実行可能ファイル,構成ファイル,およびログ・ファイルがあります。

実行可能ファイル

Event Manager 管理コマンドの実行可能ファイルは,/usr/sbin ディレクトリにあります。

一般的なコマンド (つまり,ユーザ・コマンド) の実行可能ファイルは,/usr/bin ディレクトリにあります。

初期化ファイルは,/sbin/init.d ディレクトリにあります。

構成ファイル

ベースとなる Event Manager 構成ファイルは,/etc ディレクトリにあります。 これらのファイルについて,以下に示します。

/etc/evmdaemon.conf

このファイルは,Event Manager の構成と起動で使用されるコマンドを記述したテキスト・ファイルです。 このファイルの詳しい説明は,13.2.2.1 項evmdaemon.conf(4) を参照してください。

/etc/evmchannel.conf

チャネル・マネージャ evmchmgrevmshow コマンドが読むイベント・チャネル構成ファイルです。 このファイルには,イベントをポストおよび取り出すことができるすべてのチャネルが記述されています。 このファイルの詳しい説明は,13.2.2.2 項evmchannel.conf(4) を参照してください。

/etc/evmlogger.conf

このファイルは,ロガー (evmlogger) の構成ファイルです。 イベントの表示,転送,保存に関するコマンドが入っています。 このファイルの詳しい説明は,13.2.2.3 項evmlogger.conf(4) を参照してください。

/etc/evm.auth

このファイルは,イベントとイベント・サービスへのアクセスを制御するために使用します。 このファイルの詳しい説明は,13.2.3.2 項evm.auth(4) を参照してください。

ログ・ファイル,作業ファイル,およびローカル・インストレーション・ファイル

ログ・ファイル,作業ファイル,およびローカル・インストレーション・ファイルは,/var/evm の下の以下のサブディレクトリにあります。

/var/evm/sockets

この CDSL ディレクトリには,ドメイン・ソケット・ノード evmd と,関連するロック・ファイル evmd.lck があります。 ローカル・クライアントはこのソケットを使って接続します。

/var/evm/evmlog

この CDSL ディレクトリには,省略時の Event Manager ロガー構成によって作成されたイベント・ログがあります。 このディレクトリのログ・ファイルには,evmlog.yyyymmdd[_nn] という形式の名前がつきます。 yyyymmdd はログの日付,_nn は連続の生成番号です。 ログのサイズが,設定されている 1 日の最大サイズに達した場合,またはロガーが現在のファイルにエラーを検出した場合,新しいログ・ファイルが作成されます。 1 日の最初のログ・ファイルには生成番号は付きません。 新しいログ・ファイルは,システム時間の午前 0 時を過ぎて最初にイベントを受け取った時点で作成されます。

このディレクトリにはまた,ロック・ファイル (evmlog.dated.lck) と,生成制御ファイル (evmlog.dated.gen) が置かれます。 後者には,現在の生成番号に関する情報が記録されます。 ログ・ファイルの管理については,13.2.4 項を参照してください。

/var/evm/adm/logfiles

この CDSL ディレクトリには,Event Manager の常駐のコンポーネントであるデーモン,ロガー,およびチャネル・マネージャが作成した出力メッセージ・ログが置かれます。 Event Manager が開始されるたびに新しいファイルが作成されます。 その際,古いファイルはファイル名に .old という接尾語を付加して名前が変更されます。 古いファイルがすでにある場合は,置き換えられます。 これらのメッセージ・ログは,Event Manager の misclog イベント・チャネルによってカプセル化され,その内容は,evmget とイベント・ビューアを通して見ることができます。

/var/evm/shared

このディレクトリは,クライアントの認証で必要な一時ファイルを置く作業ディレクトリです。

/var/evm/adm/templates

このディレクトリは,ローカルまたはサードパーティのイベント・テンプレートのサブディレクトリをインストールするためのものです。 このディレクトリは,シンボリック・リンクによってシステムのテンプレート・ディレクトリに結び付けられています。

/var/evm/adm/channels

このディレクトリには,ローカルおよびサードパーティのイベント・チャネル・スクリプトがインストールされます。

/var/evm/config

このディレクトリとそのサブディレクトリには,各種の Event Manager 構成要素の 2 次構成ファイルがあります。 本リリースで 2 次構成ファイルをサポートしているのは,ロガーだけです。 詳細は, evmlogger.conf(4) を参照してください。

/var/evm/adm/filters

このディレクトリには,ローカルおよびサードパーティのイベント・フィルタ・ファイルがインストールされます。

/var/run/evmd.pid

このファイルには,デーモンのプロセス ID (PID) が記録されます。 これは,evmd デーモンによって保存され,Event Manager を停止する場合などに利用されます。

/var/run/evmlogger.info

このファイルには,ロガーの PID と管理しているログ・ファイルの情報が記録されます。 evmlog チャネルの検索関数と日次クリーンアップ関数で,この情報を使用します。

システム提供の定義ファイル

システム提供のテンプレート,チャネル,フィルタの定義ファイルが,/usr/share/evm ディレクトリの下の次のサブディレクトリにあります。

これらのファイルは変更しないでください。

/usr/share/evm/channels

このディレクトリには,binlogsyslog,および evmlog などのシステム提供のイベント・チャネルのサブディレクトリがあります。 各サブディレクトリには,そのチャネルで利用できるサービスを定義するスクリプトが置かれています。

/usr/share/evm/filters

このディレクトリには,システムのフィルタ・ファイルがあります。

/usr/share/evm/templates

このディレクトリには,システムのイベント・テンプレート・ファイルおよびサブディレクトリがあります。

13.1.4    関連ユーティリティ

次のようなサブシステム,またはオプションのコンポーネントも,イベント処理機能を提供します。

システム・ロガー (syslogd)

システム・ロガー (syslogd)

システム・ロガーは,カーネル・レベルとユーザ・レベルのシステム・コンポーネントのためのテキスト・メッセージを記録します。 自分自身のログ・ファイルにイベントを記録するだけでなく,syslogd デーモンの省略時の構成では,選択されたイベントを Event Manager に転送します。 そして,さらにこれを保管したり,配布したりすることができます。 Event Manager では,syslog イベントを evmlog ファイルに格納することで,非常に大きいテキスト・ファイルからの取り出しによるオーバヘッドを軽減します。 詳細は, syslogd(8) を参照してください。

バイナリ・エラー・ロガー (binlogd)

バイナリ・エラー・ロガーは,システム・エラーと構成情報をバイナリ形式で記録します。 イベントは,システムのタイプによって,DECevent 変換機能 (dia) または Compaq Analyze (ca) により変換されます。 binlogd デーモンは,自身のログ・ファイルにイベントを記録し,自身のクライアントにそれを配布するほか,イベントを Event Manager に転送します。 Event Manager ではさらにこれを配布します。 Event Manager では,バイナリ・エラー・ログ・イベントを binlog イベント・チャネル関数を用いて記憶域から取り出します。 詳細は, binlogd(8) を参照してください。

DECevent と Compaq Analyze

DECevent は,規則ベースの変換およびレポートを行うユーティリティであり,イベントをバイナリ・エラー・ログ・イベントに変換します。 Event Manager は,DECevent の変換機能 dia を使って,バイナリ・エラー・ログ・イベントを表示できる形式に変換します。 Compaq Analyze は,ほとんどの EV6 シリーズのプロセッサ上で同様の役割を果たします。 詳細は, ca(8) と,Compaq Analyze のその他のドキュメントを参照してください。

13.2    Event Manager の管理

Event Manager が動作するシステムでの管理者の役割には,主に次のものがあります。

Event Manager の使用についての詳細は,13.3 節を参照してください。

13.2.1    Event Manager の起動と停止

Event Manager はシステム起動時に自動的に起動され,システムのシャットダウンとともに停止します。

Essential Services Monitor (ESM) デーモン esmd は,Event Manager デーモンを含む重要なシステム・デーモンを自動的に再起動することにより,その可用性を維持しています。 詳細は, esmd(8) を参照してください。

Event Manager を停止するには,ESM デーモンのプロセス識別子が必要です。 Event Manager を停止するには,以下の手順を実行します。

  1. ESM デーモンのプロセス識別子を調べる。

    # ps -aef | grep esmd | grep -v grep 
    1. root    48  1  0.0  Apr 22 ??  0:00.09 /usr/sbin/esmd
    

    この例では,PID は 48 です。

  2. kill コマンドを使用して,ESM デーモンを停止します。

    # kill -STOP PID
    

  3. evmstop コマンドを使用して,Event Manager を停止します。

    # /usr/sbin/evmstop
    

Event Manager と ESM を起動するには,以下の手順を実行します。

  1. evmstart コマンドを使用して,Event Manager を起動します。

    # /usr/sbin/evmstart
    

  2. kill コマンドを使用して,ESM デーモンの実行を元に戻します。 ESM デーモンを停止させたときに指定した PID を使用します。

    # kill -CONT PID
    

Event Manager 構成を変更しても,Event Manager を停止して再起動する必要はありません。 この場合,構成を変更した後で evmreload コマンドを実行します。 詳細は, evmreload(8) を参照してください。

13.2.2    Event Manager の構成

Event Manager を構成することは,構成可能な常駐コンポーネントを確立し,保守することを意味します。 この常駐コンポーネントには,次のものがあります。

各コンポーネントは,動作を指示する構成ファイルを参照します。

オペレーティング・システムをインストールする際に,Event Manager は,たいていのシステムに適合する省略時の構成オプションで実行するように自動的に構成されます。 ただし,たとえば以下の場合には構成ファイルを変更できます。

Event Manager は,バイナリ・ロガー (binlogd) イベントを変換するために DECevent と Compaq Analyze を使用するように事前に構成されています。

構成を変更した場合は必ず,新しいファイルをロードするため,または変更を行うため,evmreload コマンドを実行して,構成を再度確立しなければなりません。 このコマンドについての詳細は, evmreload(8) を参照してください。

構成ファイルについては,以下の項と該当するリファレンス・ページで説明します。

13.2.2.1    Event Manager のデーモンの構成

Event Manager デーモンは,/etc/evmdaemon.conf 構成ファイルを,システムのスタートアップ時と,evmreload コマンドを使用して再ロード要求が出されるたびに読み取ります。 構成ファイルの内容と構文についての詳細は, evmdaemon.conf(4) リファレンス・ページを参照してください。 例 13-1では,Event Manager デーモン構成ファイルのエントリの例を示します。

例 13-1:  Event Manager デーモン構成ファイルのエントリの例

# Event template directory:
sourcedir       "/usr/share/evm/templates"  [1]
 
# Start the Event Manager Logger                     [2]
start_sync "/usr/sbin/evmlogger -o /var/run/evmlogger.info \
            -l /var/evm/adm/logfiles/evmlogger.log"
# Start the Event Manager Channel Manager            [2]
start_sync      "/usr/sbin/evmchmgr -l \
            /var/evm/adm/logfiles/evmchmgr.log"
 
# Event retrieval service definition:
service                                    [3]
   {
     name          event_get
     command       "/usr/sbin/evmget_srv"
   }
 
# Set up an activity monitor.
activity_monitor                           [4]
   {
     name            event_count
     period          10
     threshold       500
     holdoff         240
   }
 
remote_connection false                    [5]
 
 

  1. この文は,すべてのイベント・テンプレート・ファイルのディレクトリ階層の先頭を示します。 [例に戻る]

  2. これらのコマンドでは,evmlogger コンポーネントと evmchmgr コンポーネントを 2 つのクライアントとして同期をとって開始しています。 これにより,両方のクライアントがサブスクライブ要求を完了してから,デーモンがポスト側クライアントからのイベントを受け入れることを保証します。 これらのコマンドのコマンド行オプションには,クライアントのログ・ファイルを指定します。 ロガーの場合は,出力ファイルも指定します。 この出力ファイルは,イベント・チャネル関数 evmlog から動作の詳細を利用できるようにするために使用されます。 [例に戻る]

  3. これらの文は,イベント検索サービス event_get を定義しています。 evmget コマンドはこれを使ってイベントを取り出します。 [例に戻る]

  4. これらの文は,アクティビティ・モニタを定義します。 この例では,10 分間に 500 以上のイベントを受け取った場合,デーモンはシステム管理者の注意を促すために高優先順位のイベントをポストします。 その後,動作モニタリング (イベントのカウンティング) は,保留 (hold-off) 期間である 4 時間 (240 分) の間中断されます。 [例に戻る]

  5. この行では,remote_connectionfalse にセットし,リモート Event Manager クライアントがこのシステムに接続できないようにしています。 このセキュリティ関連の値を変更する方法についての詳細は, evmdaemon.conf(4)13.2.3 項を参照してください。 [例に戻る]

構成ファイルを変更した場合は,Event Manager デーモンにこの変更を認識させるために,evmreload コマンドを実行しなければなりません。 詳細は, evmreload(8) を参照してください。

13.2.2.2    Event Manager のチャネルの構成

イベント・チャネルは,イベント情報のソースです。 チャネル構成ファイル /etc/evmchannel.conf では,チャネル・マネージャ,evmshow コマンド,およびイベント検索プロセスが使用する,一連のイベント・チャネルとそこで動作する関数を定義しています。 チャネル構成ファイルの内容と構文についての詳細は, evmchannel.conf(4) リファレンス・ページを参照してください。 例 13-2では,チャネル構成ファイル・エントリの例を示します。

例 13-2:  Event Manager チャネル構成ファイルの例

# Global path for channel functions
path   /usr/share/evm/channels    [1]
 
# Time-of-day at which daily cleanup function will run
cleanup_time 02:00:00    [2]
 
# ==================================
# Event channel:  EVM log
# ==================================
channel
  {    [3]
    name        evmlog    [4]
    path        /usr/share/evm/channels/evmlog    [5]
    events      *    [6]
    fn_get      "evmlog_get"   [7]
    fn_details  "evmlog_details"
    fn_explain  "evmlog_explain"
    fn_monitor  "evmlog_mon"
    fn_cleanup  "evmlog_cleanup 7 31"    [8]
    mon_period  15:00  # Monitor every 15 minutes    [9]
   }
 

  1. この行では,/usr/share/evm/channels ディレクトリを,すべての channel 関数の省略時設定のパスとして宣言しています。 このファイルで定義されている channel 関数の名前でスラッシュ (/) で始まらないものには,そのチャネル・グループに個別のパスが明記されていない場合,名前の前にこのパスがつけられます。 [例に戻る]

  2. この行では,すべてのチャネルを毎日午前 2:00 にクリーンアップすることを指示しています。 [例に戻る]

  3. この行では,イベント・チャネルを定義する構成グループを指定しています。 [例に戻る]

  4. この行では,チャネルの名前として evmlog を指定しています。 [例に戻る]

  5. この行では,グローバル・レベルで定義された省略時のパス /usr/share/evm/channels を指定変更します。 [例に戻る]

  6. この行のアスタリスク (*) は,このチャネルが省略時のイベント処理を行うことを示します。 つまりこの関数は,どのチャネルのイベント値にも一致しない名前を持つすべてのイベントのために,詳細と説明を提供するために呼び出されます。 [例に戻る]

  7. fn_ で始まる行はすべて,各関数に対して実行されるスクリプトを定義します。 [例に戻る]

  8. この行の引数の値は,クリーンアップ・プログラムに渡され,その操作を制御します。 この例では,7 日を超えて保持されたログ・ファイルを圧縮し,31 日を超えて保持されたこれらのログ・ファイルを削除するように指定しています。 引数の意味は個々のチャネル機能に固有であり,すべての場合に同じとは限りません。 [例に戻る]

  9. この行では,モニタリングの間隔を設定しています。 この例では,/usr/share/evm/channels/evmlog/evmlog_mon 関数は,15分ごとに呼び出されます。 [例に戻る]

13.2.2.3    Event Manager ロガーの構成

Event Manager ロガーは,/etc/evmlogger.conf 構成ファイルのエントリに従ってイベントの保存と転送を処理します。 このファイルの内容と構文についての詳細は, evmlogger.conf(4) を参照してください。 例 13-3では,ロガーの構成ファイルのエントリの例を示します。 ロガーに行うことが可能なカスタマイズの例としては,出力をログ・ファイルの他に,端末に行うことなどがあります。

例 13-3:  Event Manager ロガー構成ファイルのエントリの例

# Main log file:
eventlog {    [1]
    name        evmlog   [2]
    logfile     /var/evm/evmlog/evmlog.dated   [3]
    type        binary   [4]
    maxsize     512  # Kbytes    [5]
 
    # Uncomment the following "alternate" line and set the 
    # logfile path to specify an alternate logfile in case
    # of write failures.
    # The path must specify an existing directory.
    #alternate  /your_alternate_fs/evmlog/evmlog.dated   [6]
 
    # Log all events with priority >= 200, except binlog events:
    filter       "[prio >= 200] & (! [name @SYS_VP@.binlog])"  [7]
 
    # Suppress logging of duplicate events:
    suppress    [8] 
    {   filter      "[name *]"
        period      30    # minutes 
        threshold   3     # No. of duplicates before suppression
    } 
}
# Forward details of high-priority events to root:
forward {    [9]
    name      priority_alert    [10] 
    maxqueue  200   [11]
 
    # Don't forward mail events through mail
    filter  "[prio >= 600] & ![name @SYS_VP@.syslog.mail]"   [12]
 
    suppress    [13] 
    {   filter  "[name *]"
        period  120    # minutes
        threshold   1  # No. of duplicates before suppression
    }
 
    # This evmshow command writes a subject line as the first
    # line of output, followed by a detailed display of the 
    # contents of the event. 
    # The resulting message is distributed by mail(1).
    command "evmshow -d -t 'Subject: EVM ALERT [@priority]: @@' |
    mail root"    [14]
 
    # Limit the number of events that can be queued for this
    # command:
    maxqueue        100
}
# Secondary configuration files can be placed in the following
# directory.  See the evmlogger.conf(5) reference page for
# information about secondary configuration files.
configdir       /var/evm/adm/config/logger
 
 

  1. この行から,イベント・ログ構成グループが始まります。 [例に戻る]

  2. この行でイベント・ログの name を指定しています。 構成ファイルの他の部分は,この名前を参照します。 [例に戻る]

  3. この行では,ログ・ファイルを /var/evm/evmlog ディレクトリに格納するように指定しています。 1 日の最初のログが書き込まれるとき,dated 接尾語が yyyymmdd の形式の日付で置き換えられます。 [例に戻る]

  4. この行では,このログに書き込まれるイベントの type がバイナリ Event Manager イベントであり,フォーマットされた (ASCII テキスト) イベントではないことを指定します。 [例に戻る]

  5. この行では,ログ・ファイルの最大サイズを K バイト (KB) 単位で指定しています。 この例の場合,現在のログ・ファイルのサイズが 512 KB を超えると,ロガーはこれをクローズし,続き番号の接尾語 (たとえば,_2) を用いて新しいログ・ファイルを開始します。 [例に戻る]

  6. この行のコメントアウト (#) を外し,サンプル・パスを実際の書き込み可能ディレクトリのパス名に置き換えると,主要なディレクトリでの書き込みができなくなった場合,このディレクトリに代替ログ・ファイルがオープンされます。 [例に戻る]

  7. この行では,イベントのフィルタリング条件を指定して,どのイベントがこのログ・ファイルに記録されるかを定義しています。 Event Manager フィルタの構文についての詳細は, EvmFilter(5) を参照してください。 @SYS_VP@ エントリは,sys.unix が読み込まれたときに,そのファイルで置き換えられるマクロです。 [例に戻る]

  8. この文では,イベント・ログの抑制パラメータを定義しています。 この例の場合,イベントの抑制は,30 分以内に 3 つ以上の同じイベントを受け取ると開始されます。 同じイベントの抑制により,ログ・ファイルのスペースが節約できます。 イベントの抑制についての詳細は, evmlogger.conf(4) を参照してください。 [例に戻る]

  9. この行では,root ユーザに転送するイベントの条件を定義しています。 イベント転送プログラムは,選択されたイベントが発生すると指定されたコマンド文字列を実行します。 これは,重大なエラーが発生したときにシステム管理者に知らせるのに役立ちます。 [例に戻る]

  10. この行の name には,転送プログラムの名前を指定しています。 [例に戻る]

  11. maxqueue queue_limit キーワードは,前のイベントが処理されている間に,転送プログラムがキューに入れることができるイベントの数を制限します。 新たなイベントが到着したときに最大個のイベントが既にキューに入っている場合,この転送プログラムはこの新しいイベントを無視します。 このキーワードが指定されていない場合,省略時の値は 100 イベントです。 1000 イベントより大きい値を指定すると,ロガーは自動的に 1000 イベントに制限します。 [例に戻る]

  12. この行では,イベントのフィルタ処理を定義しています。 イベント・ログの定義と同様,フィルタ文字列は,この転送プログラムが処理する一連のイベントを指定します。 メール・サブシステムでの問題を示す高優先順位のイベントをメーラがポストした場合にイベント・ループが起きるのを避けるには,メール・イベントを,明示的にこの転送プログラムから除外します。 [例に戻る]

  13. これらの行では,イベントの重複転送を抑制しています。 転送プログラムの抑制メカニズムは,イベント・ログのものと似ています。 ただし目的は,同じイベントが繰り返しポストされることにより,短い期間にそのコマンドが何度も送られるのを防ぐことです。 この例の場合,イベントは最大で 2 時間に 1 度転送されます。 [例に戻る]

  14. この行では,転送プログラムがイベントを処理したときに実行されるコマンドを定義しています。 イベントは,このコマンドの stdin ストリームにパイプされます。 このコマンドの結果は,コマンド行の上のコメントで説明しています。 [例に戻る]

ロガー構成ファイルを変更した場合は,ロガーにその変更を知らせるために evmreload コマンドを実行しなければなりません。 詳細は, evmreload(8) を参照してください。

リモート・ロギング構成の詳細は,13.3.13.3 項を参照してください。

13.2.2.4    ロガーの 2 次構成ファイル

ロガーの 2 次構成ファイルを使用すると,1 次構成ファイル /etc/evmlogger.conf を変更せずにイベント・ログまたは転送プログラムを追加できます。 この機能により,2 次ファイルの問題が 1 次構成に影響を及ぼすことはありません。 したがって,異なるロガー構成を安全に試すことができます。 ロガーが 2 次構成ファイル内の構文エラーを検出すると,エラー・メッセージが表示されてファイルが拒否されます。 1 次構成ファイルと追加の (正しい) 2 次ファイルが処理され,Event Manager が正しく機能します。 2 次構成ディレクトリ機能を使用すると,個々のシステム・コンポーネント,製品,およびアプリケーションで,ログ・ファイルと転送プログラムをインストールまたは変更することもできます。 1 次構成ファイル内で行を挿入または修正するのではなく,ファイルをインストールまたは置き換えます。 ファイルを削除することで,エントリをアンインストールすることができます。

2 次構成ファイルの省略時の推奨位置は,/var/evm/adm/config/logger ディレクトリまたはそのディレクトリのサブディレクトリです。 それ以外の位置に構成ファイルを置き,省略時のディレクトリからシンボリック・リンクを作成することもできます。 サポートされてはいますが,1 次構成ファイルに configdir 行を追加するのは避けてください。 2 次構成ファイルのファイル名には,サフィックス .conf を付け,13.2.2.3 項で示す規則に従ったファイル構文でなければなりません。

ロガーの 2 次構成ファイルとディレクトリに適切なパーミッションを与えることが重要です。 ロガーはスーパユーザ特権で実行され,どの 2 次構成ファイルに指定されたコマンドでも実行できます。 そのため,正しいパーミッションを持たない構成ファイルはすべてロガーで拒否され,警告イベントがポストされます。 正しいファイル・パーミッションについては, evmlogger.conf(4) を参照してください。

クラスタ環境では,ロガー構成ファイルはすべてのクラスタ・メンバで共用されます。 メンバ固有のイベント・ログまたはイベント転送プログラムが必要な場合は,2 次構成ファイルで指定することができます。 2 次構成ディレクトリにコンテキスト依存シンボリック・リンク (CDSL) を作成し,ファイルを参照させます。 CDSL の作成方法は, mkcdsl(8) を参照してください。

13.2.2.5    イベントの紛失を防ぐためのバッファ・サイズの変更

イベント紛失の問題が発生した場合は,システム・パラメータを変更して,受信バッファ・サイズを大きくすることができます。

受信バッファ・サイズには,システム・ソケット・バッファの省略時の最大値が設定されています。 現在のこのパラメータの値を調べるために,次のコマンドを実行します。

#  /sbin/sysconfig -q socket sb_max

このパラメータの実行時の値を変更するには,次のコマンドを実行します。

#  /sbin/sysconfig -r socket sb_max=new-value

この変更は,次回のリブートまで有効で,新しい Event Manager 接続だけに効果があります。

この変更を恒久的なものにするには,sysconfigdb または dxkerneltuner ユーティリティを使用します。 詳細は, sysconfigdb(8) または dxkerneltuner(8) を参照してください。

13.2.3    セキュリティについて

イベントを扱う場合,セキュリティは次のような理由により重要な問題となります。

従来,イベント情報に対するセキュリティは,ログ・ファイルへの読み取りアクセスを制限したり,特定のポスト動作を root ユーザだけに制限することで維持されています。 Event Manager デーモンとイベント検索機能によって,すべてのイベントへのアクセスの代替の手段ができてしまうため,デーモンはまた,イベントがポストされたときと記録された後の両方で,アクセスを制限する手段も提供します。 これによって,権限のあるユーザだけがイベントを見ることができるようになります。 このアクセスの制御は,権限機能 (authorization feature) と認証機構 (authentication technique) を通じて行います。

Event Manager 環境で使用する実行可能関数を作成する際にも,セキュリティへの配慮が必要です。 チャネル関数の保護については,『プログラミング・ガイド』 を参照してください。

13.2.3.3 項で説明しているように,Event Manager は,指定されたユーザからはリモートでアクセスできます。

13.2.3.1    ユーザの認証

Event Manager デーモンは,接続要求を受け入れる前に,すべてのローカル・システム・ユーザの ID を認証します。 クラスタの場合,同じクラスタの別のノードから接続を要求するユーザも認証します。 リモート・ユーザの認証を含む,リモート接続については,13.2.3.3 項を参照してください。

13.2.3.2    ユーザの権限

イベントへのアクセスは,Event Manager の権限ファイル /etc/evm.auth によって制御されます。

root ユーザは,個々のユーザやユーザのグループに,次のことを行う権限を与えることができます。

省略時の設定では,すべてのイベントがポストされます。 イベント権限は,指定した権限を持っているユーザまたは明示的に権限が否定されているユーザのリストを各イベント・クラスごとに指定して,付与されます。 ユーザのリストが後に続いていない正符号 (+) では,省略時の指定として,すべてのユーザに権限が与えられます。 ユーザのリストが後に続いていない負符号 (-) では,省略時の指定として,すべてのユーザに権限が与えられません。 root ユーザは,権限を明示的に否定されないかぎり,すべてのイベントをポストあるいはアクセスする権限を持ちます。 例 13-4では,権限ファイルのエントリの例を示します。 詳細は, evm.auth(4) を参照してください。

例 13-4:  Event Manager 権限ファイルのエントリの例

# ===================
#      EVENTS
# ===================
 
event_rights {                             [1]
   class        @SYS_VP@.evm.control   # EVM control events
   post         root
   access       +
}
 
event_rights {                             [2]
   class        @SYS_VP@.evm.msg.admin  # EVM admin message
   post         root
   access       "root, group=adm"
}
 
event_rights {                             [3]
   class        @SYS_VP@.evm.msg.user         # EVM user message
   post         +
   access       +
}
 
 
# ===================
#      SERVICES
# ===================
 
service_rights {                           [4]
   service      event_get
   execute      +
}

  1. sys.unix.evm.control で始まる名前を持つクラスのイベントは,root ユーザだけがポストできます。 このようなイベントは,すべてのユーザがアクセスできます。 @SYS_VP@ エントリは,ファイルが読み込まれるときに sys.unix に置き換えられるマクロです。 [例に戻る]

  2. sys.unix.evm.msg.admin で始まる名前を持つクラスのイベントは,root ユーザだけがポストできます。 このようなイベントは,root と admin グループの全メンバがアクセスできます。 [例に戻る]

  3. sys.unix.evm.msg.user で始まる名前を持つクラスのイベントは,すべてのユーザがポストやアクセスを行うことができます。 [例に戻る]

  4. すべてのユーザが event_get サービスを実行できます。 [例に戻る]

権限ファイルを変更した場合は,Event Manager デーモンに変更を知らせるために evmreload コマンドを実行しなければなりません。

13.2.3.3    認証を含むリモート・アクセス

Event Manager では,リモート・システム上で実行されているクライアントにアクセスできます。 このため,中央のシステムからイベントの監視および取り出しができます。 このアクセスは,どのシステムからも可能にしたり,あるいは特定のシステムだけに制限することができます。 また,リモート・システム上の個々のユーザごとに,イベントへのサブスクライブ,イベントのポスト,あるいはイベントの取り出しを行うためのパーミッションを設定できます。

evmwatchevmget,および evmpost コマンド行ユーティリティに -h オプションを使用してホスト名または IP アドレスを指定すると,リモート・コネクションを確立できます。 または,イベント・ビューアの「Get Events From...」ダイアログ・ボックスで,リモート・ホスト名を指定する方法でも確立できます。 イベント・ビューアについては,13.3.11 項 を参照してください。

リモート・アクセスを制御する 2 つのファイルがあります。

/etc/evmdaemon.conf

remote_connection の値が true の場合,リモート・アクセスは許可されます。 この値が false (省略時の値) の場合,リモート・アクセスは拒否されます。

/etc/evm.auth

このファイルの remote_host の設定によって,どのリモート・システムにアクセスが許可されるか,そのリモート・システム上のどのユーザがアクセスを許可または拒否されるか,認証メソッドは,callbackopen のどちらが使用されるかが制御されます。

リモート・ホスト,ユーザ,および認証の設定

/etc/evmdaemon.conf ファイルの remote_connection の値に true を設定した後で,リモート・ホスト・システムとユーザのアクセスを細かく設定します。 この設定は,/etc/evm.auth ファイルの remote_host の設定によって行います。

remote_host の設定は,次のフォーマットで行います。

remote_host  {
             host           "1 つ以上のホスト名のリスト"
             authentication 認証タイプ
             port           ポート番号
             users          "ユーザの指定"
             }

これらのパラメータの順序は任意ですが,ホストの指定は,通常,最初に行います。 これらのパラメータを,以下に説明します。

host

host パラメータには,ローカル・ホストの Event Manager にアクセスを許可する 1 つ以上のホストのリストを指定します。 このリストのホストは,ホスト名でも IP アドレスでも,指定できますが,クラスタ別名は許されていません。 ホストのリストを二重引用符で囲むと,スペース文字またはコンマで区切ることができます。 二重引用符で囲まない場合は,ホスト名はコンマで区切ってください。 次に示すのは,正しいホストのリスト例です。

  host "hostA hostB hostC"
  host "hostM, hostN"
  host hostX,hostY,hostZ

authentication

この引数では,リストされたホストにアクセスする場合に使用される認証のタイプを指定します。 2 つのタイプ evm_openevm_callback があります。 evm_open を指定すると,リモート・ホストへのオープン・アクセスが可能になります。 evm_callback を指定すると,認証が行われ,その際にユーザを確認するためにリモート・ホストに連絡が行われます。

どちらの認証タイプも指定できます。 ここで示す例の場合,リモート・ホストが evm_callback を使用できるかどうかをローカル・ホストが調べます。 使用できる場合,evm_callback が使用されます。 使用できない場合,evm_open が使用されます。 例は,この項の末尾にある「」にあります。

port

ポート番号では TCP/IP ポートを指定します。

users

この引数で,ローカル・ホストにアクセスできるリモート・システムのユーザと,そのローカル認証方法を指定します。 ここでの指定方法にはいくつかの種類があります。 最も単純な形式では,次のように,リモート・ユーザを個々に指定します。

        users    adam
 

これは,リモート・ユーザ adam が,ローカル・ホスト上で,ローカル・ユーザ adam と同じ認証を受けることを意味します。

等号 (=) を使用すると,リモート・ユーザをローカル・ユーザにマップできます。 リモート・ユーザ remo をローカル・ユーザ lcal にマップするには,次のように指定します。

        users    remo=lcal

リモート・ユーザ名の前に,ハイフンすなわち負符号 (-) を指定すると,このユーザのアクセスは拒否することを意味します。

        users    -eve
 

プラス記号 (+) は,すべてのユーザを意味します。 次の例では,すべてのリモート・ユーザがローカル・ログイン nobody と同じ認証を受けることを意味します。

        users    +=nobody

次の形式では,プラス記号によって,すべてのリモート・ユーザがローカル・システムで相当するユーザにマップされます。

        users    +=+

これらのユーザ指定を組み合わせて使用できます。 たとえば次の指定では,root は root 権限を持ち,cain を除くその他すべてのユーザは,ローカル・ユーザ nobody と同じ権限を持つことを意味します。 リモート・ユーザ cain は,アクセスが拒否されます。

        users   root
        users   cain-
        users   +=nobody

次の例では,システム systemA,systemB,および systemC は,コールバック認証によって,このコンピュータへのリモート・アクセスが許可されます。 これらのリモート・システム上の各ユーザは,ローカル・システムの user1 にマップされます。

remote_host {
            host  "systemA, systemB,systemC"
            users  +=user1
            authentication  evm_callback
            }

次の例では,システム systemA,systemB,および systemC は,コールバック認証によって,このコンピュータへのリモート・アクセスが許可されます。 user2 と user3 を除く,これらのリモート・システム上の各ユーザは,ローカル・システムの user1 にマップされます。 user2 と user3 は,明示的にアクセスを拒否されています。

remote_host {
            host  "systemA, systemB,systemC"
            users  +=user1
            users  -user2
            users  -user3
            authentication  evm_callback
            }

次の例でも,システム systemA,systemB,および systemC は,コールバック認証によって,このコンピュータへのリモート・アクセスが許可されます。 これらのリモート・システム上の各ユーザは,user2 を除いて,ホスト・システム上で相当するユーザにマップされます。 user2 は,アクセスが拒否されます。

remote_host {
            host  "systemA, systemB,systemC"
            users  +=+
            users  -user2
            authentication  evm_callback
            }

次の例では,すべてのシステムが,コールバック認証によって,このコンピュータへのリモート・アクセスが許可されます。 root 以外のすべてのリモート・ユーザは,ローカル・システムの「special_user」にマップされますが,root は,アクセスが拒否されます。

remote_host {
            host +
            users  +=special_user
            users  -root
            authentication  evm_callback
            }

次の例では,システム systemA と systemB は,オープン認証によって,リモート・アクセスが許可されます。 すべてのユーザは,Event Manager にアクセスできます。

remote_host {
            host  "systemA, systemB"
            authentication evm_open
            }

次の例では,5 つのリモート・システムがローカル・ホスト上の Event Manager にアクセスできますが,アクセスできる範囲は異なります。 リモート・システム julius,augustus,および caesar では,ユーザ root と adm だけが Event Manager にアクセスできます。 これらのシステムのいずれかがこれらのユーザのための接続を試みる場合に,ローカル・システムの Event Manager は,これらのユーザが evm_callback 認証を使用できるかどうかを調べます。 使用できれば,その認証を使用します。 使用できなければ,evm_open を使用します。 リモート・システム plato と socrates のすべてのユーザは,自分自身にマップされ,evm_callback 認証だけが使用されます。

remote_host {
        host  "julius augustus caesar"
        users  root
        users  adm
        authentication  evm_callback
        authentication  evm_open
        }
 
remote_host {
        host  plato,socrates
        users  +=+
        authentication  evm_callback
        }

13.2.4    ログ・ファイルの管理

Event Manager チャネル・マネージャ evmchmgr は,チャネルの fn_cleanup 関数を使って,ログ管理機能を提供します。 この機能は,チャネル構成ファイル evmchannel.conf によってどのチャネルにも定義することができます。 このファイルについての詳細は,13.2.2.2 項を参照してください。

省略時の設定では,チャネル・クリーンアップ関数は,Event Manager が起動するときに実行され,その後は毎日午前 2:00 に実行されます。 チャネル構成ファイルの cleanup_time 値を編集することで,この時間を変更することができます。 クリーンアップがスケジュールされたら,チャネル・マネージャはイベント・チャネルのリストをスキャンし,ファイルで指定された各チャネルに対して,fn_cleanup コマンドを実行します。

evmlog のクリーンアップ関数 evmlog_cleanup には,次の 2 つの引数が指定できます。

この関数は,find ユーティリティを使ってアーカイブの間隔より古いログを見つけて圧縮 (zip) します。 また,削除の間隔より古いアーカイブ・ファイルは削除します。 これらの間隔の値は,チャネル構成ファイルの関数定義を編集して,変更することができます。 また,これらの値をゼロに設定すると,この関数は無効になります。

省略時のチャネル構成ではまた,misclog イベント・チャネルを通じて,SysMan Station のメッセージ・ログ・ファイル用の類似のクリーンアップ機能も提供します。 syslog および binary のエラー・ログ・チャネルは,crontab ファイル内のエントリを使用して管理することができます。 バイナリ・エラー・ログ・ファイルは,通常日次ベースでは管理されず,チャネルのクリーンアップ関数が,ログのサイズを報告する Event Manager イベントを毎日ポストします。 ログが目立って大きくなった場合,ログ・エントリを調べてください。 必要ならば binlogd のクリーンアップ・オプションを使って,クリーンアップを開始してください。 詳細は, binlogd(8) を参照してください。

evmget コマンドは,アーカイブされた (zip された) ログに格納されている evmlog イベントは取り出しません。 アーカイブされたログからイベントを取り出すには,まず gunzip コマンドでそれらを圧縮解除しなければなりません。 アーカイブ・ファイルの圧縮解除については, gunzip(1) を参照してください。

13.2.5    イベント・テンプレート

イベント・テンプレートは,中央に保持されているイベントの記述です。 イベント・テンプレートは,次の目的で使用します。

イベント・テンプレートの定義は,テンプレート・ファイルに保持されています。 このファイルは,システムのテンプレート・ディレクトリ /usr/share/evm/templates の下の (またはこれにリンクされた) ディレクトリに格納されているテキスト・ファイルです。 インストレーション固有または他社のイベント・テンプレートがある場合は,次の手順でロードします。

  1. 適切な名前のサブディレクトリをローカル・テンプレート・ディレクトリ /var/evm/adm/templates に作成し,その中にイベント・テンプレートをコピーします。

  2. -d オプションを指定して evmreload コマンドを実行し,Event Manager デーモンに内部テンプレート・データベースを再ロードするように指示します。

Event Manager が認識するには,テンプレート・ファイルに適切な所有権と許可が必要です。 詳細は, evmtemplate(4) を参照してください。 新しいイベント・テンプレート・ファイルのインストールについては,『プログラミング・ガイド』を参照してください。

イベントがポストされるたびに,Event Manager デーモンは,ポストされたイベントと名前の一致するテンプレート・イベントをその内部テンプレート・データベースで探します。 次に,そのテンプレート・イベントに保持されている,中央に集められたデータ項目を取り出します。 そしてこれらのデータ項目を,プログラムがイベントをポストしたときに渡した項目と結合します。 これにより,イベントがマージされ,これがサブスクライブ側に配布されます。

13.2.6    新しい Event Manager クライアントのインストール

新しいアプリケーションをインストールし,その機能を使うために新しい管理スクリプトを開発する際に,新しいイベントをイベント・セットに追加することができます。 イベントを追加する際には,Event Manager 構成ファイルと権限ファイルを変更した後,新しいテンプレートを追加する必要があります。 構成ファイルについては,13.2.2 項を参照してください。 新しいユーザの権限を変更する手順については,13.2.3.2 項を参照してください。

新しいイベント・テンプレートは,次の手順で追加します。

  1. 13.2.5 項で説明したとおりに,新しいテンプレート・ファイルを作成します。

  2. テンプレート・ファイルを /var/evm/adm/templates ディレクトリまたはサブディレクトリにコピーします。

  3. -d オプションを指定して evmreload コマンドを実行し,Event Manager デーモンに内部テンプレート・データベースを再ロードするように指示します。

テンプレート・ファイルに必要な所有権と許可についての詳細は, evmtemplate(4) を参照してください。

Event Manager クライアント・アプリケーションの開発については,『プログラミング・ガイド』 を参照してください。

13.2.7    binlog イベント変換ユーティリティの構成

イベント変換を行うユーティリティには,Compaq Analyze と DECevent の 2 つがありますが,新しいプロセッサでは DECevent がサポートされておらず,Compaq Analyze だけがサポートされています。

Compaq Analyze は,エラー・イベントの分析および変換を行う,規則ベースのハードウェア障害管理診断ツールです。 Compaq Analyze の複数イベント相関分析機能により,システムのイベント・ログ・ファイルに格納されているイベントを分析したり,他のシステムからのイベントを分析することができます。 ここでいう他のシステムには,他のオペレーティング・システム (OpenVMS や Windows NT など) も含まれます。

DECevent は,バイナリ・エラー・ログ・イベントのイベント変換を行う,規則ベースの変換/レポート・ユーティリティです。 Event Manager は DECevent の変換機能 dia を使用して,バイナリ・エラー・ログ・イベントを可読形式に変換します。

Event Manager インフラストラクチャは Event Manager 形式のイベントのみを直接認識しますが,イベントは binlogd デーモンなどの他チャネルを通してポストされます。 これらのイベントは,下位レベルのイベントを可変データとして Event Manager イベントに挿入することで,ラッパー Event Manager イベントとして Event Manager に渡すことができます。 その後,パッケージ全体を Event Manager に渡すことができます。 Event Manager は,可変部の内容やフォーマットは意識しません。

バイナリ・ロガー・デーモン binlogd は,この方法を使用して,自分のイベントを Event Manager を通して利用可能にします。 binlogd デーモンはオペレーティング・システムからイベントを受信すると,そのイベントを最初に自分のログ・ファイルに格納し,クライアントに配布します。 その後,binlogdsys.unix.binlog という名前で始まる Event Manager イベントを作成し,binlogd イベント・データを含む binlog_event という名前の変数を追加します。 最後に binlogd は,将来配布できるように,パッケージを Event Manager デーモンにポストします。 Event Manager デーモンはパッケージを Event Manager イベントのように取り扱い,binlog_event 変数の内容については直接は認識しません。

コマンド行から evmshow -d コマンドを実行するか,イベント・ビューアのイベント要約ウィンドウの [詳細...] ボタンを選択してイベントの詳細表示を要求すると,Event Manager は,/etc/evmchannel.conf ファイル内でこのイベントに対して定義されている詳細表示プログラムを実行します。 結果の表示は必ず,イベントの説明と,内容の詳細表示で始まります。 イベントが binlogd イベントの場合,この表示の後に変換後の binlog_event 変数の内容が続きます。 この変換情報は,システムの問題のトラブルシューティングに役立ちます。 例 13-5 に,DECevent の変換を含む,binlogd イベントの詳細表示を示します。

例 13-5:  DECevent 変換を表示する binlogd イベント

=================== Binary Error Log event ====================
Event Manager event name: sys.unix.binlog.op.shutdown
 Binary error log events are posted through the binlogd
 daemon, and stored in the binary error log file,
 /var/adm/binary.errlog. This event is posted by the shutdown(8),
 halt(8), and reboot(8) commands when the system is being shut
 down. The message includes details of the user who initiated
 the shutdown.
===============================================================
Formatted Message:
    System shutdown msg:  System rebooted by root:
Event Data Items:
    Event Name        : sys.unix.binlog.op.shutdown
    Priority          : 200
    Timestamp         : 26-Jan-2000 20:54:36
    Host IP address   : 16.69.224.11
    Host Name         : kopper
    Format            : System shutdown msg: $message
    Reference         : cat:evmexp.cat:300
Variable Items:
    subid_class = 301
    message = "System rebooted by root:"
    binlog_event = [OPAQUE VALUE: 96 bytes]
============================ Translation =====================
DECevent version: V3.2
 
Logging OS                       2. operating system
System Architecture              2. Alpha 
Event sequence number          752. 
Timestamp of occurrence             26-JAN-2000 20:54:36   
Host name                           kopper 
System type register      x0000000F  AlphaStation 600 or 500
Number of CPUs (mpnum)    x00000001 
CPU logging event (mperr) x00000000 
Event validity                   1. O/S claims event is valid
Event severity                   5. Low Priority 
Entry type                     301. Shutdown ASCII Message Type
SWI Minor class                  9. ASCII Message 
SWI Minor sub class              2. Shutdown 
ASCII Message                    System rebooted by root:
===============================================================
 

Event Manager は,binlogd イベントを DECevent または Compaq Analyze に渡して,そのイベントの変換情報を得ます。 どちらのプログラムも利用できないか,変換に失敗した場合,変換情報のエリアには,失敗を示すメッセージが表示されます。

いくつかの要因により,個々のシステムで利用できる binlogd イベント変換情報のタイプが決まります。

システムが binlogd イベントの変換に DECevent を使用する場合や,ローカル・システム上で稼働している Compaq Analyze サーバを使用する場合には,標準の構成を変更する必要はありません。 リモート・システム上で稼働している Compaq Analyze サーバを使用する場合は,/etc/evmchannel.conf ファイルを編集する必要があります。 省略時のインストレーションでは,binlog イベント・チャネルの fn_details 行は,次のように構成されています。

fn_details    "binlog_details -decevent -ca localhost"
 

この行は,DECevent が利用可能であればそれを変換に使用することを Event Manager に指示します。 利用可能でなければ,Event Manager はローカル・ホスト上で稼働している Compaq Analyze サーバに接続しようとします。 どちらのオプションも成功しなかった場合,Event Manager は Compaq Analyze のスタンドアロン・モードでの実行を試み,それでも失敗したら,変換は行われません。 これらのオプションは,リスト内の最初の 2 項目として残しておいてください。 ただし,Compaq Analyze サーバが稼働しているシステムが他にある場合は,さらに -ca 項目を追加することができます。

次の例では,Event Manager は DECevent,ローカル・システム上の Compaq Analyze,リモート・システム gandalf 上の Compaq Analyze,最後にリモート・システム tigger 上の Compaq Analyze を順に試します。

fn_details   "binlog_details -decevent -ca localhost -ca gandalf -ca tigger"
 

構成ファイルを編集した後には,evmreload -c コマンドを実行して,ファイルがアップデートされたことを Event Manager チャネル・マネージャに認識させなければなりません。

Event Manager は Compaq Analyze サーバを起動しないため,変換を成功させるためには,選択したシステム上で Compaq Analyze サーバがすでに稼働していなければなりません。 このサーバは通常,システムの初期化時に自動的に起動されます。 詳細は,Compaq Analyze のドキュメントを参照してください。

いずれかの変換ユーティリティがローカル・システム上で利用可能かどうかを調べる手順については,13.4 節を参照してください。

13.3    システム管理での Event Manager の使用

Event Manager の複数のイベント・ソースを監視し 1 つのイベント・ストリームとして結合する能力は,システムのアクティビティを監視する際に非常に役立ちます。 省略時設定では,ロガーは 600 (警告) 以上の優先順位を持つイベントがポストされたときにメールを root ユーザに送ります。 ただし,イベント・ビューアやコマンド行ユーティリティを用いて,すべてのイベント・ログを毎日確認する必要があります。 選択した基準に従って別の手段 (ポケットベルにメッセージを送信するなど) をとるように,ロガーを構成することができます。 また,端末で evmwatch コマンドを使ってイベントの発生を監視することができます。

以降の項では,イベント動作の監視や表示に使用できるコマンドについて,例を示します。 Event Manager のコマンド・セットに慣れてくると,システムで何が起こっているかを簡単に追跡できるコマンド・セット,シェル・スクリプト,およびフィルタを簡単に作成できるようになります。

13.3.1    evmshow を使用した,イベントの表示

Event Manager イベントはバイナリ・データのパッケージであるため,端末上に表示するにはテキストへ変換しなければなりません。 evmshow コマンドは stdin ストリームまたは指定されたファイルからバイナリの Event Manager イベントを読み取り,同じイベントを stdout にテキスト形式で出力します。 たとえば,Event Manager イベントが入っているファイルの内容を,次のコマンドで表示します。

# cat my_events | evmshow | more
 

このコマンドは,ログ・ファイルからイベントを取り出して省略時の方法で表示します。 つまり,フォーマット・データ項目を各イベントから取り出し,参照している変数をその値に置き換え,展開して表示します。 変数への参照は,ドル記号 ($) で示されます。 このため,my_events ファイルにフォーマット・データ項目 AdvFS: AdvFS domain $domain is full が含まれ,root_domain という値の domain という変数がイベントに含まれている場合,対応する出力行は次のとおりになります。

AdvFS: AdvFS domain root_domain is full

この情報では何が発生したかは分かりますが,いつ発生したかや,イベントの重要度は分かりません。 -t オプションを使用して表示テンプレートを指定することによって evmshow コマンドの出力を変更し,イベント内にタイムスタンプや優先順位などのデータ項目を含めることができます。 表示テンプレートとは,イベントに表示するデータ項目と,それらをどのように表示するかを示すテキスト文字列です。

次の例では,表示テンプレートを使用して,タイムスタンプ,優先順位,フォーマットされたイベント・メッセージのあるイベントを表示します。 表示テンプレートでは,表示される各項目の名前の前に,アットマーク (@) が付いています。 アットマーク 2 個 (@@) は,イベントのフォーマット項目を展開して表示することを示します。 2 番目の行は,ドメイン・フル・イベントの出力です。 この出力は,イベントの優先順位が大カッコで囲まれ,メッセージ・テキストの前にスペースが 2 個あり,表示テンプレートで指定されたとおりになっています。

# cat my_events | evmshow -t "@timestamp [@priority]  @@" | more
22-Jun-2000 11:22:27 [600]  AdvFS: AdvFS domain root_domain is full

独自の表示テンプレートをセットアップして,任意のフォーマットで重要な項目を表示することができます。 すべてのデータ項目のリストについては, EvmEvent(5) を参照してください。 使用するスタイルが決まれば,省略時の表示テンプレートを EVM_SHOW_TEMPLATE 環境変数に設定することで,コマンド行での入力を少なくすることができます。 次の Korn シェル (ksh) コマンドは,前の例と同等です。

# export EVM_SHOW_TEMPLATE="@timestamp [@priority]  @@"
# cat my_events | evmshow | more
 
 

イベントの情報がさらに必要な場合は,evmshow コマンドに -d オプションを指定することによって,説明と内容のフル・ダンプを含む,詳細表示を要求できます。 次の例は,AdvFS ドメイン・フル・イベントの詳細表示です。

# cat my_events | evmshow -d | more
============================ EVM Log event =======================
EVM event name: sys.unix.fs.advfs.fdmn.full
 
    This event is posted by the AdvFS filesystem to provide
    notification that the specified AdvFS domain is full.  No more
    space is available for writing.    [1]
==================================================================
 
Formatted Message:
    AdvFS: AdvFS domain root_domain is full    [2]
 
Event Data Items:   [3]
    Event Name        : sys.unix.fs.advfs.fdmn.full
    Cluster Event     : True
    Priority          : 600
    PID               : 1177
    PPID              : 724
    Timestamp         : 22-Jun-2000 11:22:27
    Host IP address   : 0.0.0.0
    Host Name         : x.x.example.com
    User Name         : root
    Format            : AdvFS: AdvFS domain $domain is full   [4]
    Reference         : cat:evmexp.cat:450
 
Variable Items:    [5]
    domain (STRING) = "root_domain"
 
======================================================================
 
 

  1. そのイベントについて説明するテキスト文字列。 場合によっては,このデータ・フィールドに,問題を解決するために推奨されるアクションが示されます。 [例に戻る]

  2. 「Formatted Message」セクション。 [例に戻る]

  3. 「Event Data Items」セクション。 イベントに含まれる標準的なデータ項目がすべてリストされます。 各項目の説明については, EvmEvent(5) を参照してください。

    ここに表示される項目は多くのイベントで一般的なものですが,一部の項目がない場合や,追加の項目が表示される場合があります。 たとえば,大半のイベントはクラスタ内の全ノードには配布されないため,多くの場合「Cluster Event」項目は表示されません。 [例に戻る]

  4. Format」データ項目。 「Formatted Message」データ項目の内容とほぼ同じです。 ただし,$ 記号が前に付いた domain という変数への参照が含まれています。 [例に戻る]

  5. 「Variable Items」セクション。 変数 domain の値が入っています。 [例に戻る]

詳細表示のイベントを選択する方法は,13.3.12.2 項 を参照してください。

evmshow -x コマンドを使用して,説明だけを表示することができます。 また,-x オプションと -t オプションを一緒に使用すると,イベントの要約を表示し,その直後にその説明を表示することができます。 例を次に示します。


 #cat my_events | evmshow -x -t "@timestamp [@priority]  @@" | more
21-Jun-2002 11:22:27 [600] AdvFS: AdvFS domain root_domain
is full
 This event is posted by the AdvFS filesystem to provide
 notification that the specified AdvFS domain is full.
 No more space is available for writing.
 

この項の例では,1 つのログ・ファイルに入っている Event Manager イベントの表示方法を示します。 さまざまなシステム・ログ・ファイルに格納されているイベントを表示したり,イベントの発生状況を監視することもできます。 このようにするには,evmget コマンドと evmwatch コマンドを使用します (13.3.3 項および13.3.6 項を参照)。

多くのシステムは大量のイベントを生成しますが,ほとんどが通常動作の報告です。 イベント・フィルタを使用して,表示を,関心のあるイベント・セットに限定してください。 13.3.2 項では,Event Manager のフィルタ機能の概要について説明しています。

イベントの発生元に関係なく,evmshow コマンドを使用してイベントを表示用にフォーマットできます。 表示テンプレートの詳細については, evmshow(1) を参照してください。

13.3.2    イベント・フィルタの概要

この項では,イベント・フィルタの概要について説明し,直前の項の evmshow コマンドの例に当てはめて説明します。 フィルタリングは,イベントの取り出しおよび監視の技法を説明する,後半の項で広く使用されています。 完全なフィルタ構文は, EvmFilter(5) のリファレンス・ページに定義されています。

Event Manager イベント・フィルタは,取り出すイベントを Event Manager に知らせるテキスト文字列です。 たとえば,フィルタ文字列 [priority >= 600] は,優先順位が 600 以上のイベントを選択します。 フィルタは簡単に指定できますが,フィルタ言語は強力です。 多少練習すれば,監視したいイベント・セットを正確に定義するフィルタ表現を簡単に作成して格納できます。 フィルタを使用するのは,一部の Event Manager コマンド行ユーティリティ,Event Manager ロガー,およびシステム・デーモンとクライアント・アプリケーションです。

evmshow コマンド,evmget コマンド,および evmwatch コマンドでは,-f オプションをサポートし,このオプションを使ってフィルタ文字列を指定します。 次の例のようにして,表示するイベントを my_events ファイルから選択することができます。

# export EVM_SHOW_TEMPLATE="@timestamp [@priority]  @@"
# cat my_events | evmshow -f "[priority >= 600]" | more

(この例の概要は,13.3.1 項で説明されています。) この例では,-f オプションでフィルタを指定し,600 以上の優先順位を持つイベントを選択しています。 このコマンドはすべてのイベントをファイルから読み取りますが,フィルタ文字列と一致したイベントだけを返します。

取り出すイベントの名前が分かっている場合は,次の例のように,フィルタにそれらの名前を指定することができます。

# cat my_events | evmshow -f "[name sys.unix.fs.advfs.fdmn.full]" | more

名前のコンポーネントの部分には,次のようにワイルドカード文字を使用できます。

たとえば,直前のコマンド例を短くして,次の例のようにすることができます。

# cat my_events | evmshow -f '[name *.advfs.fdmn.full]' | more
 

このワイルドカードのアスタリスクが,コンポーネント sys.unix.fs と一致します。 ワイルドカード文字をシェルがファイル名に展開しないようにするには,フィルタ文字列を,ダブルクォートではなく,シングル・クォートで囲みます。 この注意は,シェル・コマンド内で特殊文字を使用する場合はいつでもいえることです。

名前でフィルタリングする場合,Event Manager はコマンドで指定されていない場合でも,名前文字列の末尾に ワイルドカード .* があるものとして扱います。 このため,指定したものより名前コンポーネントの数が多いイベントを受け取ることがあります。 次の 2 つのコマンドは同等ですが,1 番目のコマンドの最後のワイルドカード (.*) は不要です。

# cat my_events | evmshow -f '[name *.advfs.*]'
# cat my_events | evmshow -f '[name *.advfs]'

evmshow コマンドの実行時に表示テンプレート内の項目の 1 つとして @name を指定すると,イベントの名前を表示させることができます。

フィルタの構文では,AND キーワード,OR キーワード,および NOT キーワードを使用して,複数の条件を 1 つのフィルタに結合することができます。 また,カッコを使用して,条件をグループ化することができます。 次のコマンド例は,advfs というコンポーネントを名前に含み,優先順位が 600 以上のすべてのイベントを選択します。

# cat my_events | evmshow -f '[name *.advfs] and [priority >= 600]'

次のコマンドは,優先順位に関係なく,名前コンポーネントが binlog のイベントも選択します。 この例では,priority キーワードが prinamena に短縮されています。 大半のフィルタ・キーワードは, EvmFilter(5) のリファレンス・ページに説明されているように短縮形で記述できます。

# cat my_events | evmshow -f '([na *.advfs] and [pri >= 600]) or [na *.binlog]'

この項の例では,最もよく使用されるフィルタ・キーワードについて説明します。 evmshow コマンドでのフィルタの使い方と,以下の項で説明されている Event Manager コマンドに慣れたら,より高度なフィルタ機能を使用して,役に立つフィルタを作成して保存したり,最も必要なイベントを選択する能力を高めることができます。 高度なフィルタリング技法については 13.3.12 項を参照し,完全な構文については EvmFilter(5) のリファレンス・ページを参照してください。

13.3.3    evmget を使用した,格納されているイベントの取り出し

システム・ログ・ファイルには,さまざまなフォーマットと詳細度レベルでイベントが格納されているため,従来のシステム・ユーティリティを使用してすべてのイベントに対する整った表示を行うことは困難です。 evmget コマンドを使用すると,各種のログ・ファイルからイベントを取り出し,まだ Event Manager の形式でなければイベントを Event Manager イベントに変換し,Event Manager イベントの単一ストリームを返すことによって,整った表示を行うことができます。 evmshow コマンドを使用すると,Event Manager イベント・ストリームを表示形式に変換できます。

次のコマンド・パイプラインは,evmget コマンドを使用してすべてのシステム・イベントを取り出し,表示するために evmshow コマンドに渡します。

# evmget | evmshow -t "@timestamp [@priority]  @@" | more

evmget コマンドは,Event Manager デーモンへのサービス・コネクションを確立します。 このコネクションは,get サーバ・プログラム /usr/sbin/evm_getsrv の新しいコピーを起動します。 get サーバ・プログラムはチャネル構成ファイルを読み取り,get 関数 (通常,チャネル構成ファイル /etc/evmchannel.conf に構成されている各チャネルに対するシェル・スクリプト) を実行します。 この構成ファイルについては,13.2.2.2 項を参照してください。

get 関数は,次の処理を実行します。

すべてのチャネル get 関数が実行され,すべてのイベントが返却されると,get サーバ・デーモンと evmget コマンドはどちらも終了します。

注意

イベントはテキスト行または特殊なバイナリ・フォーマットとしてログ・ファイルに格納されていることがありますが,evmget コマンドはすべてのイベントを,evmshow に渡して表示することができる,バイナリ形式の Event Manager イベントとして返します。 evmget の出力を直接端末に送信すると,このコマンドはエラー・メッセージを表示します。 これは,バイナリ出力は適切に表示できないので,端末の設定に影響を与えることがあるためです。 出力を more コマンドや pg コマンドなどの他のコマンドにパイプすると,evmget コマンドはこのエラーを検出できないため,ランダムな文字が表示されます。

evmshow コマンドと同様に, evmget コマンドは返却するイベントを制限するためのフィルタ・オプションをサポートしています。 たとえば,次のコマンドは,優先順位が高いイベントだけを表示します。

# evmget -f '[pri >= 600]' | evmshow | more

evmshow コマンドでフィルタを指定するより evmget コマンドでフィルタを指定する方がより効果的です。 これは,evmget コマンドがフィルタ文字列をイベント・チャネルの get 関数 (フィルタに一致するイベントだけを返す) に渡すためです。 get サーバ・デーモンから evmget コマンドに返されるイベントが少なくなり,コマンドが転送し処理するイベントが少なくなるため,コマンドの動作が速くなります。

取り出されたイベントを後で分析するために保存したい場合や,別のシステムにコピーしたい場合は,evmget コマンドの出力をファイルにリダイレクトできます。 たとえば,次のコマンドを入力します。

# evmget -f '[pri >= 600]' > my_events

evmget コマンドのバイナリ形式の出力を保存する方が,evmshow コマンドのテキスト形式の出力を保存するよりも,柔軟性があります。 後で,バイナリ・ファイルをソートしフィルタリングして evmshow コマンドに渡し,好きなフォーマットで表示することができます。

evmget コマンドを試してみると,複数のイベントがまとまって出力されていることが分かります。 多くの場合,すべてのバイナリ・エラー・ロガー・イベントが最初に出力されています。 それぞれのまとまりの中では,イベントは一般的に,日時順に並んでいます。 これは,省略時のチャネル構成ファイルでは binlog イベント・チャネルが最初に指定されており,その get 関数が最初に実行されるためです。 各 get 関数はイベントを順に evmget コマンドに渡し,evmget コマンドはそれらのイベントを受け取った順で出力します。 イベントを何らかの順序 (多くの場合,日時順) で表示したくなるので,イベントを evmsort コマンド (13.3.4 項を参照) にパイプする必要があります。 13.3.5 項では,パイプラインを使用しないで,イベントを取り出し,ソートし,表示することができる,-A オプションを指定した evmget コマンドの使用方法について紹介します。

システムの規模やタイプ,記録されるイベントの数によっては,イベントの取り出しに長時間かかることがあります。 これは,取り出し操作のたびに,各チャネルの get 関数がそのログ・ファイルを読み取り,イベントを Event Manager イベントに変換してから,イベントを evmget コマンドに渡すかどうかを判断するためにフィルタ文字列を適用する (フィルタがある場合) 必要があるためです。 ログ・ファイルが大きくなるほど,処理に時間がかかります。 ログ・ファイルを注意深く管理すると,処理を速くするのに役立ちます。 特定のイベント・チャネルに属しているイベントだけを表示したい場合は,evmget -C コマンドを使用して指定したチャネルだけを表示するようにすると,処理時間を短くできます。 たとえば,次のコマンドを入力します。

# evmget -f '[pri >= 600]' -C binlog | evmshow | more

この例では,get 関数は binlog チャネルについてのみ処理するため,コマンドの作業が早く完了します。 フィルタ文字列が指定されており,優先順位が 600 以上のイベントが返却されます。 どのようなチャネルが構成されているかは,evminfo -lc コマンドを使用するか,チャネル構成ファイルを調べると分かります。 詳細については, evminfo(1) を参照してください。

13.3.4    evmsort を使用した,イベントのソート

evmsort コマンドは Event Manager イベントのストリームを入力とし,要求された順序でそのイベントをソートし,stdout ストリームにイベントを書き込みます。 このコマンドは evmget コマンドの出力をソートするのに最も適していますが,どのソースからの Event Manager イベントのソートにも使用できます。 詳細は, evmsort(1) を参照してください。

13.3.3 項では,evmget コマンドで取り出したイベントは,イベント・チャネル構成に応じて,まとまって出力されると説明しました。 evmsort コマンドを使用すると,evmshow コマンドに送って表示する前に,イベントを希望の順序にソートすることができます。 次の例は,一般的なコマンド・シーケンスです。

# export EVM_SHOW_TEMPLATE="@timestamp [@priority]  @@"
# evmget -f '[pri >= 600]' | evmsort | evmshow | more
 

特に指定しなければ,evmsort コマンドはイベントを日時順でソートします。 このため,このコマンドは多くの場合,適切です。 別の方法でイベントをソートしたい場合は,-s オプションを使用してソート指定を宣言できます。 ソート指定とは,イベントをソートするデータ項目であるソート・キーを 1 つ以上定義するテキスト文字列です。 この指定は,コロン (:) で区切られたデータ項目名のリストです。 例を次に示します。

priority:timestamp

上記の指定は,優先順位の同じイベントをタイムスタンプ順にソートします。 このため,返却されるイベントの最初のグループは,発生順にソートされた,優先順位が最も低いイベントです。 この指定は,次のように使用します。

# evmget -f '[pri >= 600]' | evmsort -s "priority:timestamp" | evmshow | more

省略時のソート順は昇順ですが,マイナス記号 (-) を付加すると,項目指定子ごとに降順に変更できます。 プラス記号 (+) を指定すると,明示的に昇順を要求できます。 たとえば,次のコマンドは優先順位が最も高いイベントを最初に表示します (降順) が,各優先順位内ではイベントは古い順にソートされます (昇順)。

# evmget -f '[pri >= 600]' | evmsort -s "priority-:timestamp+" | evmshow | more

表示テンプレート構文との一貫性を保つために,evmsort コマンドでは,各項目指定子の前に @ (アット) 文字を付けることができます (13.3.1 項を参照)。 このようにする必要はありませんし,付けても動作には影響しません。

ソート方法が決まったら,EVM_SORT_SPEC 環境変数を設定して,省略時のソート・シーケンスを変更できます。 次の Korn シェル (ksh) コマンドは,上記の例と同等です。

# export EVM_SORT_SPEC="priority-:timestamp+"
# evmget -f '[pri >= 600]' | evmsort | evmshow | more
 

-s オプションで別のソート指定を渡すと,いつでも EVM_SORT_SPEC 変数の値より優先させることができます。

13.3.5    -A オプションを使用した,コマンド文字列の簡略化

Event Manager のコマンドは,ブロック構造で設計されており,各コマンドは特定の動作を 1 つ行います。 このことにより,イベント情報を操作するシェル・スクリプトの開発を,非常に柔軟に行うことができます。 コマンドをコマンド行から入力する場合は,簡単な形式のコマンドを使用することもできます。

イベント取り出しの最も一般的なコマンド・シーケンスでは,evmget コマンドを evmsort コマンドにパイプした後,evmshow コマンドにパイプします。 この後,テキスト出力を more コマンドにパイプし,出力を表示することができます。 例を次に示します。

# evmget -f '[pri >= 600]' | evmsort -s "priority-:timestamp+" | evmshow | more

evmget -A コマンド・オプションを使用すると,上記のコマンドを簡単にすることができます。 このオプションは,コマンドの出力を他の Event Manager コマンドへ自動的にパイプします。 たとえば,-A オプションを使用すると,上記のコマンド例を次のように簡単にできます。

# evmget -A -f '[pri >= 600]' -s "priority-:timestamp+" | more

evmget -A コマンドを起動すると,evmsort -A コマンドが自動的に起動され,出力がそのコマンドにパイプされます。 evmsort コマンドを起動すると,-A オプションの使用により evmshow コマンドが起動され,イベントがパイプで渡されて表示されます。 -s オプションによるソート指定や,-t オプションによる表示テンプレートを使用することができます。 これらのオプションは,それぞれ evmsort コマンドと evmget コマンドに渡されます。

evmwatch コマンドは,-A オプションをサポートしています (13.3.6 項を参照)。

13.3.6    evmwatch を使用した,イベントの監視

evmwatch コマンドを使用すると,ターミナル・ウィンドウを通してイベントをアクティブに監視できます。 このコマンドは,サブスクライブを行う Event Manager のクライアントです。 このコマンドは Event Manager デーモンへのコネクションを確立し,サブスクライブ要求を送信し,イベントの受信を待機します。 イベントが到着すると,evmwatch コマンドはイベントを自分の標準出力ストリーム (stdout) に,バイナリ Event Manager イベントとして書き込みます。

evmwatch コマンドの出力はバイナリ・イベントのストリームであるため,これを表示することはできません。 evmshow コマンドを使用して,イベントをフォーマットしなければなりません。 次の例はすべてのイベントを監視し,発生するたびにターミナルに表示します。

evmwatch | evmshow -t "@timestamp [@priority]  @@"

システムのタイプとイベント動作のレベルによっては,イベントを表示するまでに,このコマンドがしばらく動作することがあります。 このコマンドは,ユーザが (普通は [Ctrl/c] を押して) コマンドを終了させてターミナルの制御を取り戻すまで,動作し続けます。

システムの正常動作時にポストされるイベントの多くは,優先順位の低い情報イベントです。 システムでのイベント動作が高レベルの場合は特に,これらのイベントをフィルタリングして外したいこともあります。 evmwatch コマンドにフィルタを指定すると,情報メッセージをフィルタリングできます。

# evmwatch -f "[priority >= 400]" | evmshow -t "@timestamp [@priority]  @@"

この例では,優先順位がエラー以上のイベントを監視します。 このフィルタ文字列を変更すると,常時発生する重要でないイベントのセットを除外することができます。 代わりに,特定のイベントのセットを監視しなければならないこともあります。

上記の例では,evmshow の出力が,表示用の more にパイプされていません。 これは,evmwatch コマンドがリアルタイムのモニタだからです。 evmwatch コマンドは,ファイルからイベントを表示するのではなく,発生するたびにイベントを出力します。 pgmore のようなコマンドでは,1 画面目のデータを表示した後,入力パイプからさらにデータを読み込む前にオペレータの入力を待機するため,長時間ほっておくとパイプラインが詰まってしまうことがあります。 Event Manager デーモンでは,クライアント (evmwatch コマンド) がバックログをクリアするのを待つことができないため,これにより evmwatch コマンドがイベントを紛失してしまいます。 イベントを pgmore にパイプする代わりに,evmwatch コマンドの出力を直接ターミナル・ウィンドウ上に表示し,スクロールバーを使用してイベント・リストを参照するようにします。

evmwatch コマンドの出力は,evmsort にパイプしないでください。 evmsort コマンドは入力の最後まで読み取らないと,イベントをソートできないためです。 通常 evmwatch コマンドは,明示的に終了させるまで,監視プログラムとして入力を待ちます。 このため,evmwatch コマンドの出力を直接 evmsort コマンドにパイプすると,evmsort コマンドからは何も出力されません。

-A オプションを使用すると,evmsort コマンドと evmshow コマンドが自動的に実行されるため,コマンド文字列が簡単になります。 evmwatch コマンドも -A オプションをサポートしており,このオプションを指定すると evmshow コマンドが自動的に実行されます。 evmwatch コマンドのオプションとして,表示テンプレートを次のように指定できます。

# evmwatch -A -f "[priority >= 400]" -t "@timestamp \
[@priority]  @@"

evmget コマンドを使用すると,関心のあるイベントのセットをファイルに捕捉し,後で参照することができます。 バイナリ形式でイベントを格納する方が,テキスト形式で格納するよりも便利です。 このため,evmwatch コマンドの出力を evmshow コマンドにパイプするのではなく,次のように直接ファイルにリダイレクトしてください。

# evmwatch -f "[priority >= 400]" > my_events

evmwatch コマンドは,シェル・スクリプト内でイベントを監視するのに役立つ,その他のオプションもサポートしています。 詳細については, evmwatch(1) を参照してください。

13.3.7    evmpost を使用した,クイック・メッセージ・イベントのポスト

大半のイベントはシステムおよびアプリケーション・ソフトウェアからポストされますが,コマンド行やシェル・スクリプトからイベントをポストしたい場合もあります。 たとえば,タスクが完了したことや,重要な事項を示すメッセージ・イベントをシステム・ログにポストすることができます。 システム・ログ内にエントリを作成すると,作成したエントリとの位置関係で,他のイベントがいつ発生したかが分かりやすくなります。

evmpost コマンドを使用すると,イベントをポストできます。 このコマンドの最も簡単な形式は,-a (管理者) オプションまたは -u (ユーザ) オプションを使用して指定できる,クイック・メッセージ形式です。 メッセージをポストするには,クォートされた文字列として,メッセージをコマンド行に指定します。

# evmpost -a "Fire drill started - evacuating computer room"

管理用クイック・メッセージは sys.unix.evm.msg.admin という名前でポストされるため,名前フィルタを使用して検索できます。

# evmget -f '[name *.msg.admin]' | 
evmshow -t 'timestamp [@priority]  @@'
27-Jun-2000 15:40:49 [200]  EVM admin msg: Fire drill started - evacuating computer room
 

特に指定しなければ,このメッセージは優先順位 200 の通知イベントとしてポストされます。 優先順位は,-p オプションで変更できます。 たとえば,優先順位として 400 を指定すると,メッセージがエラー・イベントとして分類されます。

# evmpost -p 400 -a  \
"Users reporting possible network problems"

省略時の設定では,root ユーザか adm グループのメンバだけが,-a オプションでイベントをポストできます。 ただし,認証ファイル /etc/evm.auth13.2.3.2 項の説明のように編集すると,他の特権ユーザも利用できるようになります。 どのユーザも,-u オプションを使用して同じ方法でメッセージをポストできます。 必要であれば,認証ファイルを編集して,信頼できるユーザだけにこの特権を制限することができます。

13.3.8    登録済みのイベントのリスト表示

テンプレート・ファイル・エントリを追加し (13.2.5 項を参照),-d オプションを指定して evmreload コマンドを実行し Event Manager デーモンにエントリを認識させるか,システムを再起動して,イベントを登録します。

登録したイベントのリストを取り出すには,evmwatch -i コマンドを使用できます。 evmwatch -i コマンドの出力を evmshow コマンドにパイプし,イベント・テンプレートを好みのフォーマットで表示します。 たとえば,次のコマンドを入力します。

# evmwatch -i | evmshow -t "@name [@priority] @format" -x

テンプレートは,ファイルにリダイレクトすることも,evmshow コマンドにパイプして表示することもできる,バイナリ形式の Event Manager イベントとして返されます。 上記の例では,表示テンプレート (-t オプション) の内容に従って,イベントの名前,優先順位,およびメッセージ・フォーマットが表示されます。 -x オプションにより,各要約行の後にイベントの説明が表示されます。

表示しているのはテンプレートであり実際のシステム・イベントではないため,展開されたメッセージではなく,イベントのメッセージ・フォーマットを要求するコマンド・シーケンスを指定します。 この出力では,要約行には変数の値ではなく変数の名前で,メッセージが表示されます。 たとえば,次のような要約行と説明テキストが表示されます。

sys.unix.fs.advfs.fdmn.bal.error [400] AdvFS: Balance error on AdvFS domain $domain
  This event is posted by the balance(8) command to indicate that an
  error has occurred while balancing the domain.
 
  Action: Please see balance(8) for further information.
 
 

この例では,$domain 変数は,ポストされたイベントのインスタンスを evmget コマンドを使用して取り出す際にドメイン名に置き換えられています。

登録済みイベントを全部は表示したくない場合,フィルタを使用して evmwatch コマンドの出力を,表示したいイベントだけに限定することができます。

# evmwatch -i -f '[name *.evm]' | evmshow -t "@name \
[@priority] @format" -x 

13.3.9    シェル・スクリプトからのイベントのポスト

新しく登録したイベントを,イベント情報をソース (テキスト) 形式でコマンドに渡してポストするには,evmpost コマンドを使用します。 イベントの構文についての詳細は, evmpost(1) のリファレンス・ページを参照してください。 ソース・レベルでのポスト機能は,イベントで操作の成功または失敗を示すことがあるルーチン操作を実行するシェル・スクリプトで,最も役に立ちます。 この項では,バックアップの終了を通知する新しいイベントを作成し,ポストする手順について説明します。 基本的なステップは,次のとおりです。

  1. テンプレート・ファイルを作成し,その構文を確認します。

  2. テンプレート・ファイルをインストールし,Event Manager デーモンに知らせます。

  3. 認証ファイルをアップデートし,イベントをポストできるようにします。

  4. イベントをポストするシェル・スクリプト・コマンドを作成します。

イベントの設計ガイドラインについては,『プログラミング・ガイド』を参照してください。 この本に説明されている概念を理解してから,新しいイベントの設計を開始してください。 この例では,パックアップ・スクリプトは 2 つのイベント (優先順位 200 (通知) の local.admin.backup.ok と,優先順位 400 (エラー) の local.admin.backup.failed) のうちの 1 つをポストします。 失敗したイベントには,バックアップ・プログラムから返された終了コードを保持する result_code という変数が入っています。 この変数は 8 ビットの符号なし整数で,テンプレート内ではダミー値 0 が入っています。 このダミー値は,イベントのポスト時に実際の値に置き換えられます。 テンプレート・ファイルの構文については, evmtemplate(4) のリファレンス・ページを参照してください。

次の手順は,新しいイベントを作成してポストする方法を示します。

  1. /var/evm/adm/templates/local ディレクトリが存在しない場合は,作成します。

  2. vi などのテキスト・エディタを使用して,次のテキスト・ファイルを作成します。

    # This file contains EVM event templates for local
    # backup notification events.
    event {
      name local.admin.backup.ok
      format "BACKUP: Backup completed OK"
      priority 200
    }
     
    event {
      name local.admin.backup.failed
      format "BACKUP: Backup failed - code $result_code"
      var {name result_code type UINT8 value 0}
      priority 400
    }
    

  3. このファイルを backup.evt という名前で,/var/evm/adm/templates/local ディレクトリに保存します。

    /var/evm/adm/templates ディレクトリ下のディレクトリであれば,どこにでも新しいテンプレート・ファイルをインストールできます。 ただし,サブディレクトリおよびテンプレート・ファイルの名前は識別しやすいように,イベントの名前に由来する名前にしてください。 密接に関連する少数のイベント・テンプレートを 1 つのテンプレート・ファイルに保持すると,管理が簡単になります。

  4. テンプレートの構文を確認します。 テンプレート・ファイルの構文はイベントをポストするときに使用する構文と同じなので,evmpost -r コマンドを使用して構文を確認できます。 -r オプションは,イベントのポストではなく,構文の確認であることを evmpost コマンドに指示し,入力をバイナリの Event Manager イベントに変換してから,Event Manager イベントを自分の標準出力 (stdout) ストリームに書き込みます。 テンプレート項目のイベントへのマージを回避するか,タイムスタンプやホスト名などの環境項目を追加するには,evmpost -M コマンド・オプションを使用します。

    どのバイナリ Event Manager イベントのストリームの場合も,evmshow コマンドを使用して,evmpost コマンドの出力を確認できます。 この処理を行うには,次のコマンドを入力します。

    # cat /var/evm/adm/templates/local/backup.evt |
     evmpost -r -M | evmshow -t "@priority @@"
    

    ファイルが正しく作成された場合,次の出力が表示されます。

    200 BACKUP: Backup completed OK
    400 BACKUP: Backup failed - code 0
    

  5. ファイルの所有者が root または bin で,パーミッションが 040006000440,または 0640 であることを確認します。 必要であれば,chown コマンドおよび chmod コマンドを使用して,パーミッションを修正します。

  6. 次のコマンドを実行して,Event Manager デーモンに構成を再ロードさせます。

    # evmreload -d
    

    コマンドがエラー・メッセージを表示した場合は,問題を解決して,コマンドを再入力します。 最も考えられる原因は,ファイルの所有者やパーミッションの誤りです。

  7. Event Manager デーモンのデータベースからテンプレートを取り出す evmwatch -i コマンド・オプションを使用して,テンプレートの登録を確認します。 evmwatch コマンドはテンプレートをバイナリ Event Manager イベントの形式で出力します。 テンプレートを表示するには evmshow コマンドを使用します。 正しく登録されていることを確認するのに必要なのは,次の例のように,イベントの名前の表示だけです。

    # evmwatch -i -f "[name local.admin.backup]" |
     evmshow -t "@name"
    local.admin.backup.ok
    local.admin.backup.failed
    

  8. 認証ファイル /etc/evm.auth をアップデートし,イベントがポストされるようにします。 次の行を追加して,root ユーザだけがこのイベントをポストし,すべてのユーザがこのイベントを参照できるようにします。

    # Local backup events:
    event_rights {
       class        local.admin.backup
       post         root
       access       +
    }
    

    名前の最初の 3 コンポーネントだけが指定されています。 これらのコンポーネントは新しい 2 つのイベントに共通なので,どちらのイベントがポストされても,その名前とこのエントリが一致します。

  9. evmreload -d コマンド・オプションを実行して,デーモンがこの新しい認証エントリを認識するようにします。

  10. 次のコマンドを使用して,イベントのログが正しく取得されていることを確認します。

    # echo 'event {name local.admin.backup.ok}' | evmpost
    # echo 'event {name local.admin.backup.failed}' | evmpost
    # evmget -f '[name local.admin.backup]' |
     evmshow -t '@timestamp [@priority]  @@'
     
    28-Jun-2002 15:21:39 [200]  BACKUP: Backup completed OK
    28-Jun-2002 15:21:40 [400]  BACKUP: Backup failed - code 0
    

    上記の例では,evmpost コマンドが標準入力 (stdin) ストリームからソース入力を読み取り,入力を Event Manager イベントに変換して,そのイベントをポストしています。 最後のコマンドの出力は,ポストされたイベントを表示します。 この出力には,テンプレート・ファイルに指定された優先順位が含まれています。 これは,各イベントがポストされる際に,Event Manager デーモンがテンプレート情報を各イベントとマージするためです。 2 番目のイベントのコードの値はゼロです。 これはテンプレート・ファイルに設定されたダミー値であり,ポストされたイベント内でその値が置き換えられなかったためです。 バックアップ・スクリプトでは,この値にゼロ以外の値を設定します。

  11. 次の例のように,ポスト・コマンドをバックアップ・スクリプトに追加します。

    #! /bin/sh
    # This shell script runs the backup operation
    # and posts an event to indicate success
    #or failure.
     
    do_backups  # Performs the backup operation
    if [ $? -eq 0 ]
    then
     # success
     echo 'event {name local.admin.backup.ok}'| evmpost
    else
     # failure
     RES=$?
     evmpost << END
     event {
       name local.admin.backup.failed
        var { name result_code type UINT8 value $RES }
        }
    END
    fi
     
     
    

    上記の例で,成功したイベントの evmpost コマンドへの入力は簡単なので,echo コマンドを使用して同じ行で指定しています。 失敗したイベントの場合,result_code 変数の値も渡さなければなりません。 この値を渡すには,シェルの << 構文を使用して,より構造化された複数行フォームの入力を使用します。 どちらの入力フォームも,標準入力 (stdin) ストリームを通して,evmget コマンドにソース・コード入力を渡します。

コマンド行またはシェル・スクリプトからのイベントのポストについての詳細は, evmpost(1) を参照してください。

13.3.10    Event Manager のマーク・イベントについて

イベント動作の表示や監視を行うと,次のイベントが 15 分ごとに発生していることが分かります。

26-Jun-2000 08:57:45 [200] EVM: Mark event
 

evmlog イベント・チャネルでは,このイベントをポストして,定期的にイベント動作が発生するようにします。 システムに問題が発生し,最後に動作していたのがいつかを調べる必要がある場合,次のコマンドでシステム・ログ内のマーク・イベントを探すことで確認できます。

# evmget -f "[name *.evm.mark]" | evmshow -t "@timestamp @last_timestamp  @@"
26-Jun-2000 00:57:35 26-Jun-2000 04:42:40  [16 times] EVM: Mark event
26-Jun-2000 04:57:41 -  EVM: Mark event
26-Jun-2000 05:12:41 -  EVM: Mark event
26-Jun-2000 05:27:41 -  EVM: Mark event
26-Jun-2000 05:42:41 26-Jun-2000 09:12:45  [15 times] EVM: Mark event

省略時のロガー構成ファイルを使用している場合は通常,個別のマーク・イベントが 3 個と,その後に [n times] (n は数で,最大 16) が前に付いたイベント 1 個が表示されます。 これは,最大 4 時間の間の複数のイベントを結合して無駄なスペースを最小限にする,ロガーの抑制機能の結果です。 通常のタイムスタンプ値は,結合されたイベントのうち最初のイベントの発生を示します。 last_timestamp データ項目は,最後のイベントの発生時刻を示します。 この例では,09:12:45 にポストされた最後のマーク・イベントを表示する表示テンプレート内に,last_timestamp データ項目があります。 このマーク・イベントは,この時刻にシステムが動作していたことを示しています。

マーク・イベントのポストを無効にするには,チャネル構成ファイルを編集して,次のいずれかの変更を行います。

チャネル構成ファイルについての詳細は,13.2.2.2 項 と, evmchannel(4) を参照してください。 イベントの抑制についての詳細は,13.2.2.3 項 と, evmlogger.conf(4) を参照してください。

13.3.11    SysMan イベント・ビューアを使用した,イベントの表示

SysMan のグラフィカル・イベント・ビューアには,システム・イベント・ログへの簡単で便利なインタフェースが用意されています。 イベント・ビューアは SysMan システム管理群の不可欠な部分であり,X ウィンドウ・ディスプレイや,PC アプリケーションなどの文字セル端末,Web ブラウザなど,さまざまなグラフィカル環境で使用できます。 ビューアを SysMan Station から起動することもできます。 SysMan の使用については,第 1 章を参照してください。

イベント・ビューアをコマンド行から起動するには,sysman コマンドを入力してから,[モニタリング/チューニング] メニュー項目をオープンします。 [イベントの参照] オプションを選択して,イベント・ビューアを起動します。 CDE からイベント・ビューアを直接起動するには,CDE のフロント・パネルのツール・ドロワをオープンし,「システム管理」,「日常管理」,「イベント・ビューア」の順で選択します。

イベント・ビューアを初めて実行すると,イベントがフィルタリングされて優先順位が高いイベントだけが表示されるという警告メッセージが示されることがあります。 システムが正常に動作している場合,イベント要約ウィンドウには何もイベントが表示されないのが普通です。 表示するイベントを選択するには,ウィンドウの下部にある [フィルタ...] を選択し,「フィルタ」ウィンドウ内のフィルタ基準を変更します。 格納されているすべてのイベントを表示する場合は,ウィンドウの左側のチェックボックスがすべてチェックされていないことを確認してから,[了解] を選択します。 システムのイベント動作が高レベルの場合,「プライオリティ」ボックスをチェックして優先順位の範囲を調整すると,表示されるイベントの数を減らし,イベントの表示にかかる時間を短くすることができます。 この範囲に 400 〜 700 を設定すると,優先順位が error 以上のすべてのイベントが表示されます。 範囲の下限に 300 を設定すると,警告イベントも表示されます。

「フィルタ」ウィンドウの左側のボタンをクリックすると,表示フィルタの基準を追加することができます。 変更を行うたびに,[適用] を選択してイベント・リストに変更を適用するか,[了解] を選択して変更を適用してからメインのビューア・ウィンドウに戻らなければなりません。

「フィルタ」ダイアログ・ウィンドウでは,イベント・フィルタ文字列を入力することなく,直感的で便利な方法でフィルタを作成できます。 フィルタ文字列の構文に習熟していて,フィルタの高度な機能を利用したい場合は,メインのイベント・ウィンドウの下部にある [追加オプション...] を選択してアクセスする,「アドバンスド・フィルタ」ダイアログ・ボックスでフィルタ文字列を入力することができます。 フィルタ文字列を保存して,後で再使用することもできます。 フィルタ構文についての詳細は, EvmFilter(5) のリファレンス・ページを参照してください。

ビューアの最も重要な機能の 1 つは,任意のイベントの詳細表示を簡単に行えることです。 要約ウィンドウ内にあるイベントを選択し,[詳細...] を選択するだけで,説明テキスト,DECevent や Compaq Analyze からの変換 (binlog イベントの場合) など,すべての情報が表示されます。 メイン・ウィンドウに戻らなくても,「イベントの詳細」ウィンドウでイベント・リストをブラウズできます。

[カスタマイズ...] および [追加オプション...] を選択すると,イベントのソースなどの,ビューアの表示を変更できます。 イベントが表示される順序を変更するには,[ソート...] を選択します。 ビューアとその機能についての詳細を表示するには,任意のウィンドウで [ヘルプ...] を選択します。

注意

イベント・ビューアは,イベントの発生をリアル・タイムに監視するわけではありません。 アップデートされたイベント・リストを表示するには,メイン・ウィンドウの [Refresh] を選択します。

これらのアプリケーションの使用方法の詳細は, sysman(8) および evmviewer(8) を参照してください。 ビューアのオプションの使用方法については,イベント・ビューアのオンライン・ヘルプを参照してください。

13.3.12    高度な選択とフィルタリング技法

以降の項では,追加のフィルタリング技法をいくつか示しています。 この技法を使ってイベント選択方法を改善すると,必要なイベントだけを受け取ることができます。

13.3.12.1    時刻によるフィルタリング

timestamp キーワード,before キーワード,since キーワード,および age キーワードを使用すると,イベントがポストされた時刻でイベントをフィルタリングすることができます。 これらのキーワードのうち,age キーワードが一番簡単に使用でき,毎日の操作で一番便利です。

timestamp キーワードを使用する場合は,次の形式で,時刻の範囲を定義する文字列を指定しなければなりません。

year:month-of-year:day-of-month:day-of-week:hours:minutes:seconds

任意のコンポーネントに対し,アスタリスク (*) をワイルドカード文字として使用できます。 このため,2002 年 7 月 6 日に発生したイベントを選択するには,次のコマンドを使用します。

# export EVM_SHOW_TEMPLATE="@timestamp [@priority] @@"
# evmget -A -f '[timestamp 2002:7:6:*:*:*:*]' | more

最後の 4 つのコンポーネント内のアスタリスク (*) は,時刻に関係なく,この日に発生したすべてのイベントが必要であることを示します。 また,次のコマンドのように,任意の位置に 1 つ以上の範囲を指定することもできます。

# evmget -A -f '[timestamp 2002:*:*:1-3,5:*:*:*]' | more

4 番目のコンポーネントは,曜日を指定します。 ポスト時刻の範囲が 1 〜 3 または 5 のイベントを検索すると,2002 年の月曜日,火曜日,水曜日,または金曜日にポストされたすべてのイベントが取り出されます。

before キーワードと since キーワードでは同様の指定子文字列を使用しますが,ワイルドカード文字は使用できず,曜日を示すコンポーネントはありません。 たとえば,次のコマンドは 2002 年 7 月 6 日の午後 3 時以降にポストされたイベントを見つけます。

# evmget -A -f '[since 2002:7:6:15:0:0]' | more

age キーワードを使用すると,タイムスタンプに従い,便利で直感的な方法でイベントを選択できます。 システム管理者としては,システムの問題を示す最近のイベントが最も重要です。 このようなイベントを見つけるには,イベント・フィルタの priority キーワードと age キーワードを組み合わせます。 たとえば,次のコマンド・シーケンスは,優先順位がエラー (400) 以上で,昨日か今日発生した (イベントの経過時間が 2 日未満) すべてのイベントを表示します。

# evmget -A -f '[pri >= 400] and [age < 2d]' | more

上記の例では,2d で経過時間 (age) が 2 日未満のイベントを指定しています。 age は,秒 (s),分 (m),時 (h),日 (d),または週 (w) で指定できます。 各指定子がどのように使用されてイベントの経過時間 (age) が算出されるかについては, EvmFilter(5) を参照してください。

より複雑なフィルタを使用すると,より限定された期間に発生したイベントを返すことができます。 次の例は,3 日以上,6 日未満前に発生したエラー・イベントを見つけます。

# evmget -A -f '[pri >= 400] and ([age < 6d] and [age > 3d])' | more

タイムスタンプによるイベントの選択と,全フィルタ構文については, EvmFilter(5) を参照してください。

13.3.12.2    詳細表示のイベントを選択する event-id の使用

evmshow -d コマンド・オプションを使用してイベントを表示すると,出力が大量になることがあります。 このような場合は,表示されるイベントの数を制限できます。 Event Manager を使ってポストされるイベントには,event-id という一連の識別子が含まれています。 event-id を使い,詳細を表示する特定のイベントまたはイベントの範囲を選択することができます。

event-id は,デーモンが再起動されるたびにカウンターにゼロが設定されるため,特定のイベントのセット内で一意であるとは限りません。 イベントを確実に一意にするには,次の例に示すようにイベントの選択時にタイムスタンプも使用する必要があります。

# evmget -A -f '[age < 1d]' -t "@timestamp @event_id @@" | more

15-Apr-1999 14:19:06 0  EVM daemon: Configuration completed
15-Apr-1999 14:19:06 1  EVM daemon: Initialization completed
15-Apr-1999 14:19:06 2  EVM logger: Logger started
15-Apr-1999 14:19:06 3  EVM: Mark event - initial
15-Apr-1999 14:19:06 5  EVM logger: Started eventlog /var/evm/evmlog/evmlog.19990415
[1]               [2]
.
.
.
 
 

  1. この age フィルタ・キーワードは,今日発生したイベントすべてを選択します。 今日発生したかどうかは,データの 1 番目の欄にあるタイムスタンプで示されています。 [例に戻る]

  2. 表示テンプレート内の @event_id 指定子は,取り出された各イベントの event-id を表示するように,evmshow コマンドに指示します。 この id は,データの 2 番目の欄に示されています。 [例に戻る]

event-ids が表示されると,必要なイベントを選択することができます。 たとえば次のコマンドを使い,開始マークのイベントの詳細を表示します。 前述の例の出力では,3 という event-id があります。

# evmget -f '[age < 1d] and [event_id = 3]' | evmshow -d | more
 

次の例で示すように,さらに複雑なフィルタを使ってイベントの範囲を選択することができます。

# evmget -f '[age < 1d] and [event_id >= 1] and [event_id <= 3]'|
 evmshow -d | more

正しいイベントのセットを選択するために,時間範囲を注意深く選択する必要があります。 システムをリブートしたばかりの場合,最近 2 時間以内に発生したイベントだけを選択するには,[age < 2h] を指定します。

詳細表示するイベントを選択する一番簡単な方法は,13.3.11 項で説明しているイベント・ビューアを使うことです。

13.3.12.3    予約済みのコンポーネント名の検索

一部のイベント名は,名前拡張子として予約済みのコンポーネント名を含みます。 このようなコンポーネントは下線文字 (_) で始まり,通常,イベントがポストされる原因となった項目を識別するコンポーネントが続きます。 たとえば,多くのハードウェア関連のイベントの名前には,_hwid というコンポーネントが含まれ,その後にその項目の数値ハードウェア識別子が続きます。 予約済みのコンポーネント名は,イベント名に対する拡張として自動的に追加されます。この名前が追加されると,その後ろには変数が追加されます。 これは各予約済みのコンポーネント名ごとに行われます。 たとえば, @SYS_VP@.temperature_high という名前のイベントで変数 _degrees が 212 の場合,@SYS_VP@.temperature_high._degrees.212 という名前のイベントとして出力されます。

次のコマンドを使用して,このようなイベントをすべて検索することができます。

# evmget -A -f '[name *._hwid]' | more

特定のデバイスのハードウェア識別子が分かっている場合,次のようなコマンドを使用して,検索の範囲をそのデバイスに関連するイベントに絞ることができます。

# evmget -A -f '[name *._hwid.4]' | more

13.3.12.4    フィルタ・ファイルの使用

役に立つフィルタをファイルに保存して,Event Manager の間接フィルタ機能を使用して呼び出すことができます。 フィルタ・ファイルは,名前に .evf というサフィックスが付いていて,任意の数の名前付きフィルタを含めることができます。 たとえば,次のフィルタ・ファイル・エントリは,SCSI デバイスを参照するすべての binlog イベントを選択します。

filter {
    name "scsi"
    value "[name @SYS_VP@.binlog.hw.scsi]"
    title "Binlog SCSI events"
}

この例の @SYS_VP@ は,フィルタの使用時に sys.unix に置き換えられる,標準の Event Manager マクロです。

間接フィルタを使用するには,次の例のように,アットマーク (@) の後に,フィルタが格納されたファイルの名前をフィルタ文字列の代わりに指定します。

# evmget -A -f @binlog

このようなコマンドでフィルタ・ファイル名を指定する場合は,.evf サフィックスを省略できます。

上記の例では,ファイル内の最初のフィルタが使用されますが,次のように名前を指定して別のフィルタを選択することもできます。

# evmget -A -f @binlog:scsi

1 つのファイルに必要な数だけフィルタを入れることも,各フィルタを別々のファイルに入れることもできます。 上記の例は,Event Manager に含まれている binlog フィルタを指定しています。 他のフィルタは,/usr/share/evm/filters ディレクトリ内にあります。 これらのファイルを例として使用し,独自のフィルタ・ライブラリを作成してください。

evmshow -F コマンド・オプションを使用すると,格納されているフィルタの内容を簡単に参照できます。 -F オプションを使用すると,evmshow コマンドはフィルタ文字列を表示し,イベントを読み込まずに終了します。 次の例では,evmshow コマンドは binlog.evf ファイルに格納されている scsi という名前のフィルタの内容を表示します。

# evmshow -f @binlog:scsi -F
( [name sys.unix.binlog.hw.scsi] )

フィルタ・ファイルの構文の完全な情報と,ファイルを置く位置については, evmfilterfile(4) を参照してください。

注意

/usr/share/evm/filters ディレクトリ内のフィルタ・ファイルは編集しないでください。 変更を行っても,将来のアップデート・インストレーション時に,警告なしに上書きされてしまいます。

13.3.13    イベントのロギングと転送

イベントへの応答は,サイト固有の要件や環境によって決まる任意のアクションです。 この応答は,アラームを起動したり責任者を呼び出すものから,ログ・エントリを作成するものや,通常のアクティビティで予想できる現象を無視するものまであります。

あるタスクのイベント出力を次のプロセスの起動のトリガとして使用して,一連の依存関係のあるタスクを実行するようなイベント処理シーケンスを構成することもできます。 Event Manager では,ロギング機能を用いて,応答アクティビティとインタフェースをとることができます。 利用可能なオプションには,イベントの保存とイベント転送があります。

Event Manager ロガー evmlogger は,Event Manager デーモンによって自動的に起動され,次のような役割をします。

ロガーは,省略時は,ローカル・デーモンからポストされたイベントを処理しますが,リモート・システムからポストされたイベントを処理するように構成することも可能です。 詳細は,13.2.3.3 項を参照してください。

ロガーは,構成ファイルによって制御される,通常の Event Manager クライアントです。 省略時の構成ファイルは /etc/evmlogger.conf ファイルであり,13.2.2.3 項で説明しています。 このファイルの詳細は evmlogger.conf(4) を, このコマンドについての詳細は evmlogger(8) を参照してください。

13.3.13.1    イベントのロギング

構成ファイル内の eventlog グループの仕様に一致するすべてのイベントは,イベント・ログに記録されます。 このファイルの省略時の位置と命名規則については,13.1.3.3 項を参照してください。

例 13-3 で示したように,構成ファイルの eventlog 文に suppress グループの仕様を含めることができます。 この文があると,抑制の基準に一致するイベントはログに記録されなくなります。 イベントの最初のインスタンスだけが記録され,後はそのイベントの数と最初と最後の出現時刻のデータだけが記録されます。 この基準についての説明は, evmlogger.conf(4) を参照してください。

13.3.13.2    転送を使用したイベントの自動処理

選択したイベントを自動的に処理したい場合,Event Manager ロガーを構成して,コマンドの実行によってイベントを転送することができます。 たとえば,イベント情報をポケットベル・サービスにメールしたり,またはイベント処理アプリケーション・プログラムを呼び出すことができます。

省略時の設定では,ロガーは高優先順位のイベントを root ユーザにメールで送るように構成されています。 この省略時の転送コマンドを例として使って,独自のアクションを記述することができます。 詳細は,13.2.2.3 項evmlogger.conf(4) を参照してください。

構成ファイル内の forward 文の指定に一致するイベントはすべて,この文で指定されたコマンドの標準入力 (stdin) に書き込まれます。 コマンドは,シェル・スクリプトの名前,1 つの UNIX コマンド,一連の UNIX コマンド (パイプライン),またはその他の実行可能文です。 一般的な転送アクションとしては,次の操作があります。

イベントを転送するようにロガーを構成する場合,次の点に注意してください。

転送プログラムやその他の構成項目を追加するには,13.2.2.4 項で示すように,ロガーの 2 次構成ファイル機能を使用します。

13.3.13.3    リモート・システムからのイベントのロギング

省略時の設定では,ロガーはローカル・デーモンからポストされるイベントだけをサブスクライブします。 構成ファイルに 1 つ以上の remote_hosts セクションを追加することで,他のシステム上でポストされたイベントをロガーがログをとるか転送するように構成できます。 最善の方法は,2 次構成ファイルにリモート接続を指定することです。 2 次構成ファイルの詳細は,13.2.2.4 項を参照してください。

ロガーは,接続が確立,切断,あるいは再確立するたびにイベントをポストすることで,リモート接続のステータスをレポートします。

例 13-6 に,remote_hosts セクションの例を示します。 完全な構文は, evmlogger.conf(4) を参照してください。

例 13-6:  リモート・ロギングを行うためのロガー構成ファイルのエントリの例

remote_hosts {                         
        name            appsys_hosts                  [1]
        hostnames       appsys1,appsys2              
        hostnames       appsys3                       [2]
        targets         appsys_log                    [3]
        filter          "[priority >= 400]"           [4]
        retry           10                            [5]
    }
 
    eventlog {                                        [6]
        name            appsys_log
        logfile         /eventlogs/applog.dated
        explicit_target yes                           [7]
        filter          all                           [8]
    }

  1. name キーワードでこのグループを識別します。 [例に戻る]

  2. hostnames 行にはロガーがサブスクライブするリモート・ホストのリストを指定します。 このリストは複数行にわたって指定することができ,また各行に複数のホストを含めることもできます。 [例に戻る]

  3. targets 行は,このグループにリストされたリモート・ノードから受信するイベントが,eventlog グループ appsys_log で定義されるイベント・ログに記録されることを示しています。 ターゲットは,イベント・ログまたはフォワーダのいずれかです。 [例に戻る]

  4. filter 行は,任意のリモート・システムでポストされた,優先度が 400 以上のすべてのイベントのログがとられることを示しています。 [例に戻る]

  5. retry 行は,任意のリモート・ホストへの接続が確立できないか切断された場合に,ロガーが 10 秒ごとに再接続を試みることを示しています。 [例に戻る]

  6. これが,サンプルの remote_hosts セクションのターゲットになる eventlog グループです。 [例に戻る]

  7. explicit_target キーワードに yes (または true) を設定すると,この eventlog グループが,target 行で名前を指定した remote_hosts グループを通じて受信したイベントのログだけを記録するようになります。 ローカル・デーモンから受信したイベントは,このグループでは扱われません。 [例に戻る]

  8. ログのフィルタに all を設定すると,リモート・ホストから受信したすべてのイベントのログが記録されます。 remote_hosts グループで指定したフィルタ文字列によって,受信するイベントの集合が決まります。 [例に戻る]

構成を変更した場合,ロガーにその変更を認識させるために,evmreload -l コマンドを実行してください。

TruCluster 環境で remote_hosts セクションを指定した場合には,各種のクラスタ・ノードで実行されている個々のロガーが,同じセットのリモート接続を確立し,クラスタの各ノードで独立してイベントのログをとります。 この動作を変更するには,mkcdsl コマンドを使用して,2 次構成ファイルのメンバ固有のバージョンを作成してください。 CDSL (コンテキスト依存シンボリック・リンク) の詳細は, mkcdsl(8) を参照してください。

13.4    Event Manager のトラブルシューティング

Event Manager が正常に動作していない疑いがある場合,まず最初に /var/evm/adm/logfiles ディレクトリ内のメッセージ・ファイルを調べます。 このファイルのメッセージはまた,Event Manager ビューアと evmget でも,misclog イベント・チャネルの一部として表示されます。

次のリストでは,典型的な問題と,その解決のために最初に行うべきステップを示します。