|
≫ |
|
|
|
この章では,システム・ログ・ファイルの設定と管理,エラー・ログ・ファイルの管理,およびシステム管理ユーティリティを使ったシステムの監視について説明します。
この章では,次の作業を説明します。
さらに,次の項目について説明します。
システム管理を行う場合,システム・イベントに関する情報を収集して検討することが必要になります。
OpenVMS オペレーティング・システムでは,システム資源の使用状況,エラー状態,他のシステム・イベントの情報を記録するログ・ファイルがいくつか提供されます。
これらのログ・ファイルについて 表 6-1 「システム・ログ・ファイル」 で簡単にまとめます。
エラー・ログ・サブシステムは,自動的にエラー・メッセージを最新バージョンのエラー・ログ・ファイル SYS$ERRORLOG:ERRLOG.SYS に書き込みます。
エラー・ログ・レポートは,主に,弊社のサポート担当者がハードウェアの問題箇所を特定するときに使用するものです。
また,システム管理者でも,あるシステム障害が頻繁に発生する場合には,それが注意を要するものであるかどうか,エラー・ログ・レポートから判断することができます。
エラー・ログ・サブシステムについて
エラー・ログ・サブシステムは,表 6-2 「エラー・ログ・サブシステムの構成要素」 に示す 3 つの部分から構成されます。
表 6-2 エラー・ログ・サブシステムの構成要素 構成要素 | 説明 |
---|
エグゼクティブ・ルーチン | エラーおよびイベントを検出し,関連する情報をメモリ内のエラー・ログ・バッファに書き込む。 |
エラー・フォーマッタ (ERRFMT)
| ERRFMT プロセス は,システムのブート時に起動し,定期的にエラー・ログ・バッファを空にするとともに,エラーの記述を標準形式に変形し,書式化した情報をシステム・ディスク上のエラー・ログ・ファイルに格納する (6.3.2 項 「エラー・ログ・ファイルの管理」を参照)。 エラー・フォーマッタを使えば,ERRFMT プロセスが回復不可能なエラーに遭遇してプロセス自身を削除する場合に,SYSTEM アカウントや他のユーザにメールを送ることができる
(6.3.3 項 「ERRFMT によるメールの送信」を参照)。 |
Error Log Viewer (ELV) | エラー・ログ・ファイルの内容を選択して報告する。
このユーティリティは,バージョン 7.3 およびそれ以降の OpenVMS を実行しているシステム上で書き込まれたエラー・ログの場合に最も便利である。 ELV を呼び出すには,DCL の ANALYZE/ERROR_LOG/ELV コマンドを入力する (6.4 項 「Error Log Viewer (ELV) の使用方法」を参照)。 |
エグゼクティブ・ルーチンとエラー・フォーマッタ (ERRFMT) プロセスは継続的に稼働します。
途中,ユーザと対話することはありません。
エグゼクティブ・ルーチンは,エラーやイベントを検出すると,そのままの形でメモリ上のエラー・ログ・バッファに格納します。
エラー・ログ・バッファの 1 つがいっぱいになるか,またはあらかじめ設定された時間が経過すると,ERRFMT は自動的にエラー・ログ・バッファを SYS$ERRORLOG:ERRLOG.SYS に書き込みます。
しかし,エラーが瞬時に大量に発生し,ERRFMT プロセスがエラー・ログ・バッファを空にする前に,エラー・ログ・バッファがあふれてしまうこともあります。
この状態を発見するためには,エラー・ログ・レポートを読んで,レコード番号の途中に抜けた箇所がないかどうか調べます。
ERRFMT プロセスがエラー・ログ・バッファ空間を解放すると,ただちに,エラー・ログは再開されます。
エラーが多すぎてエラー・ログ・ファイルに書き込めなくなると,ERRFMT プロセスは,システム・コンソール・ターミナルにエラー・メッセージを表示し,自分で実行を停止します。
ERRFMT プロセスを再開する方法については,6.3.1 項 「ERRFMT プロセスの再起動」を参照してください。
エラー・ログ・フォーマッタ(ERRFMT)プロセスは,ブート時に自動的に起動されます。
次に各作業の実行方法と参照箇所を示します。
6.3.1 ERRFMT プロセスの再起動 | |
ERRFMT プロセスを再起動するためには,次の手順に従ってください。
-
システム管理者のアカウントでログインする。
これは,操作に必要な特権を獲得するためである。
-
コマンド・パラメータとして ERRFMT を指定し,サイト別スタートアップ・コマンド・プロシージャ (STARTUP.COM) を実行する。
$ @SYS$SYSTEM:STARTUP ERRFMT
|
6.3.2 エラー・ログ・ファイルの管理 | |
エラー・ログ・ファイル SYS$ERRORLOG:ERRLOG.SYS は共用ファイルのため,ANALYZE/ERROR_LOG ユーティリティがそのファイルの既存のエラー・ログ・エントリを読み込んだり抽出したりしている間にも,ERRFMT プロセスは新しいエントリを書き込みます。
ERRLOG.SYS は,システム管理者が明示的にリネームするか削除するまで大きくなっていきます。
したがって,エラー・ログ・ファイルは定期的に整理する必要があります。
1 つの方法として,1 日 1 回 ERRLOG.SYS をリネームします。
そうすると,新しいエラー・ログ・ファイルが自動的に作成されます。
たとえば,毎朝 9 時に ERRLOG.SYS を ERROLOG.OLD にリネームします。
リネームした古いエラー・ログ・ファイルは別のボリュームに移すか,システム・ディスクから削除すれば,システム・ディスクの空間が解放されます。
また,論理名 SYS$ERRORLOG をエラー・ログ・ファイルを格納したいデバイスとディレクトリに定義することにより,システム・ディスク以外のディスク上にエラー・ログ・ファイルを格納する方法もあります。
次に例を示します。
$ DEFINE/SYSTEM/EXECUTIVE SYS$ERRORLOG DUA2:[ERRORLOG]
|
システムを起動するたびにこの論理名を定義する場合は,論理名定義を SYLOGICALS.COM プロシージャに追加します。
詳細は『OpenVMS システム管理者マニュアル (上巻)』を参照してください。
このとき,誤って使用中のエラー・ログ・ファイルを削除しないように注意してください。
また,リネームするときに,ファイル名の先頭あるいは最後に日付を付けて整理する方法もあります。
6.3.3 ERRFMT によるメールの送信 | |
エラー・フォーマッタ (ERRFMT) を使用すれば,ERRFMT プロセスが回復不可能なエラーを検出し,プロセス自身を削除するときに,システム管理者や他の指定したユーザにメールを送ることができます。
2 つのシステム論理名 ERRFMT$_SEND_MAIL および ERRFMT$_SEND_TO が,この機能を制御します。
-
ERRFMT$_SEND_MAIL
メールの送信を可能にするには,文字列 TRUE (大文字と小文字の区別なし) を指定する。
他の値では,メールの送信はできない。
-
ERRFMT$_SEND_TO
ユーザ名を指定する (現在の省略時の値は SYSTEM)。
配布リストおよび複数のユーザ名はなるべく使用しないこと。
上記の論理名を定義するには,次のいずれかを行います。
-
DCL の DEFINE/SYSTEM コマンドを使用し,動的に定義する。
変更後,ERRFMT を停止し再起動しなければ,変更は有効にならない。
-
SYS$STARTUP:SYLOGICAL.COM を使用し,恒久的に定義する。
定義した論理名は,次回システムをリブートしたときから有効となる。
これ以降の説明では,この方法を使用する。
6.3.3.1 メールを送信するための ERRFMT の停止と再起動
ERRFMT$_SEND_MAIL が TRUE と定義されている場合,ユーザは,ERRFMT がプロセス自身を削除するという表題のメール・メッセージを受信します。
オペレータ・ログ・ファイルおよびシステム・コンソール OPA0: には,発生した障害についての詳細な情報,および ERRFMT を再起動するための指示が出力されます。
しかし,ユーザはコンソールにいないこともあるので,この情報を見ないかもしれません。
たとえば,メールの送信が可能なモードで ERRFMT を使用している場合,メールの送信を禁止にするには,システム管理者のアカウントを使って,SYS$STARTUP:SYLOGICAL.COM を編集し,次のコマンドを追加します。
$ DEFINE/SYSTEM ERRFMT$_SEND_MAIL FALSE
|
もう一度,メールの送信を可能にするには,システム管理者のアカウントを使って,SYS$STARTUP:SYLOGICAL.COM を編集し,次のコマンドを追加します。
$ DEFINE/SYSTEM ERRFMT$_SEND_MAIL TRUE
|
省略時の設定では,メールは SYSTEM アカウントに送信されます。
しかし,ERRFMT$_SEND_TO を定義すれば,ERRFMT が自分自身を削除するときに,メールを他のユーザに送信することもできます。
メールを受信するユーザ名を変更するには,システム管理者のアカウントを使って,SYS$STARTUP:SYLOGICAL.COM を編集し,適切な論理名を定義する DEFINE コマンドを追加します。
次に例を示します。
$ DEFINE/SYSTEM ERRFMT$_SEND_TO R_SMITH
|
配布リストおよび複数ユーザ名はなるべく使用しないでください。
Error Log Viewer (ELV) は,エラー・ログ・ファイルの内容を選択して報告します。
ELV は,OpenVMS バージョン 7.3 およびそれ以降を実行しているシステム上で書き込まれたエラー・ログで使用すると最も便利です。 ELV についての詳細は,『OpenVMS システム管理 ユーティリティ・リファレンス・マニュアル(上巻)』の ELV についての章を参照してください。
6.4.1 Error Log Viewer (ELV) について | |
Error Log Viewer (ELV) ユーティリティを使用すると,エラー・ログ・ファイルを,ユーザが読める形式で,コマンド行から素早く調べることができます。
この処理を実行することで,データに対し,System Event Analyzer (SEA) などのツールによるより分かりやすい分析が必要かどうかを判断できます。 ELV は,表 6-3 「ELV が完全にサポートするイベント・タイプ」 に示すイベント・タイプに属するすべてのイベントについて,詳細情報を出力します。
イベント・タイプは,同じ表に示すイベント・クラスでグループ分けされます。
表 6-3 ELV が完全にサポートするイベント・タイプ イベント・クラス | イベント・タイプ |
---|
制御エントリ | システム起動,タイム・スタンプ,オペレータおよびネットワークのメッセージ,通知イベント,ERRLOG.SYS が作成したメッセージ,および Send Message から Error Logger ($SNDERR) システム・サービスへのメッセージ | ボリューム変更 | ボリュームのマウントとディスマウント | バグチェック | システムのバグチェック,ユーザのバグチェック,およびクラッシュ再起動 | マシン・チェック | 訂正可能エラーの絞り込み通知,6A0/6B0 回復可能な訂正不能エラー |
デバイス・エラー | ソフトウェア・パラメータ |
ELV は,表 6-4 「ELV が部分的にサポートするイベント・タイプ」 に示すイベント・タイプに属する一部のイベントについて,詳細情報を出力します。
イベント・タイプは,同じ表に示すイベント・クラスでグループ分けされます。
表 6-4 ELV が部分的にサポートするイベント・タイプ イベント・クラス | イベント・タイプ |
---|
マシン・チェック | 620 システムの訂正可能エラー,630 プロセッサの訂正可能エラー,660 システムの訂正不能エラー,670 プロセッサの訂正不能エラー,680 システム・イベント,コンソール・データ・ログ |
デバイス・エラー | デバイス・エラー,デバイス・タイムアウト,非同期デバイス・アテンション |
非要求型 MSCP | ログに記録される MSCP メッセージ |
6.4.2 ELV の起動 | |
ELV を起動するには,次の DCL コマンドを入力します。 ELV コマンドを入力しないと,ユーティリティは会話型シェル・モードに入り,ELV プロンプトを表示します。 この後,ELV コマンドを入力できます。
ELV はコマンドを実行した後,再度 ELV> プロンプトを表示します。 ELV プロンプトから ELV コマンドを実行した後に DCL に直接戻るには,/NOINTERACTIVE 修飾子を使用します。 また,ELV コマンドを DCL から直接入力することもできます。
例を次に示します。
$ ANALYZE/ERROR_LOG/ELV TRANSLATE ERRLOG.SYS;42
|
特に指定しなければ,ELV はコマンドを実行した後,DCL プロンプトに戻ります。 DCL から直接 ELV コマンドを実行した後に会話型シェル・モードに入るには,/INTERACTIVE 修飾子を使用します。
6.4.3 主な ELV コマンド | |
表 6-5 「主な ELV コマンド」 に,主な ELV 操作のコマンドを示します。
表 6-5 主な ELV コマンド コマンド | 説明 |
---|
CONVERT | 新しい形式で書き込まれている 1 個以上のバイナリ・エラー・ログ・ファイルのイベントを,古い形式に変換して 1 個の新しいエラー・ログ・ファイルに書き込む。
新しいファイルは,ANALYZE/ERROR_LOG により読み込めるようになる。 このコマンドは,ELV が変換をサポートしていない古いエラー・ログ・イベントの変換を可能とするために主に使用される。 |
DUMP | 1 個以上のバイナリ・エラー・ログ・ファイルのイベントを,OpenVMS ダンプ・スタイル形式で 1 個の新しい ASCII 出力ファイルに書き込む。 |
TRANSLATE | 1 個以上のバイナリ・エラー・ログ・ファイルのイベントに対してバイナリからテキストへの変換を行い,結果として得られたレポートを,ターミナルまたは 1 個の新しい ASCII 出力ファイルに書き込む。 |
WRITE | 1 個以上のバイナリ・エラー・ログ・ファイルのイベントを,1 個の新しいバイナリ・エラー・ログ・ファイルにコピーする。 |
これらのすべてのコマンドに共通の修飾子を使用して,コマンドで処理されるイベントを選択または拒否することができます。
たとえば,TRANSLATE /SINCE=YESTERDAY を指定すると,昨日以降に発生した有効なイベントすべてが変換されます。
6.4.4 TRANSLATE コマンドを使用した標準レポート | |
TRANSLATE コマンドを使用すると,さまざまな詳細レベルで標準レポートを作成できます。
標準レポートの作成は,ELV ユーティリティの主要な機能です。 標準レポートの詳細レベルを指定するには,TRANSLATE コマンドに /BRIEF,/FULL,または /ONE_LINE 修飾子を指定します (概要は表 6-6 「標準レポートの詳細レベル」 を参照)。
または,詳細レベル修飾子を省略して,省略時のレポートを表示します。
これらの修飾子の他に,/TERSE 修飾子を使用すると,詳細レベルに関係なく,データの加工が少ない標準レポートを得ることができます。 表 6-6 標準レポートの詳細レベル 詳細レベル | 修飾子 | 説明 |
---|
1 行 | /ONE_LINE | ヘッダ情報だけを,標準レポートに含める。 |
簡潔 | /BRIEF | ヘッダ情報の他に,最も重要な情報だけを含める。 |
省略時の表示 | (なし) | ヘッダ情報の他に,一般的に役立つイベント情報だけを含める。 |
完全 | /FULL | ヘッダ情報の他に,すべてのイベント情報を含める。 |
例 6-1 「標準レポートと要約レポート」 に,標準レポートと要約レポートの例を,順に示します。
標準レポートだけを作成する (省略時の指定で含まれる要約レポートを作成しない) には,/NOSUMMARY 修飾子を使用します。
要約レポートだけを作成する (省略時の指定で含まれる標準レポートを作成しない) には,/SUMMARY 修飾子を使用します。 例 6-1 標準レポートと要約レポート
|
Output for SYS$COMMON:[SYSEXE.ERRLOGS]EXAMPLE.DAT;1
EVENT EVENT_TYPE___________________TIMESTAMP________________NODE__EVENT_CLASS_______________
1 Volume Mount 14-AUG-2003 13:31:39.12 FRANZ VOLUME_CHANGES
DESCRIPTION__________________________RANGE___ VALUE___________TRANSLATED_VALUE___________
Hardware Architecture 4 Alpha
Hardware System Type 35 Wildfire
Logging CPU 3
Number of CPU's in Active Set 4
System Marketing Model 1968 COMPAQ AlphaServer GS160
Error Mask <31:006gt;: 0x00000003
Seconds Since Boot 17
Error Sequence Number 46
DSR String AlphaServer GS160 6/731
Operating System Version X9WY-SSB
Owner UIC of the Volume 65537
Unit Operation Count 378
Device Unit Number 200
Device Generic Name FRANZ$DKB
Volume Number within Set 0
Number of Volumes within Set 0
Volume Label OPAL_X9WY
ERROR_LOG_SUMMARY________________________________________________
Total number of events: 1
Number of the first event: 1
Number of the last event: 1
Earliest event occurred: 14-AUG-2003 13:31:39.12
Latest event occurred: 14-AUG-2003 13:31:39.12
Number of events by event class:
VOLUME_CHANGES 1
|
|
この節では,オペレータ・ログ・ファイルと,このファイルに記録される OPCOM メッセージについて説明し,次の表の作業手順を示します。
これらの作業を行う場合は OPER 特権が必要になります。
6.5.1 オペレータ・ログ・ファイルについて | |
オペレータ・ログ・ファイル (SYS$MANAGER:OPERATOR.LOG) には,システム・イベントと,オペレータ通信マネージャ (OPCOM) からオペレータ・ターミナルに送信されたユーザ要求が記録されます。
記録は,すべてのオペレータ・ターミナルが使用不能になっている場合でも行われます。
通常,OPCOM はシステムをブートすると起動します。
OPCOM についての詳細は,『OpenVMS システム管理者マニュアル (上巻)』を参照してください。
オペレータ・ログ・ファイルにより,ハードウェアおよびソフトウェアの障害を予測してそれらを事前に防止したり,ディスクおよび磁気テープに対するユーザ要求を監視することもできます。
オペレータ・ログ・ファイルを定期的に調べれば,今後障害につながる可能性がある問題を事前に見つけ,適切な処置をとることができます。
OPERATOR.LOG ファイル (または論理名 OPC$LOGFILE_NAME が指すファイル) のサイズとアクセスは,それが置かれているディスク・デバイスのサイズとアクセスの制限を受けます。
ディスク・デバイスにログ・ファイルを書き込むだけの余裕がなかったり,他の方法でのデバイスへのアクセスが制限されていたりすると,ログ・ファイルから記録が失われる可能性があります。
6.5.2 OPCOM メッセージについて | |
次の表に示す各項では,オペレータ・ログ・ファイルに含まれるメッセージの種類を説明します。
6.5.2.8 項 「オペレータ・ログ・ファイルの内容」 に,オペレータ・ログ・ファイル内にある典型的なメッセージの例を示します。
REPLY/LOG コマンドを入力すると,現在のオペレータ・ログ・ファイルがクローズし,代わりに新しいバージョンがオープンします。
それ以後生成される OPCOM メッセージは,この新しいログ・ファイルに記録されるようになります。
新しいログ・ファイルを作成すると,その先頭には初期化メッセージが記録されます。
初期化メッセージには,ログ・ファイルを初期化したオペレータとそのログ・ファイル指定が次の形式で示されます。
%%%%%%%%%%% %OPCOM, <dd-mmm-yyyy hh:mm:ss.cc> %%%%%%%%%%%
Logfile has been initialized by operator <terminal-name>
Logfile is <logfile-specification>
|
例
%%%%%%%%%%% OPCOM, 19-APR-2002 12:29:24.52 %%%%%%%%%%%
Logfile has been initialized by operator _MARS$VTA2:
Logfile is HOMER::SYS$SYSMOND:[SYSMGT]OPERATOR.LOG;43
|
一部の入出力ドライバは,制御するデバイスの状態変化に関するメッセージを OPCOM に送信します。
たとえば,ライン・プリンタがオフラインになった場合,明示的にオンライン状態に戻すまで,オペレータ・ログ・ファイルには OPCOM メッセージが定期的に記録されます。
オペレータ・ログ・ファイルに記録されるデバイス状態メッセージの形式は次のとおりです。
%%%%%%%%%%%% OPCOM <dd-mmm-yyyy hh:mm:ss.cc> %%%%%%%%%%%%
Device <デバイス名> is offline
|
このメッセージは,カード・リーダ,ライン・プリンタ,磁気テープの場合に表示されます。
6.5.2.3 ターミナルの使用可能または不能メッセージ
次に,ターミナルをオペレータ・ターミナル (コンソール) として使用可能または使用不能にするコマンドの例を示し,それらのコマンドを実行したときにオペレータ・ログ・ファイルに記録されるメッセージについて説明します。
REPLY/ENABLE メッセージ
ターミナルをオペレータ・ターミナルとして指定する場合は,使用したいターミナルで REPLY/ENABLE と入力します。
OPCOM は次の形式のメッセージをオペレータ・ターミナルに表示し,同時にオペレータ・ログ・ファイルに記録して,この要求を確認します。
%%%%%%%%%%%% %OPCOM dd-mmm-yyyy hh:mm:ss.cc %%%%%%%%%%%%
Operator <ターミナル名> has been enabled, username <ユーザ名>
%%%%%%%%%%%% %OPCOM dd-mmm-yyyy hh:mm:ss.cc %%%%%%%%%%%%
Operator status for operator <ターミナル名>
<状態レポート>
|
このメッセージはオペレータ・ターミナルとして使用可能になったターミナルを示し,そのターミナルが受け付けて応答できる要求をリストします。
また,REPLY/ENABLE=クラス・コマンドを入力すると,ターミナルを特定の機能のためのオペレータ・ターミナルとして指定することもできます。
たとえば,REPLY/ENABLE=TAPES コマンドを入力すると,OPCOM により,次のようなメッセージが表示されます。
%%%%%%%%%%%% %OPCOM 19-APR-2002 10:25:35.74 %%%%%%%%%%%%
Operator _ROUND$OPA1: has been enabled, username SYSTEM
%%%%%%%%%%%% %OPCOM 19-APR-2002 10:25:38.82 %%%%%%%%%%%%
Operator status for operator _ROUND$OPA1:
TAPES
|
OPCOM は,このターミナルがオペレータ・ターミナルとして使用可能になったことを確認し,またこのターミナルがテープのマウントやディスマウントなど,磁気テープに関するイベントの要求と応答だけを扱うことのできるターミナルであることを示します。
REPLY/DISABLE メッセージ
オペレータ・ターミナルとして宣言されたターミナルは,そのオペレータがログアウトすると自動的に非オペレータ・ターミナルの状態になります。
ログアウトしないでターミナルを通常の (非オペレータの) 状態に戻すためには,そのターミナルから REPLY/DISABLE コマンドを実行します。
OPCOM は,そのターミナルがオペレータ・ターミナルでなくなったことを確認するメッセージをターミナルに表示し,同時にオペレータ・ログ・ファイルに記録します。
このメッセージは,ターミナルが非オペレータ状態に戻ったことと,その状態変化が行われた日時を次の形式で示します。
%%%%%%%%%%% %OPCOM <dd-mmm-yyyy hh:mm:ss.cc> %%%%%%%%%%%
Operator <ターミナル名> has been disabled, username <ユーザ名>
|
あるターミナルをオペレータ・ターミナルとして宣言したときにその機能の一部が使用できない場合は,OPCOM から状態メッセージが表示されます。
状態メッセージは,該当するターミナルが受け取ったり応答したりできる要求を示します。
形式は次のとおりです。
%%%%%%%%%%% %OPCOM <dd-mmm-yyyy hh:mm:ss.cc> %%%%%%%%%%%
Operator status for operator <ターミナル名>
<状態レポート>
|
たとえば,ターミナルを,磁気テープおよびディスクに関連するメッセージ,および OPER10 というシステム固有の特殊なオペレータ・クラスのメッセージを受信するオペレータ・ターミナルとして定義し,後になって,テープに関連するメッセージの受信をやめる場合を考えてみます。
REPLY/DISABLE=TAPES コマンドを実行すると,OPCOM から次のようなメッセージが返されます。
%%%%%%%%%%% %Opcom 19-APR-2002 09:23:45.32 %%%%%%%%%%%
Operator status for operator TTA3
DISKS, OPER10
|
このメッセージは,TTA3 というターミナルが,ディスクに関するメッセージとオペレータ・クラス OPER10 へのメッセージを受信していること,および受信したメッセージに対して応答ができることを示しています。
6.5.2.4 ユーザ要求とオペレータ応答メッセージ
ユーザがオペレータと連絡をとるためには,REQUEST コマンドで /REPLY 修飾子あるいは /TO 修飾子のいずれかを指定します。
これらの修飾子には次の働きがあります。
コマンド | 説明 |
---|
REQUEST/REPLY | 要求は次の形式でオペレータ・ログ・ファイルに記録される。
%%%%%%%%%%% %OPCOM <dd-mmm-yyyy hh:mm:ss.cc> %%%%%%%%%%%
Request <要求 id>, from user <ユーザ名> on <ノード名><_ターミナル名:>, <"メッセージ・テキスト">
|
このメッセージは,メッセージを送信したユーザ,メッセージが送信された時刻,メッセージに割り当てられた要求識別番号 (要求 ID),そのメッセージの発信元のターミナル,およびメッセージを示している。 |
REQUEST/TO | 要求内容は,REQUEST/REPLY の例で示した形式でオペレータ・ログ・ファイルに記録される。
ただし,要求 ID は記録されない。
%%%%%%%%%%% %OPCOM, <dd-mmm-yyyy hh:mm:ss.cc> %%%%%%%%%%%
Request from user <ユーザ名> on <ノード名><_ターミナル名:>, <"メッセージ・テキスト">
|
|
また,メッセージは,ユーザに対してどのように応答するかによっても異なってきます。
コマンド | 説明 |
---|
REPLY/TO | 内容はオペレータ・ログ・ファイルに次の形式で記録される。
response message
<hh:mm:ss.cc>, request <要求 id> completed
by operator <ターミナル名>
|
このメッセージは,オペレータがユーザの要求にどう応答したか,応答が入力された時刻,応答したオペレータを示している。 |
REPLY/ABORT | 内容はオペレータ・ログ・ファイルに次の形式で記録される。
<hh:mm:ss.cc>, request <要求 id> was aborted
by operator <ターミナル名>
|
|
REPLY/PENDING
| 内容はオペレータ・ログ・ファイルに記録されない。
これは,その要求が完了しない (すなわち,応答も中断もされない) ためである。 |
REQUEST/REPLY コマンドによってすべてのオペレータ・ターミナルが使用不能になると,OPCOM はそれ以後,ユーザからのすべての要求をログ・ファイルに記録しますが,オペレータの応答が行われないことを示すメッセージをユーザに返すことはありません。
オペレータ・ログ・ファイルに記録されるオペレータ応答は,REPLY/ENABLE,REPLY/DISABLE,REPLY/LOG の各コマンドに関連するものだけです。
他のオペレータ応答は記録されません。
6.5.2.5 ボリュームがマウントまたはディスマウントされたことを示すメッセージ
オペレータ・ログ・ファイルに記録されるオペレータ・メッセージの多くは,おそらく次のようなボリュームのマウントとディスマウントに関するものです。
%%%%%%%%%%% OPCOM, 19-APR-2002 22:41:07.54 %%%%%%%%%%%
message from user SYSTEM
Volume "KLATU " dismounted, on physical device MTA0:
15-APR-2002 22:42:14.81, request 2 completed by operator OPA0
|
ユーザは適切な特権を持っていれば,システム・パラメータの以下の値を変更することができます。
値 | 説明 |
---|
現在値 | ディスク上の省略時のパラメータ・ファイルに格納されている値で,システムのブート時に使用される。 |
アクティブ値 | メモリに格納されている値で,システムの稼働時に使用される。 |
システムはブートするとき,現在値をメモリに読み込み,アクティブ値を作成します。
アクティブ値と現在値は,どちらかを変更するまでは同じ値となります。
ユーザは,システム・パラメータのアクティブ値と現在値に以下の変更を加えることができます。
-
システム・パラメータのアクティブ値 -- CMKRNL 特権を持つユーザは,システム管理ユーティリティ (SYSMAN) またはシステム生成ユーティリティ (SYSGEN) を使用して,稼働中 (アクティブ) のシステムのシステム・パラメータを変更できる。
ただし,ダイナミック・システム・パラメータとして分類されているアクティブ値のみ。
-
システム・パラメータの現在値 -- SYSPRV 特権を持つユーザは,SYSMAN または SYSGEN を使用して現在のシステムのシステム・パラメータを変更できる。
OPCOM は,現在のシステム・パラメータに対して行われたすべての変更を,SYSGEN メッセージとしてログ・ファイルに記録します。
形式は次のとおりです。
%%%%%%%%%%% %OPCOM <dd-mmm-yyyy hh:mm:ss.cc> %%%%%%%%%%%
Message from user <ユーザ名>
%SYSGEN-I-WRITExxx, <システム・モード> system parameters modified by
process ID
<プロセス id> into file <ファイル指定>
|
例
%%%%%%%%%%% %OPCOM 3-JUN-2002 08:11:59.55 %%%%%%%%%%%
Message from user D_PLUTO on ANASAT
%SYSGEN-I-WRITECUR, CURRENT system parameters modified by process ID 0000020B
into file SYS$UPDATE:[SYSTEM]UPDATESYS.PAR;2
|
このメッセージは,システム・パラメータの現在値が変更されていることを示しています。
アラーム・メッセージは,選択したイベントが発生したときに機密保護オペレータ・ターミナルに送信されます。
機密保護アラーム・メッセージをターミナルで受信できるようにするための方法については,6.6.6 項 「ターミナルを使用可能にして,アラーム・メッセージを受信する方法」を参照してください。
例
次の例は,JTQUOTA に変更した後の 機密保護アラーム OPCOM メッセージを表しています。
%%%%%%%%%%% OPCOM 6-JAN-2003 10:41:21.10 %%%%%%%%%%%
Message from user AUDIT$SERVER on BISCO
Security alarm (SECURITY) and security audit (SECURITY) on BISCO, system id:
20353
Auditable event: System UAF record modification
Event time: 6-JAN-2003 10:41:20.69
PID: 00600123
Process name: SYSTEM
Username: SYSTEM
Process owner: [SYSTEM]
Terminal name: RTA1:
Image name: BISCO$DUA0:[SYS0.SYSCOMMON.][SYSEXE]AUTHORIZE.EXE
Object class name: FILE
Object name: SYS$SYSTEM:SYSUAF.DAT;4
User record: NEWPORT
JTQUOTA: New: 2048
Original: 1024
|
例 6-2 「オペレータ・ログ・ファイルの例 (SYS$MANAGER:OPERATOR.LOG)」 に,オペレータ・ログ・ファイルに記録される代表的なメッセージの一部を示します。
例 6-2 オペレータ・ログ・ファイルの例 (SYS$MANAGER:OPERATOR.LOG)
|
%%%%%%%%%%% OPCOM, 19-APR-2002 22:26:07.90 %%%%%%%%%%%
Device DMA0: is offline. 1
Mount verification in progress.
%%%%%%%%%%% OPCOM, 19-APR-2002 22:26:20.22 %%%%%%%%%%%
Mount verification completed for device DMA0:
%%%%%%%%%%% OPCOM, 19-APR-2002 22:33:54.07 %%%%%%%%%%%
Operator '_ZEUS$VT333:' has been disabled, user JONES 2
%%%%%%%%%%% OPCOM, 19-APR-2002 22:34:15.47 %%%%%%%%%%%
Operator '_ZEUS$VT333:' has been enabled, user SMITH
%%%%%%%%%%% OPCOM, 19-APR-2002 22:34:15.57 %%%%%%%%%%%
operator status for '_ZEUS$VT333:'
PRINTER, TAPES, DISKS, DEVICES
%%%%%%%%%%% OPCOM, 19-APR-2002 22:38:53.21 %%%%%%%%%%%
request 1, from user PUBLIC 3
Please mount volume KLATU in device MTA0:
The tape is in cabinet A
%%%%%%%%%%% OPCOM, 19-APR-2002 22:39:54.37 %%%%%%%%%%%
request 1 was satisfied.
%%%%%%%%%%% OPCOM, 19-APR-2002 22:40:23.54 %%%%%%%%%%%
message from user SYSTEM 4
Volume "KLATU " mounted, on physical device MTA0:
%%%%%%%%%%% OPCOM, 19-APR-2002 22:40:38.02 %%%%%%%%%%%
request 2, from user PUBLIC
MOUNT new relative volume 2 () on MTA0:
%%%%%%%%%%% OPCOM, 19-APR-2002 22:41:07.54 %%%%%%%%%%%
message from user SYSTEM
Volume "KLATU " dismounted, on physical device MTA0:
15-APR-2002 22:42:14.81, request 2 completed by operator OPA0
%%%%%%%%%%% OPCOM, 19-APR-2002 22:46:47.96 %%%%%%%%%%%
request 4, from user PUBLIC
_TTB5:, This is a sample user request with reply expected.
%%%%%%%%%%% OPCOM, 19-APR-2002 22:47:38.50 %%%%%%%%%%%
request 4 was canceled
%%%%%%%%%%% OPCOM, 19-APR-2002 22:48:21.15 %%%%%%%%%%%
message from user PUBLIC
_TTB5:, This is a sample user request without a reply expected.
%%%%%%%%%%% OPCOM, 19-APR-2002 22:49:37.64 %%%%%%%%%%%
Device DMA0: has been write locked.
Mount verification in progress.
%%%%%%%%%%% OPCOM, 19-APR-2002 23:33:54.07 %%%%%%%%%%%
message from user NETACP
DECnet shutting down
|
|
各メッセージの種類は次のとおりです。
1 | デバイス状態メッセージ
|
2 | ターミナルが使用可能または使用不能になったことを示すメッセージ
|
3 | ユーザからの要求とオペレータの応答を示すメッセージ
|
4 | ボリュームがマウントまたはディスマウントされたことを示すメッセージ
|
6.5.3 オペレータ・ログ・ファイルの設定 | |
通常,オペレータ・ログ・ファイルはシステム・ディスクの [SYSMGR] というディレクトリに格納されます。
しかし,論理名 OPC$LOGFILE_NAME を定義することによって,ログ・ファイルを別の場所に格納することもできます。
OPERATOR.LOG ファイル (または論理 OPC$LOGFILE_NAME が指すファイル) のサイズとアクセスは,そのファイルが置かれているディスク・デバイスのサイズとアクセスの制限を受けます。
ディスク・デバイスにログ・ファイルを書き込むだけの余裕がなかったり,他の方法でのデバイスへのアクセスが制限されていたりすると,ログ・ファイルから記録が失われる可能性があります。
省略時の設定では,ログ・ファイルは,OpenVMS Cluster 環境のワークステーション (クラスタ内の 1 番目のシステムでないワークステーション) を除き,すべてのシステム上に作成されます。
OPCOM は,システムにグラフィック・デバイスがあるかテストして,システムがワークステーションかどうかを判断します。
具体的には,次のようにテストします。
F$DEVICE ("*", "WORKSTATION", "DECW_OUTPUT")
|
論理名 OPC$LOGFILE_ENABLE に「真」を定義することで,ログ・ファイルが作成されるようにできます。 システムをリブートするたびに,OPERATOR.LOG の新しいバージョンが作成されます。
各ノードに対して,オペレータ・ログ・ファイルが 1 つ存在します。
このファイルは,共用ファイルではありません。
このファイルは ASCII 形式のため,印刷することができます。
このファイルを定期的に印刷して参照用に保管してください。
6.5.5 項 「オペレータ・ログ・ファイルのプリント」 に,オペレータ・ログ・ファイルを印刷する方法を説明します。
6.5.3.1 オペレータ・ログ・ファイルの新バージョンの作成
DCL の REPLY/LOG コマンドにより,ファイルの新しいバージョンをいつでも作成することができます。
ログ・ファイルとして使用されるのは常に最新のバージョンで,このバージョンは他のユーザがアクセスすることはできません。
省略時の設定では,すべてのオペレータ・クラスのメッセージがログ・ファイルに記録されます。
次に示すのは,REPLY/LOG コマンドを使用するときのガイドラインです。
-
ログ・ファイルに含むオペレータ・クラスを指定するときには,REPLY/LOG/ENABLE=(キーワード) および REPLY/LOG/DISABLE=(キーワード) の 2 つのコマンドが使用できる。
-
REPLY/ENABLE コマンドおよび REPLY/DISABLE コマンドで /LOG 修飾子を使用する場合,キーワードで選択したクラスがターミナルで有効あるいは無効になるのではなく,ログ・ファイルへの記録が開始または停止される。
ログ・ファイルがすでにオープンしていると,クラス・リストが保持され,新しく作成されたログ・ファイルで有効になります。
ログ・ファイルがオープンしていない場合には,論理名 OPC$LOGFILE_CLASSES の値が使用されます。
この論理名が存在しなければ,新しいログ・ファイルですべてのクラスが有効になります。
OPC$LOGFILE_CLASSES に不正なクラスが含まれていると,すべてのクラスが有効となり,次のようなメッセージが,システムのスタートアップ時にコンソールに表示され,OPERATOR.LOG ファイルに記録されます。
%%%%%%%%%%% OPCOM 18-MAY-2002 13:28:33.12 %%%%%%%%%%%
"BADCLASS" is not a valid class name in OPC$LOGFILE_CLASSES
|
正しいオペレータ・クラスについては,『OpenVMS システム管理者マニュアル (上巻)』を参照してください。 詳細は,『OpenVMS DCL ディクショナリ』の REPLY/LOG,REPLY/ENABLE,REPLY/DISABLE の各コマンドの項目を参照してください。
例
ディスクおよびテープのマウントおよびディスマウント操作を記録するログ・ファイルをオープンします。
$ REPLY/LOG/ENABLE=(DISKS,TAPES)
|
コマンド・プロシージャ SYS$MANAGER:SYLOGICALS.COM に論理名を定義することによって,オペレータ・ログ・ファイルの省略時の状態を指定することができます。
次の表に,そのような論理名とその働きをまとめます。
SYLOGICALS.COM についての詳細は,『OpenVMS システム管理者マニュアル (上巻)』を参照してください。
論理名 | 働き |
---|
OPC$ALLOW_INBOUND | ノードに戻ってくる OPCOM トラフィックをオフまたはオンする。
省略時の設定では,この論理名は,TRUE に定義されている。
この論理名を FALSE に定義すると,ノードはクラスタ内の別のノードから大半の OPCOM メッセージを受信しなくなる。 |
OPC$ALLOW_OUTBOUND | ノードから出て行く OPCOM トラフィックをオフまたはオンする。
省略時の設定では,この論理名は,TRUE に定義されている。
この論理名を FALSE に定義すると,ノードはクラスタ内の別のノードへ大半の OPCOM メッセージを送信しなくなる。 |
OPC$LOGFILE_ENABLE
| オペレータ・ログ・ファイルをオープンするかどうかを指定する。
この論理名を TRUE に定義するとオペレータ・ログ・ファイルをオープンし,FALSE に定義するとオープンしない。
省略時の設定では,OpenVMS Cluster 環境上のワークステーションを除くすべてのシステム上でログ・ファイルがオープンする。 |
OPC$LOGFILE_CLASSES
| ログ・ファイルに記録するイベントのオペレータ・クラスを指定する。
省略時の設定では,すべてのクラスのイベントを記録するものとしてログ・ファイルをオープンする。
論理名は,適用するクラスの検索リスト,コンマで区切ったリスト,あるいはその両方の組み合わせで指定できる。
OPC$LOGFILE_ENABLE を定義しない場合でも OPC$LOGFILE_CLASSES を定義できる。
その場合,指定したクラスは,オープンするすべてのログ・ファイルに使用される。
しかし,各ログ・ファイルをオープンするかどうかは省略時の設定が適用される。 有効なオペレータ・クラスについての説明は,『OpenVMS システム管理者マニュアル (上巻)』を参照。 |
OPC$LOGFILE_NAME
| ログ・ファイルの名前を指定する。
この論理名の定義を省略すると,ログ・ファイルの名前は SYS$MANAGER:OPERATOR.LOG となる。
システム・ディスク以外のディスクを指定する場合は,コマンド・プロシージャ SYLOGICALS.COM にそのディスクをマウントするコマンドを加える必要がある。 |
OPC$OPA0_ENABLE
| クラスタ内のワークステーション用のシンボル値を上書きする。
この論理名を TRUE と定義すると,OPA0 デバイスを BROADCAST (NOBROADCAST の省略時の設定を上書き) に設定する。
クラスタ内のワークステーションではないシステムの場合,この論理名を FALSE と定義すると,OPA0 デバイスが NOBROADCAST に設定される。 |
6.5.4 オペレータ・ログ・ファイルの管理 | |
オペレータ・ログ・ファイルを定期的に管理するための計画をたててください。
まず,毎日新しいログ・ファイルを起動し,前日に使用していたファイル (2 番目に新しいバージョン) をリネームするという方法があります (次の項の例を参照)。
あるいは,古いファイルを削除することもできます。
ただし,ログ・ファイルを削除する場合には,必ずそのバックアップをとるようにしてください。
詳細は『OpenVMS システム管理者マニュアル (上巻)』を参照してください。
OPCOM を誤って削除してしまった場合は,次の手順に従って手動で起動します。
-
SYSTEM アカウントにログインして,この操作に必要な特権を入手する。
-
次のコマンドを入力して,スタートアップ・コマンド・プロシージャ (STARTUP.COM) を実行し,コマンド・パラメータとして OPCOM を指定する。
$ @SYS$SYSTEM:STARTUP OPCOM
|
6.5.5 オペレータ・ログ・ファイルのプリント | |
次に,オペレータ・ログ・ファイルの最新のバージョンをプリントする手順を示します。
この作業を行うためには,OPER 特権が必要です。
-
ターミナルをオペレータ・ターミナルとして宣言 (使用可能に) する。
-
現在のログ・ファイルをクローズし,新しいファイルをオープンする。
-
省略時の値を SYS$MANAGER に設定し,次のコマンドによってファイルのすべてのバージョンを表示する。
$ SET DEFAULT SYS$MANAGER
$ DIRECTORY OPERATOR.LOG
|
-
2 番目に新しいバージョンを OPERATOR.OLD にリネームする。
$ RENAME OPERATOR.LOG;-1 OPERATOR.OLD
|
バージョン番号 –1 は,このファイルの 2 番目に新しいバージョンを表す。
なお,最も大きなバージョン番号は,現在使用中のオペレータ・ログ・ファイルである。
-
オペレータ・ログ・ファイルをプリントする。
例
$ REPLY/ENABLE 1
$ REPLY/LOG 2
%%%%%%%%%%% OPCOM, 19-APR-2002 12:28:20.11 %%%%%%%%%%%
Logfile was closed by operator _MARS$VTA2: 3
Logfile was HOMER::SYS$MANAGER:[SYSMGT]OPERATOR.LOG;27
%%%%%%%%%%% OPCOM, 19-APR-2002 12:29:24.52 %%%%%%%%%%%
Logfile has been initialized by operator _MARS$VTA2:
Logfile is HOMER::SYS$MANAGER:[SYSMGT]OPERATOR.LOG;28
$ SET DEFAULT SYS$MANAGER 4
$ DIRECTORY OPERATOR.LOG 5
Directory SYS$MANAGER:[SYSMGT]
OPERATOR.LOG;28 OPERATOR.LOG;27
Total of 2 files.
$ RENAME OPERATOR.LOG;-1 OPERATOR.OLD 6
$ PRINT OPERATOR.OLD 7
|
番号が付いた各行の意味は次のとおりです。
1 |
REPLY/ENABLE コマンドにより,ターミナルをオペレータ・ターミナルとして宣言する。
|
2 |
REPLY/LOG コマンドにより,現在のログ・ファイルをクローズし,新しいファイルをオープンする。
|
3 |
新しいログ・ファイルがオープンされたことを示す OPCOM からのメッセージ。
|
4 |
SET DEFAULT コマンドにより,オペレータの省略時のディスクとしてシステム・ディスクを使用するよう設定する。
|
5 |
DIRECTORY コマンドにより,システム・ディスク上の [SYSMGR] ディレクトリ内のファイルを表示する。
|
6 |
RENAME コマンドにより,オペレータ・ログ・ファイルの 2 番目に新しいバージョンを OPERATOR.OLD にリネームする |
7 |
PRINT コマンドにより,古いオペレータ・ログ・ファイル OPERATOR.OLD をプリントする。
|
この節では,機密保護監査機構の働き,機密保護監査機構の起動,および機密保護監査ログ・ファイルを新しく作成する方法を説明します。
機密保護監査ログ・ファイルについての詳細は,『OpenVMS システム・セキュリティ・ガイド』を参照してください。
6.6.1 機密保護監査機構について | |
機密保護監査機構は,機密保護関係のイベントがシステム上で発生したときに,それを記録する機能です。
機密保護関係のイベントは,イベント・クラスと呼ばれるカテゴリに分類されます。
省略時の設定では,システムを 表 6-7 「省略時のイベント・クラス」 に示すイベント用にインストールまたはアップグレードしたときに,機密保護監査機構が使用できるようになります。
表 6-7 省略時のイベント・クラス クラス | 説明 |
---|
ACL | 機密保護監査機構 ACE を持つ全オブジェクトへのアクセス。 |
AUDIT | SET AUDIT コマンドの全用途。
このカテゴリは使用禁止にできない。 |
AUTHORIZATION | 登録データベースに加えたすべての変更。
-
-
ネットワーク代理登録ファイル (NETPROXY および NET$PROXY) -
|
BREAKIN | すべてのブレークインの試み。
バッチ,独立,ダイアルアップ,ローカル,ネットワーク,遠隔。 |
LOGFAILURE | すべてのログイン障害。
バッチ,ダイアルアップ,ローカル,遠隔,ネットワーク,サブプロセス,独立。 |
使用しているサイトにおける機密保護の必要条件が,その他の監査にも合う場合は,6.6.4 項 「その他のクラスに対して機密保護監査機構を使用する方法」 で説明するように,DCL の SET AUDIT コマンドを使用して,別のイベント・クラスを使用可能にすることができます。
監査サーバ・プロセスは,システム起動時に作成され,機密保護監査ログ・ファイル SYS$MANAGER:SECURITY.AUDIT$JOURNAL 中の特定のイベントを記録します
(記録されるイベントについては,表 6-7 「省略時のイベント・クラス」 を参照)。
定期的にファイルを検討するときの手順によって,機密保護監査ログ・ファイルの有用性は変わってきます。
サイトの監査検討方針の一部として,たとえば次のような手順が考えられます。
-
毎朝,機密保護管理ログ・ファイルの新しいバージョンを作成する。
-
前日のログ・ファイルを見て,問題があると思われるシステム・アクティビティがないか,検討する。
システムについて監査する機密保護イベントの数によっては,監査ログ・ファイルに書き込まれる監査レコードすべてを検討することは現実的ではない場合がある。
そのようなときには,特定のレコード・セット (たとえば,Authorization レコードや Breakin レコード,あるいは通常の勤務時間外に作成された全イベント) をログ・ファイルから選択したい場合もある。
-
検討中に,問題があると思われる機密保護イベントが見つかった場合は,機密保護監査ログ・ファイルをより詳細に調べる
(『Security Guide』 を参照)。
6.6.1.2 混合バージョン・クラスタの監査ログ・ファイル
以前のバージョンのシステムで実行される監査分析ユーティリティ (ANALYZE/AUDIT) は,最新バージョンの監査ログ・ファイルを処理できません。
最新バージョンを処理するには,ANALYZE/AUDIT の最新バージョンを使用する必要があります。
混合バージョンのクラスタでは,別々の監査ログ・ファイルを保守することをお勧めします。
監査ログ・ファイルの出力先を変更するには,以前のバージョンを実行するノードと最新バージョンを実行するノードの両方で,次のコマンドを発行します。
AUDIT/JOURNAL/DESTINATION=ファイル指定
|
ここで指定したファイル指定は,監査サーバ・データベース・ファイルに格納されます。
省略時の設定では,このファイルは SYS$COMMON:[SYSMGR] に格納され,それぞれ SECURITY_AUDIT.AUDIT$JOURNAL と SECURITY.AUDIT$JOURNAL と呼ばれます。
オペレーティング・システムは,ワークステーションと制限された管理リソースを持つユーザが,監査ログ・ファイルを別のノードに複製することを許可します。
2次ログ,つまり機密保護アーカイブ・ファイルは,ファイルを解析できる遠隔ノード上のセキュリティ・アドミニストレータが使用できます。
クラスタ内の各ノードは,各自のアーカイブ・ファイルを持っていなければなりません。
アーカイブ・ファイルは,クラスタ内の複数のノードでは共用できません。
詳細は『OpenVMS システム・セキュリティ・ガイド』を参照してください。
6.6.2 機密保護監査情報の表示 | |
現在サイトが監査しているイベント・クラスを調べるには,DCL の SHOW AUDIT コマンドを入力します。
表示される機密保護情報の例を次に示します。
System security alarms currently enabled for:
ACL
Breakin: dialup,local,remote,network,detached
Privilege use:
SECURITY
Privilege failure:
SECURITY
System security audits currently enabled for:
ACL
Authorization
Breakin: dialup,local,remote,network,detached
Login: dialup,local,remote,network,detached
Logfailure: batch,dialup,local,remote,network,subprocess,detached
Logout: dialup,local,remote,network,detached
Privilege use:
SECURITY
Privilege failure:
ACNT ALLSPOOL ALTPRI AUDIT BUGCHK BYPASS CMEXEC CMKRNL
DETACH DIAGNOSE EXQUOTA GROUP GRPNAM GRPPRV LOG_IO MOUNT
NETMBX OPER PFNMAP PHY_IO PRMCEB PRMGBL PRMMBX PSWAPM
READALL SECURITY SETPRV SHARE SHMEM SYSGBL SYSLCK SYSNAM
SYSPRV TMPMBX VOLPRO WORLD
DEVICE access:
Failure: read,write,physical,logical,control
FILE access:
Failure: read,write,execute,delete,control
VOLUME access:
Failure: read,write,create,delete,control
|
6.6.3 監査の開始を遅らせる方法 | |
通常は,SYSTARTUP_VMS.COM が実行される直前に VMS$LPBEGIN の監査が開始されますが,論理名 SYS$AUDIT_SERVER_INHIBIT を定義し直せば,この動作を変更することができます。
オペレーション・システムが機密保護イベント・メッセージを送り始めるタイミングを変更するには,次の行を SYS$STARTUP:SYLOGICALS.COM コマンド・プロシージャに追加します。
$ DEFINE/SYSTEM/EXECUTIVE SYS$AUDIT_SERVER_INHIBIT YES
|
これで,システム・スタートアップの別のフェーズ (おそらく,SYSTARTUP_VMS.COM の終わり) で監査を開始することができます。
これを行うには,コマンド・ファイルを編集して,次の行を追加します。
$ SET AUDIT/SERVER=INITIATE
|
SYSTARTUP_VMS.COM の編集に関しては,『OpenVMS システム管理者マニュアル (上巻)』を参照してください。
6.6.4 その他のクラスに対して機密保護監査機構を使用する方法 | |
表 6-7 「省略時のイベント・クラス」 に示したクラス以外のクラスに対して機密保護監査を行うには,次の形式を使用します。
SET AUDIT/ENABLE=キーワード[,...] {/ALARM | /AUDIT}
使用可能にできるイベント・クラスの説明については,『OpenVMS システム・セキュリティ・ガイド』を参照してください。
その他のイベント・クラスを監査できるようにするためには,次の 2 つの修飾子を指定しなければなりません。
-
/ENABLE
-
/ALARM または /AUDIT のいずれか
(必ず 1 つは指定すること。
また,両方とも指定してもかまわない。)
/ENABLE,/ALARM,/AUDIT の各修飾子について,次に説明します。
修飾子 | 説明 |
---|
/ENABLE | 監査するイベント・クラスを定義する。
詳細は 第7章 「資源使用状況の調査」 を参照。 |
/ALARM,
/AUDIT | イベント・メッセージのデスティネーションを定義する。
-
/ALARM は,メッセージのデスティネーションを使用可能になっている全セキュリティ・オペレータ・ターミナルに指定する。 -
/AUDIT は,メッセージのデスティネーションを機密保護ログ・ファイルに指定する。
重要なイベントを報告するには,/ALARM 修飾子と /AUDIT 修飾子を使用する。
比較的重要でないイベントは,後で調べることができるように機密保護監査ログ・ファイルだけに書き込んでおくことができる。 表 6-7 「省略時のイベント・クラス」 に示す省略時のイベント・クラスは,ALARM および AUDIT として送られる。 |
新しいイベントの監査は,全ノードでそれが使用できるようにすると,すぐに開始されます。
例
-
次のコマンドを実行すると,ボリュームのマウントとディスマウントに対する監査が使用可能になります。
さらに,メッセージを機密保護監査ログ・ファイルに送信します。
$ SET AUDIT/ENABLE=MOUNT/AUDIT
|
-
次のコマンドを実行すると,ファイルへのアクセス失敗に対する監査が可能になります。
さらに,メッセージを機密保護監査ログ・ファイルおよびすべての使用可能なセキュリティ・オペレータ・ターミナルに送信します。
$ SET AUDIT/ALARM/AUDIT/ENABLE=ACCESS=FAILURE/CLASS=FILE
|
6.6.5 機密保護監査機構の使用禁止 | |
ユーザが次の構文を使って明示的に /DISABLE 修飾子が指定されたクラスを使用禁止にするまで,監査は続けられます。
SET AUDIT/DISABLE=キーワード[,...] {/ALARM | /AUDIT}
6.6.6 ターミナルを使用可能にして,アラーム・メッセージを受信する方法 | |
アラーム・メッセージは,セキュリティ・クラス・メッセージ用に使用可能にされているターミナルに送信されます。
機密保護アラーム・メッセージはオペレータ・ログ・ファイルに書き込まれず,セキュリティ・クラス・メッセージ用に使用可能にされているターミナルだけに表示されます。
多くの場合,機密保護アラーム・メッセージは省略時の設定としてシステム・コンソールに表示されますが,メッセージは画面上を高速でスクロールするので,セキュリティ・クラス・メッセージ用に別個のターミナルを使用できるようにしておき,システム・コンソールにはメッセージが表示されないようにしておくとよいでしょう。
安全な場所にあるターミナルをハードコピーの出力用として指定しておくか,あるいはセキュリティ・オペレータ・ターミナルを監視する専門の担当者を決めておくようにしてください。
セキュリティ・オペレータとして使用可能にするターミナルの数に制限はありません。
セキュリティ・クラス・アラーム・メッセージを受信するようにターミナルを設定するには,指定したターミナルで次の DCL コマンドを入力します。
例
次に,機密保護アラーム・メッセージの例を示します。
%%%%%%%%%%% OPCOM 25-MAY-2002 16:07:09.20 %%%%%%%%%%%
Message from user AUDIT$SERVER on GILMORE
Security alarm (SECURITY) on GILMORE, system id: 20300
Auditable event: Process suspended ($SUSPND)
Event time: 25-MAY-2002 16:07:08.77
PID: 30C00119
Process name: Hobbit
Username: HUBERT
Process owner: [LEGAL,HUBERT]
Terminal name: RTA1:
Image name: $99$DUA0:[SYS0.SYSCOMMON.][SYSEXE]SET.EXE
Status: %SYSTEM-S-NORMAL, normal successful completion
Target PID: 30C00126
Target process name: SMISERVER
Target username: SYSTEM
Target process owner: [SYSTEM]
|
6.6.7 機密保護レポートの作成 | |
作成するレポートの最も一般的なタイプは,簡略レポートで,これはイベントの日誌リストです。
その日の機密保護イベント・メッセージのレポートを作成し,そのレポートを MAIL を使ってシステム管理者に送信するためのコマンド・プロシージャを作成して,毎夜バッチ・ジョブ形式で実行することができます。
次に,ANALYZE/AUDIT コマンド行を使用して,このようなレポートを作成する例を示します。
$ ANALYZE/AUDIT/SINCE=TODAY/OUTPUT=31JAN2002.AUDIT -
_$ SYS$MANAGER:SECURITY.AUDIT$JOURNAL
$ MAIL/SUBJECT="Security Events" 31JAN2002.AUDIT SYSTEM
|
6.6.8 機密保護監査ログ・ファイルの新しいバージョンの作成 | |
ユーザ側で何らかの処置を行わない限り,機密保護監査ログ・ファイルは大きくなり続けるので,その保守には工夫が必要です。
クラスタ用機密保護監査ログ・ファイルを新しく作成するためには,SET AUDIT コマンドを入力します。
それまでに記録された監査メッセージが失われないように,メモリ内に記憶されたすべての監査メッセージがファイルに書き込まれるまで,監査ログ・ファイルの古いバージョンはクローズされません。
6.6.8.1 ログ・ファイルの新しいクラスタ全体としてのバージョンの作成
機密保護監査ログ・ファイルの,新しい,クラスタ全体としてのバージョンを作成するには,次のコマンドを使用します。
$ SET AUDIT/SERVER=NEW_LOG
|
監査サーバ・プロセスにより,クラスタ・ノードごとに監査ログ・ファイルの新しいバージョンがオープンされます。
新しいログをオープンしたら,古いバージョンをリネームします。
これには,データの開始または終了日付をファイル名に組み込む,ファイルの命名規則を使用します。
次に古いログを別のディスクにコピーし,ディスク空間を節約するためシステム・ディスクからこのログを削除します。
そして,古いログに対して監査分析ユーティリティを実行します。
このファイルを保管しておくことにより,クラスタ全体としての監査メッセージの履歴を管理します。
システム上に機密保護の侵害の恐れがあった場合,指定した時間帯に保管したログ・ファイルを分析して,疑わしいユーザ・アクティビティを追跡することができます。
6.6.8.2 ログ・ファイルの新しいノード固有のバージョンの作成
場合によっては,OpenVMS Cluster ノードが同じシステム・セキュリティ監査ログ・ファイルを共用していないことがあります。
機密保護監査ログ・ファイルの新しい,ノード固有のバージョンを作成するには,次のコマンドを使用します。
$ SET AUDIT/DESTINATION=ファイル指定
$ SET AUDIT/SERVER=NEW_LOG
|
ファイル指定には,ノード固有のファイルを指す論理名 (SYS$SPECIFIC:[SYSMGR]SECURITY など) を指定します。
別のノード上のシステム機密保護監査ログ・ファイルには影響しません。
Monitor ユーティリティ(MONITOR)は,オペレーティング・システムの性能に関する情報を入手するためのシステム管理ツールです。
さまざまな MONITOR 修飾子を指定することにより,稼働中のシステムからシステム性能データを収集したり,以前にレコード・ファイルに記録されたデータをプレイバックしたりすることができます。
プレイバックしたデータは,表示,要約したり,記録し直してレコード・ファイル内のデータ量を減らしたりすることもできます。
この節では,MONITOR ユーティリティの働きと,MONITOR ユーティリティによって情報を表示したり記録したりするいくつかの異なる方法を説明します。
具体的には,次のトピックを取り上げます。
Monitor ユーティリティにより得られる情報の解釈については,『Guide to OpenVMS Performance Management』を参照してください。
また,Monitor ユーティリティの使用方法については,『OpenVMS システム管理 ユーティリティ・リファレンス・マニュアル』を参照してください。
6.7.1 MONITOR について | |
MONITOR を使用して,システム全体の性能データ (システム入出力統計,ページ管理統計,各プロセッサ・モードの動作時間など) を特定の間隔で監視し,いろいろな形式で出力することができます。
また,MONITOR をバックグラウンド・プロセスとして継続的に実行することにより,システムの性能情報のデータベースを開発することもできます。
これについては,6.7.9 項 「MONITOR の継続実行」を参照してください。
各 MONITOR クラスはいくつかのデータ項目から構成されます。
個々のクラスに対して定義されているデータ項目の一覧については,『OpenVMS システム管理 ユーティリティ・リファレンス・マニュアル』の MONITOR コマンドの説明を参照してください。
特別な情報のクラスを監視するには,MONITOR コマンド行にクラス名を指定します。
MONITOR が表示する情報は,選択したクラスのタイプによって異なります。
表 6-8 「MONITOR クラスの種類」 では,2 つの MONITOR クラス・タイプの比較を示します。
表 6-8 MONITOR クラスの種類 クラスの種類 | 説明 |
---|
システム・クラス | システム全体の資源の使用状況に関する統計値。 |
コンポーネント・クラス | 個々のコンポーネントがシステムあるいはクラスタ全体に対してどれだけ「貢献」しているかを示す統計値。 |
MONITOR クラスの 2 つの種類の違いとして,IO クラスと DISK クラスを例にとって考えることができます。
IO クラスは,システム全体のすべての直接入出力操作を計測するデータ項目が含まれるため,システム・クラスに属します。
一方,DISK クラスは,個々のディスクの直接入出力操作を計測するため,コンポーネント・クラスに属します。
表 6-9 「MONITOR クラス」 に,各 MONITOR クラスとクラスの種類 (システムかコンポーネントか) を示します。
表 6-9 MONITOR クラス クラス | 種類 | 説明 |
---|
ALL_CLASSES | システムまたはコンポーネント | すべてのクラスの統計値 |
CLUSTER | システム | クラスタ全体の性能に関する統計値 |
DECNET | システム | DECnet for OpenVMS に関する統計値 |
DISK | コンポーネント | ディスク入出力に関する統計値 |
DLOCK | システム | 分散型ロック管理情報の統計値 |
FCP | システム | ファイル制御プリミティブに関する統計値 |
FILE_SYSTEM_CACHE | システム | ファイル・システム・キャッシュに関する統計値 |
IO | システム | システム入出力に関する統計値 |
LOCK | システム | ロック管理情報の統計値 |
MODES | コンポーネント | 各プロセッサ・モードでの動作時間 |
MSCP_SERVER | システム | MSCP サーバに関する統計値 |
PAGE | システム | ページ管理情報の統計値 |
PROCESSES | コンポーネント | すべてのプロセスに関する統計値 |
RMS | コンポーネント | レコード管理サービス (RMS) に関する統計値 |
SCS | コンポーネント | システム通信サービスに関する統計値 |
STATES | システム | スケジューラ状態ごとのプロセス数 |
SYSTEM | システム | 他のクラスに関する統計値の要約 |
TRANSACTION | システム | DECdtm サービスに関する統計値 |
VBS[1] | システム | 仮想バランス・スロットに関する統計値 |
VECTOR | システム | スケジューリングされたベクタ・プロセッサの使用 |
PROCESSES クラスのものを除き,表示可能なデータ項目はすべてレートとレベルで表されます。
データ項目ごとに,次の 4 種類の統計値をどれでも,また何種類でも要求することができます。
統計値 | 説明 |
---|
レートまたはレベルの現在値 | 最も新しく収集された,レートまたはレベルの値 |
レートまたはレベルの平均値 | MONITOR 要求の最初から測定される |
レートまたはレベルの最小値 | MONITOR 要求の最初から測定される |
レートまたはレベルの最大値 | MONITOR 要求の最初から測定される |
DISK,MODES,SCS,STATES の各クラスの場合は,オプションとしてすべての統計値をパーセンテージで表すことができます。
PROCESSES クラスでは,MONITOR は,説明情報,レベル情報,および時間の経過で増加するカウンタが表示されます。
MONITOR は,システム性能データをクラスごとに収集し,指定した修飾子によって,次のように 3 種類のオプションの形式で出力します。
修飾子 | 説明 |
---|
/DISPLAY | ASCII 画面イメージ形式の出力を生成する。
これは /VIEWING_TIME 修飾子により指定される頻度で作成される。 |
/RECORD | 要求されたクラスのために収集したデータを含むバイナリ・レコード・ファイルを生成する。
インターバルごとに,各クラスに 1 つのレコードが作成される。 |
/SUMMARY | MONITOR 要求の間に要求された全クラスの要約統計値を含む ASCII ファイルを生成する。 |
上記の修飾子のいずれかとともに /INPUT を指定すると,MONITOR は,以前に作成したレコード・ファイルから 1 つまたは複数の性能データを収集します。
そうでない場合は,データはカウンタと稼働システム上のデータ構造から収集されます。
MONITOR 要求を開始したい場合には /BEGINNING 修飾子を,終了したい場合には /ENDING 修飾子をそれぞれ使用します。
/DISPLAY 修飾子の使用方法
MONITOR により収集された情報は,通常は ASCII 画面イメージとして表示されます。
/DISPLAY 修飾子を使用すると,ディスク・ファイルにこの情報を含めるようにオプション指定することができます。
ファイル指定を省略すると,出力先は SYS$OUTPUT になります。
/DISPLAY 修飾子については,『OpenVMS システム管理 ユーティリティ・リファレンス・マニュアル』を参照してください。
/RECORD 修飾子の使用方法
/RECORD 修飾子を使用すると,クラスに関する全データが記録されます。
これは,単一の統計値や単一のコンポーネント統計値クラスの項目だけを同時に表示している場合でも同じです。
このファイルは MONITOR 要求が開始されたときに作成され,要求が終了するとクローズします。
結果として得られたファイルを今後の要求のソース・ファイルとして使用して,ターミナル上でデータを形式化して表示したり,要約ファイルを作成したり,別の特性を持つ新しいレコード・ファイルを作成したりすることができます。
6.7.2 MONITOR の起動 | |
Monitor ユーティリティを起動するためには,次の DCL コマンドを入力します。
次のプロンプトが表示されます。
このプロンプトに対して,任意の MONITOR コマンドを入力することができます。
詳細は『OpenVMS システム管理 ユーティリティ・リファレンス・マニュアル』を参照してください。
ただし,最もよく使用する MONITOR コマンドは,クラス名を指定します。
例
この例は,ページ管理情報の統計値を監視するために MONITOR コマンドで PAGE クラスを指定しています。
DCL コマンド・レベルからも MONITOR のコマンドを使用することができます。
MONITOR 要求の変更または終了
MONITOR コマンドによる要求の動作は,/ENDING 修飾子を指定するまで続けられます。
ただし,MONITOR 要求を変更したり終了したりする場合は,次のいずれかを押します。
キー | 説明 |
---|
Ctrl/W | /VIEWING_TIME 値を一時的に変更し,現在の画面の直後に新しい画面を生成する。
この機能は,ブロードキャスト・メッセージが MONITOR 表示領域を上書きしてしまった場合に便利である。 また,/VIEWING_TIME の値が大きいときに Ctrl/W を使うと,要求があり次第表示イベントを生成することができる。 |
Ctrl/C | 現在の要求を終了するが,ユーティリティは終了しない。
したがって,引き続き MONITOR> プロンプトから新しい要求を開始したり,任意の MONITOR コマンドを入力することができる。 |
Ctrl/Z | 現在の要求を終了して,かつ MONITOR も終了する。 |
6.7.3 システムの動作の表示 | |
システムの動作の表示モードは,定期的に,あるいはインストールのチェック,チューニング,トラブルシューティングで,稼働中のシステムの動作をリアルタイムに調べたい場合に使用します。
出力の履歴情報は記録されません。
次の例は,システムの動作の表示モードの使用方法を示しています。
例
-
$ MONITOR PROCESSES/TOPCPU
|
前回の表示からこのコマンドを実行するまでに CPU を最も使用した 8 つのプロセスを示す棒グラフが表示される。
また,各プロセスが使用した CPU 時間も表示される。
このコマンドにより次のような出力が生成される。
OpenVMS Monitor Utility
TOP CPU TIME PROCESSES
on node BOMBAY
20-JAN-2002 10:06:49
0 25 50 75 100
+ - - - - + - - - - + - - - - + - - - - -+
07E00181 CAFARET 100 ****************************************
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
+ - - - - + - - - - + - - - - + - - - - -+
|
この例では,ユーザ CAFARET が使用できる CPU 時間を 100 パーセント使用している。
ユーザが使用しているコンピュータの資源についてより詳細な情報を表示するには,次のようなコマンドを使用する。
$ SHOW PROCESS/CONTINUOUS/ID=07E00181
|
この例では,結果として得られる表示の中で最も役に立つ情報は,イメージの名前であり,たとえば次のように,最後の部分に表示される。
.
.
.
$1$DUA1:[SYS1D.SYSCOMMON.][SYSEXE]RODAN.EXE
|
この例は CAFARET が RODAN.EXE を実行していることを示している。
これは新しいソフトウェアであり,その動作がループしている可能性がある。
このような状況は,CAFARET が特権ユーザで,別のユーザよりも高い優先順位でプロセスを実行した場合に発生する。
-
$ MONITOR/DISPLAY=PROCESSES.LOG PROCESSES
|
MONITOR からの情報は,サポートされている任意のターミナルまたはディスク・ファイルに出力することができる。
ここでは,MONITOR のプロセス統計を PROCESSES.LOG ファイルに書き込んでいる。
この後,このファイルをハードコピー・デバイスに出力してプリントすることができる。
-
$ MY_CLASSES :== -
_$ "DECNET+FCP+IO+LOCK+MODES+PAGE+PROCESSES+STATES"
$ MONITOR/NODE=(CURLEY,LARRY)/INTERVAL=20/VIEWING_TIME=8 'MY_CLASSES'
|
頻繁に使用するクラス名の組み合わせは,DCL シンボルに定義しておくと便利なことがある。
ここでは,CURLEY および LARRY という OpenVMS Cluster ノード に関して選択されたクラスのデータが 20 秒ごとに収集される。
また,クラスのうちの 1 つに関して収集されたデータのうちの最新の項目が 8 秒ごとに表示される。
MONITOR では,クラスの表示順序があらかじめ決められている。
6.7.4 システムの動作の記録 | |
システムの動作の記録は,将来のために MONITOR データをとっておく必要がある場合に使用します。
次のような用途が考えられます。
-
インストールのチェック,チューニング,トラブルシューティング。
すなわち,システムの動作の表示で示したすべての用途。
ターミナルに物理的に表示できる量より多くの情報を入手したい場合,ターミナルが利用できない場合,またはシステムのデータを入手する必要があるがしばらくはデータ収集のための時間がとれないという場合,記録モードを利用できる。
-
長期間に渡って定期的に性能のデータを収集する。
MONITOR データを定期的に記録してまとめることで,システム資源の使用量に関する長期間のデータを収集することができる。
次の例は,システムの動作の記録モードの使用方法を示しています。
例
$ MONITOR/NODE=(LARRY,MOE)/NODISPLAY/RECORD MODES+STATES
|
各プロセッサ・モードでの動作時間,および LARRY および MOE というノードの各スケジューラ状態におけるプロセス数のデータが記録されます。
ただし,この情報は出力されません。
6.7.5 システムの動作の表示と記録 | |
システムの動作の表示と記録モードは,性能データを保持し,収集されるときにその性能データを表示させる場合に使用します。
MONITOR では,記録ファイルに共用読み込みアクセス権が設定されるので,他の表示プロセスが記録ファイルを書き込んでいる間に,それを別の表示プロセスがプレイバックすることができます。
次の例は,性能の情報を記録しながら,同時に収集中のデータを表示する方法を示しています。
最初の例では,データの収集と記録の両方を同じコマンドで行います。
2 番目および 3 番目の例は,2 つの別々のプロセスを使って記録と表示を同時に行う方法を示しています。
2 番目の例のプロセスは記録を行い,3 番目の例のプロセスがファイルをプレイバックして要約します。
例
-
$ MONITOR/RECORD FCP/AVERAGE,FILE_SYSTEM_CACHE/MINIMUM
|
ファイル・システムとファイル・システム・キャッシュのデータを 3 秒ごとに収集して記録する。
さらに,棒グラフによって,FCP の平均値と FILE_SYSTEM_CACHE の最小値が表示される。
2 つのグラフが 3 秒ごとに交互に表示される。
現在の統計値は次のプレイバック要求で得られる。
-
$ MONITOR/RECORD=SYS$MANAGER:ARCHIVE.DAT -
_$ /INTERVAL=300/NODISPLAY ALL_CLASSES
|
すべてのクラスのデータを同時に 5 秒間隔で保存する。
同様のコマンドをバッチ・ジョブで実行し,ディスクの使用量を注意深く監視すると便利である。
-
$ MONITOR/INPUT=SYS$MANAGER:ARCHIVE.DAT: -
_$ /NODISPLAY/SUMMARY/BEGINNING="-1" PAGE,IO
|
報告された性能の問題の調査の一部として,過去 1 時間に発生したページ動作および入出力動作をまとめる。
記録を行うプロセスは 5 分ごとに OpenVMS RMS フラッシュ動作を行うため,過去 5 分以内の収集データは表示を行うプロセスからは利用できない点に注意。
/FLUSH_INTERVAL 修飾子により,フラッシュ動作を行う間隔を明示的に指定できる。
表示を行うプロセスには,記録ファイルに対する読み込みアクセス権が必要。
6.7.6 記録した動作のプレイバック | |
プレイバックとは,記録ファイルに収集されたデータの全部または一部をターミナルに表示したり,要約レポートとしてまとめたりすることをいいます。
データは,クラス,ノード,あるいは時間帯に基づいてまとめることができます。
たとえば,24 時間に渡っていくつかのクラスのデータを収集した場合,その間の任意の時間帯の 1 つ以上のクラスのデータを調べたり,まとめたりできます。
記録した時間帯と別の時間帯のデータを表示したりまとめたりすることも可能です。
スクリーンに表示を行う実際の間隔は,/VIEWING_TIME 修飾子で制御します。
次の例は,記録した動作のプレイバックを行う方法を示しています。
例
-
$ MONITOR/RECORD/INTERVAL=5 IO
⋮
$ MONITOR/INPUT IO
|
システム入出力の統計をとる。
最初のコマンドは,データの収集と表示を 5 秒間隔で行う。
この作業は,このコマンドを入力した時点から Ctrl/Z を押すまで続けられる。
さらにこのコマンドは,省略時の出力ファイル MONITOR.DAT にバイナリ・データを記録する。
2 番目のコマンドは,MONITOR.DAT のデータを入力データとして,入出力統計をプレイバックして表示する。
プレイバック・データの省略時の表示時間は 3 秒間だが,スクリーンには監視された入出力統計が 5 秒間ずつ表示される。
-
$ MONITOR/RECORD/NODISPLAY -
_$ /BEGINNING=08:00:00 -
_$ /ENDING=16:00:00 -
_$ /INTERVAL=120 DISK
$ MONITOR/INPUT/DISPLAY=HOURLY.LOG/INTERVAL=3600 DISK
|
このコマンドの列は,比較的短い間隔でデータを記録し,比較的長い間隔でデータをプレイバックしている。
この方法は,さまざまな時間での平均値,最小値,最大値を求めるので,長い間隔で収集したときより正確な値が必要なときに便利である。
最初のコマンドは,指定された 8 時間に 2 分間隔で,システム上のすべてのディスクの入出力動作に関するデータを記録する。
2 番目のコマンドは,1 時間ごとにデータをプレイバックして表示し,その内容を HOURLY.LOG というファイルに保存する。
このファイルを表示またはプリントすれば,データを収集した 8 時間の 1 時間ごとのディスクの累計使用量が分かる。
-
$ MONITOR/INPUT/NODISPLAY/SUMMARY=DAILY.LOG DISK
|
前の例で作成された記録ファイルを使用し,データを収集した 8 時間の平均値を示す 1 ページの要約レポート・ファイルを作成する。
要約レポートの形式は画面表示と同じになる。
次に例を示す。
OpenVMS Monitor Utility
DISK I/O STATISTICS
on node TLC From: 25-JAN-2002 08:00:00
SUMMARY To: 25-JAN-2002 16:00:00
I/O Operation Rate CUR AVE MIN MAX
DSA0: SYSTEM_0 0.53 1.50 0.40 3.88
DSA1: SYSTEM_1 0.00 0.39 0.00 8.38
DSA4: WORK_0 0.00 0.11 0.00 1.29
DSA5: WORK_1 0.03 0.87 0.00 5.95
DSA6: WORK_2 0.03 0.25 0.00 2.69
DSA7: WORK_3 0.04 0.97 0.00 20.33
DSA17: TOM_DISK 0.00 0.04 0.00 0.80
DSA23: MKC 0.00 0.00 0.00 0.13
$4$DUA0: (RABBIT) SYSTEM_0 0.20 0.65 0.17 1.97
$4$DUA2: (RABBIT) SYSTEM_0 0.20 0.65 0.17 1.97
$4$DUA3: (RABBIT) SYSTEM_1 0.00 0.14 0.00 2.49
PLAYBACK SUMMARIZING
|
6.7.7 記録した動作の遠隔プレイバック | |
適切な特権を持っていれば,DECnet によってローカル・システムに接続されている任意のシステムから MONITOR データを収集することができます。
収集中のデータは,同時にローカル・システム上に表示することができます。
その場合,次の手順に従います。
-
各遠隔システム上の省略時の DECNET ディレクトリに MONITOR.COM という名前で次のような内容のファイルを作成する。
$ !
$ ! * Enable MONITOR remote playback *
$ !
$ MONITOR /NODISPLAY/RECORD=SYS$NET ALL_CLASSES
|
-
ローカル・システム上でデータを収集したい遠隔システムの論理名を定義する。
DEFINE 遠隔ノード論理名 ノード名::タスク=モニタ
ログイン・コマンド・プロシージャの中でアクセスしたいすべてのシステムの論理名を定義することもできる。
-
遠隔システムからの MONITOR データを収集と同時に表示するためには,次の構文のコマンドを入力する。
MONITOR/INPUT=遠隔ノード論理名 クラス名
MONITOR.COM ファイルを省略時の DECNET ディレクトリ以外のディレクトリに置き,アクセス制御文字列または代理のアカウントを使用して,これらのコマンド・ファイルを遠隔呼び出しすることも可能です。
MONITOR をローカル・システムで呼び出した場合は,遠隔システム上にコマンド・ファイル MONITOR.COM を実行するプロセスが生成されます。
したがって,遠隔システムではこのプロセスに関連する CPU および DECnet のオーバヘッドが発生します。
このオーバヘッドは,MONITOR.COM ファイルの中に /INTERVAL 修飾子とクラス名のリストを加えることによって制限できます。
混在バージョンのクラスタ・システムにおいて,遠隔で監視を行う方法については6.7.10 項 「遠隔監視」で説明しています。
6.7.8 記録ファイルの更新 | |
記録ファイルの更新は,プレイバックと記録の 2 つの操作を組み合わせて行われます。
この機能を使用すると,記録ファイルのデータの量を減らすことができます。
既存の記録ファイルをプレイバックする場合は,MONITOR のすべてのオプションを利用できます。
したがって,記録されているデータから特定のクラス,時間帯,記録する間隔を選択することができます。
これらの操作により,記録されたデータの一部を削除した,サイズが小さな記録ファイルが新しく作成されます。
収集する間隔を長くするとデータの量は少なくなり,それだけ新しい記録ファイルから表示または要約されるデータの精度は低くなります。
この場合,平均の割合を示す値は影響されませんが,サンプル・データのサイズが小さいために,平均のレベルを示す値の精度は低くなります。
次の例は,記録ファイルの更新方法を示しています。
例
MONREC.COM は次のコマンドを含んでいます。
$ MONITOR/NODISPLAY/RECORD/INTERVAL=60 /BEGINNING=8:00/ENDING=16:00 DECNET,LOCK
$ MONITOR/INPUT/NODISPLAY/RECORD DECNET
|
最初のコマンドはバッチ形式で動作し,午前 8 時から午後 4 時までの間,1 分ごとに DECnet とロック管理に関する情報を記録します。
2 番目のコマンドは最初のコマンドが完了すると発行され,MONITOR.DAT ファイルの新しいバージョンを作成して DECnet に関するデータだけを再記録します。
6.7.9 MONITOR の継続実行 | |
MONITOR をバックグランド・プロセスとして継続して実行することにより,システムの性能に関する情報を記録したデータベースを構築することができます。
ここでは,クラスタ管理者として,マルチファイルのクラスタ全体の要約を作成するために使用できるプロシージャの例を示します。
このコマンド・プロシージャを自分のサイトに合うように,変更することができます。
なお,SYSTARTUP.COM に論理名 SYS$MONITOR および MON$ARCHIVE を定義してからでないと,コマンド・ファイルを実行することはできません。
論理名 SYS$EXAMPLES が指すディレクトリに,データベースの構築に利用できる 3 つのコマンド・プロシージャが含まれています。
これらのプロシージャのインストールおよび実行の方法は,各プロシージャの先頭のコメントに示されています。
表 6-10 「MONITOR のためのコマンド・プロシージャ」 で,これらのプロシージャについて簡単にまとめます。
表 6-10 MONITOR のためのコマンド・プロシージャ プロシージャ名 | 説明 |
---|
MONITOR.COM | 前回のブート時に作成された記録ファイルから要約ファイルを作成し,今回のブートの記録を開始する。
記録の間隔は 10 分。 |
MONSUM.COM | 複数のファイルから構成されるクラスタ全体の要約レポートを 2 種類作成して,システム管理者にメールする。
一方のレポートには過去 24 時間の情報が記録され,もう一方のレポートには前日のプライム・タイム (午前 9 時から午後 6 時まで) の情報が記録される。
このプロシージャは,毎日夜中に実行するように,自身をキューに再登録する。 |
SUBMON.COM | MONITOR.COM を独立プロセスとして実行する。
サイト別スタートアップ・コマンド・プロシージャから SUBMON.COM を起動する。 |
MONITOR で継続的にデータを記録しながら,特定の期間の要約レポートを作成することができます。
MONSUM.COM コマンド・プロシージャは毎晩夜中に実行され,表 6-10 「MONITOR のためのコマンド・プロシージャ」 に示す複数のファイルから構成される 2 つの要約レポートを生成し,メールします。
これらのレポートはファイルに保存されません。
内容を残すためには,メール・ファイルから情報を抽出するか,レポートを保存するように MONSUM.COM コマンド・プロシージャを変更します。
6.7.9.1 MONITOR.COM プロシージャの使用法
前回のブートで収集したデータから記録ファイルおよび要約ファイルを保存し,現在のブートのデータの連続記録を開始します。
例 6-3 「MONITOR.COM プロシージャ」のプロシージャは,記録ファイルをパージしない点に注意してください。
例 6-3 MONITOR.COM プロシージャ
|
$ SET VERIFY
$ !
$ ! MONITOR.COM
$ !
$ ! This command file is to be placed in a cluster-accessible directory
$ ! called SYS$MONITOR and submitted at system startup time as a detached
$ ! process via SUBMON.COM. For each node, MONITOR.COM creates, in
$ ! SYS$MONITOR, a MONITOR recording file that is updated throughout the
$ ! life of the boot. It also creates, in MON$ARCHIVE, a summary file from
$ ! the recording file of the previous boot, along with a copy of that
$ ! recording file. Include logical name definitions for both cluster-
$ ! accessible directories, SYS$MONITOR and MON$ARCHIVE, in SYSTARTUP.COM.
$ !
$ SET DEF SYS$MONITOR
$ SET NOON
$ PURGE MONITOR.LOG/KEEP:2
$ !
$ ! Compute executing node name and recording and summary file names
$ ! (incorporating node name and date).
$ !
$ NODE = F$GETSYI("NODENAME")
$ SEP = ""
$ IF NODE .NES. "" THEN SEP = "_"
$ DAY = F$EXTRACT (0,2,F$TIME() )
$ IF F$EXTRACT(0,1,DAY) .EQS. " " THEN DAY = F$EXTRACT(1,1,DAY)
$ MONTH = F$EXTRACT(3,3,F$TIME() )
$ ARCHFILNAM = "MON$ARCHIVE:"+NODE+SEP+"MON"+DAY+MONTH
$ RECFIL = NODE+SEP+"MON.DAT"
$ SUMFIL = ARCHFILNAM+".SUM"
$ !
$ ! Check for existence of recording file from previous boot and skip
$ ! summary if not present.
$ !
$ OPEN/READ/ERROR=NORECFIL RECORDING 'RECFIL'
$ CLOSE RECORDING
$ !
$ !
$ ! Generate summary file from previous boot.
$ !
$ MONITOR /INPUT='RECFIL' /NODISPLAY /SUMMARY='SUMFIL' -
$ ALL_CLASSES+MODE/ALL+STATES/ALL+SCS/ITEM=ALL+SYSTEM/ALL+DISK/ITEM=ALL
$ !
$ !
$ ! Compute subject string and mail summary file to cluster manager.
$ !
$ !
$ A="""
$ B=" MONITOR Summary "
$ SUB = A+NODE+B+F$TIME()+A
$ MAIL/SUBJECT='SUB' 'SUMFIL' CLUSTER_MANAGER
$ !
$ !
$ ! Archive recording file and delete it from SYS$MONITOR.
$ !
$ COPY 'RECFIL' 'ARCHFILNAM'.DAT
$ DELETE 'RECFIL';*
$ !
$ NORECFIL:
$ SET PROCESS/PRIORITY=15
$ !
$ !
$ ! Begin recording for this boot. The specified /INTERVAL value is
$ ! adequate for long-term summaries; you might need a smaller value
$ ! to get reasonable "semi-live" playback summaries (at the expense
$ ! of more disk space for the recording file).
$ !
$ MONITOR /INTERVAL=300 /NODISPLAY /RECORD='RECFIL' ALL_CLASSES
$ !
$ !
$ ! End of MONITOR.COM
$ !
|
|
6.7.9.2 SUBMON.COM プロシージャの使用法
例 6-4 「SUBMON.COM プロシージャ」 のプロシージャは,SYSTARTUP.COM から独立プロセスとして MONITOR.COM をキューに登録し,現在のブートの継続記録を開始します。
例 6-4 SUBMON.COM プロシージャ
$ SET VERIFY
$ !
$ ! SUBMON.COM
$ !
$ ! This command file is to be placed in a cluster-accessible directory
$ ! called SYS$MONITOR. At system startup time, for each node, it is
$ ! executed by SYSTARTUP.COM, following logical name definitions for
$ ! the cluster-accessible directories SYS$MONITOR and MON$ARCHIVE.
$ !
$ !
$ ! Submit detached MONITOR process to do continuous recording.
$ !
$ !
$ RUN SYS$SYSTEM:LOGINOUT.EXE -
/UIC=[1,4] -
/INPUT=SYS$MONITOR:MONITOR.COM -
/OUTPUT=SYS$MONITOR:MONITOR.LOG -
/ERROR=SYS$MONITOR:MONITOR.LOG -
/PROCESS_NAME="Monitor" -
/WORKING_SET=512 -
/MAXIMUM_WORKING_SET=512 -
/EXTENT=512/NOSWAPPING
$ !
$ !
$ ! End of SUBMON.COM
$ !
|
6.7.9.3 MONSUM.COM プロシージャの使用法
例 6-5 「MONSUM.COM プロシージャ」 のプロシージャは,毎日のプライム・タイムのクラスタの要約を作成します。
例 6-5 MONSUM.COM プロシージャ
|
$ SET VERIFY
$ !
$ ! MONSUM.COM
$ !
$ ! This command file is to be placed in a cluster-accessible directory
$ ! called SYS$MONITOR and executed at the convenience of the cluster
$ ! manager. The file generates both 24-hour and "prime time" cluster
$ ! summaries and resubmits itself to run each day at midnight.
$ !
$ SET DEF SYS$MONITOR
$ SET NOON
$ !
$ ! Compute file specification for MONSUM.COM and resubmit the file.
$ !
$ FILE = F$ENVIRONMENT("PROCEDURE")
$ FILE = F$PARSE(FILE,,,"DEVICE")+F$PARSE(FILE,,,"DIRECTORY")+F$PARSE(FILE,,,"NAME")
$ SUBMIT 'FILE' /AFTER=TOMORROW /NOPRINT
$ !
$ ! Generate 24-hour cluster summary.
$ !
$ !
$ MONITOR/INPUT=(SYS$MONITOR:*MON*.DAT;*,MON$ARCHIVE:*MON*.DAT;*) -
/NODISPLAY/SUMMARY=MONSUM.SUM -
ALL_CLASSES+DISK/ITEM=ALL+SCS/ITEM=ALL-
/BEGIN="YESTERDAY+0:0:0.00" /END="TODAY+0:0:0.00" /BY_NODE
$ !
$ !
$ ! Mail 24-hour summary file to cluster manager and delete the file from
$ ! SYS$MONITOR.
$ !
$ !
$ MAIL/SUBJECT="Daily Monitor Clusterwide Summary" MONSUM.SUM CLUSTER_MANAGER
$ DELETE MONSUM.SUM;*
$ !
$ ! Generate prime-time cluster summary.
$ !
$ !
$ MONITOR/INPUT=(SYS$MONITOR:*MON*.DAT;*,MON$ARCHIVE:*MON*.DAT;*) -
/NODISPLAY/SUMMARY=MONSUM.SUM -
ALL_CLASSES+DISK/ITEM=ALL+SCS/ITEM=ALL-
/BEGIN="YESTERDAY+9:0:0.00" /END="YESTERDAY+18:0:0.00" /BY_NODE
$ !
$ !
$ ! Mail prime-time summary file to cluster manager and delete the file
$ ! from SYS$MONITOR.
$ !
$ !
$ MAIL/SUBJECT="Prime-Time Monitor Clusterwide Summary" MONSUM.SUM CLUSTER_MANAGER
$ DELETE MONSUM.SUM;*
$ !
$ ! End of MONSUM.COM
$ !
|
|
このプロシージャの中の MAIL コマンドは,ファイルを CLUSTER_MANAGER というユーザに送信するように指定しています。
CLUSTER_MANAGER のところを実際のユーザ名または論理名に置き換えてください。
多くの場合,データは多量になるため,要約ファイルはできるだけプリントするようにします。
6.7.10 遠隔監視 | |
MONITOR は,転送メカニズムとして TCP/IP と DECnet の両方を使用できます。
OpenVMS V7.0 以降では,TCP/IP を使用するためには,SYS$STARTUP:SYSTARTUP_VMS.COM ファイルの中で次のコマンドを実行して,TCP/IP サーバを起動しておく必要があります。
$ @SYS$STARTUP:VPM$STARTUP.COM
|
DECnet は,ずっと作動し続けます。
ネットワーク・オブジェクトは,要求の時に作成されます。
混合バージョンの OpenVMS Cluster システムにおける遠隔監視 MONITOR CLUSTER コマンドを発行する,または会話型の任意の MONITOR 要求で/NODE 修飾子を指定すると,OpenVMS Cluster システム内の任意のノードを開始することができます。
OpenVMS Cluster システムでの遠隔監視は,OpenVMS のバージョンが異なるノード間では,互換性がないことがあります。
表 6-11 「OpenVMS Cluster システムでの遠隔の監視互換性」 に,遠隔監視のバージョンの互換性を示します。
表 6-11 OpenVMS Cluster システムでの遠隔の監視互換性 バージョン | OpenVMS Alpha,I64
および VAX バージョン 6.nまたは 7.n
| OpenVMS Alpha バージョン 1.5 および VAX バージョン 5.n |
---|
OpenVMS Alpha,I64,および VAX バージョン 6.n または 7.n | Yes | No |
OpenVMS Alpha バージョン 1.5 および VAX バージョン 5.n | No | Yes |
互換性のない遠隔ノードを監視しようとすると,次のメッセージが表示されます。
%MONITOR-E-SRVMISMATCH, MONITOR server on remote node is an incompatible version
|
このメッセージが表示されたら,弊社のサポート担当者に連絡し,この問題を解決するための修正キットを入手してください。
修正キットをインストールする前でも,MONITOR を使って,遠隔ノードについてのデータを得ることができます。
これを行うには,遠隔ノードについてのデータを記録してから MONITOR プレイバック機能を実行し,ローカル・ノードについてのデータを検査します。
OpenVMS Cluster システムにおいて遠隔ノードを監視する際には,もう1つの相違があります。
OpenVMS バージョン 6.2 以降では,監視できるディスク数の制限が,レコードの出力については 799 から 909 に,表示と要約の出力については 799 から 1817 に増えました。
ただし,OpenVMS バージョン 6.2 以降を実行している遠隔ノードを,OpenVMS バージョン 6.2 より前のバージョンが実行されているシステムで監視する場合は,制限値は 799 のままです。
MONITOR についての詳細は,『OpenVMS システム管理 ユーティリティ・リファレンス・マニュアル』を参照してください。
|