JP1/Performance Management - Agent Option for Platform（UNIX(R)用）

1.3.2　パフォーマンス監視のしかた

ここでは，システムリソースごとのパフォーマンスの監視方法およびパフォーマンスデータの収集例について説明します。

• レコード名は，レコードIDで表記しています。フィールド名は，PFM - View名で表記しています。正式なレコード名，フィールド名については，「6.　レコード」を参照してください。
• フィールドの説明は概要だけを記載しています。フィールドの詳細な説明については，「6.　レコード」を参照してください。
• 複数のプログラムの情報をまとめて監視したい場合は，「4.2.1　ワークグループ情報の収集の設定」を参照してください。
• プロセスの稼働・非稼働情報を監視したい場合は，「4.2.2　プロセスの稼働・非稼働情報収集の設定」を参照してください。
• アプリケーションの稼働・非稼働情報を監視したい場合は，「4.2.3　アプリケーションの稼働・非稼働情報収集の設定」を参照してください。

＜この項の構成＞

(1)　プロセッサ

(2)　メモリー

(3)　ディスク

(4)　ネットワーク

(5)　プロセス

(6)　利用ポート情報の収集例

(7)　PFM製品が導入されていない複数のホストからのパフォーマンスデータの収集例

(1)　プロセッサ

プロセッサのパフォーマンスを監視する方法について説明します。

(a)　概要

プロセッサのパフォーマンス情報を監視すれば，システム全体のパフォーマンス傾向を把握できます。UNIXでは，次の概念図に示すように，カーネルによる動作とユーザーのプロセスによる動作から成ります。

図1-1　カーネルとプロセスの関係

プロセッサの利用状況は，一般的にはCPU使用率で監視できます。さらに，キュー数で監視する方法が考えられます。

プロセスなどのジョブは，OSによってスケジューリングされCPUを割り当てられて実行されます。キュー数は，CPUの割り当てられるのを待っているジョブの数です。このため，システム全体の負荷が高くなると，キュー数が増大する傾向にあります。

監視テンプレートでは，CPU Usageアラームや，CPU Status(Multi-Agent)レポートなどを提供しています。

監視テンプレートで用意されているプロセッサのパフォーマンス監視をさらに詳細に監視する場合，プロセッサごとのプロセッサ使用率，プロセスごとのプロセッサ使用率，プロセッサのキュー数，およびハードウェアからのプロセッサ割り込みなどを監視する方法が考えられます。

関連するレコードとフィールドを次の表に示します。

表1-1　プロセッサに関連する主なフィールド

使用レコード	使用フィールド	値の見方（例）
PI	1-Minute Run Queue Avg	実行キュー内で待っていたカーネル分を除くスレッド数の平均。 高い値の場合，プロセッサの利用効率に問題があるおそれがある。
	5-Minute Run Queue Avg
	15-Minute Run Queue Avg
	CPU %	CPUの使用率。高い値の場合，CPUに負荷が掛かっていることを示す。
	Idle %	CPUの未使用率。高い値の場合，CPUに負荷が掛かっていないことを示す。
PI_CPUP	CPU %	各プロセッサのCPUの使用率。
	System %	カーネルモードで実行した各プロセッサのCPU使用率。 OS，運用方法に問題があるおそれがある。
	User CPU %	ユーザーモードで実行した各プロセッサのCPU使用率。 特定のアプリケーションに問題があるおそれがある。
PD_PDI	CPU %	各プロセスのCPU使用率。 OS，運用方法，特定のアプリケーションに問題があるおそれがある。
	System CPU	カーネルモードで実行した各プロセスのCPU使用率。 OSに問題があるおそれがある。
	User CPU	ユーザーモードで実行した各プロセスのCPU使用率。 特定のアプリケーションに問題があるおそれがある。

(b)　監視方法

・カーネルCPU使用率を監視したい

システム全体のカーネルCPU使用率は，監視テンプレートで提供しているKernel CPUアラームを使用することで，監視できます。

詳細については，「1.3.3(1)(a)　監視テンプレート」を参照してください。

・ユーザーCPU使用率を監視したい

システム全体のユーザーCPU使用率は，監視テンプレートで提供しているUser CPUアラームを使用することで，監視できます。

詳細については，「1.3.3(1)(a)　監視テンプレート」を参照してください。

・プロセッサごとのCPU使用率を監視したい

プロセッサごとのCPU使用率は，特定のCPUに負荷が掛かっているなどの，OSの運用方法に問題がないかどうか監視できます。システム環境を見直し，対策を立てる目安となります。

各プロセッサの使用状況は，カーネルCPU使用率，ユーザーCPU使用率，およびプロセッサの混雑とあわせて監視すると効果的です

プロセッサごとのユーザーCPU使用率（PI_CPUPレコードのUser CPU %フィールド）が，しきい値以上の値を表示している場合，過度にCPUを使用しているプロセスを見つけ，対策を立てる目安となります。

プロセッサごとのカーネルCPU使用率（PI_CPUPレコードのSystem %フィールド）が，しきい値以上の値を表示している場合，限界を超えるシステム環境のため，プロセッサをアップグレードするか，プロセッサを追加する目安となります。

定義例については，「1.3.3(1)(b)　監視テンプレート以外の定義例」を参照してください。

・プロセッサの混雑を監視したい

プロセッサの混雑は，監視テンプレートで提供しているRun Queueアラームを使用することで，監視できます。

プロセッサの混雑（キュー数）を監視することで，プロセッサ使用率同様，プロセッサの負荷状況を監視できます。上記「プロセッサ使用率」とあわせて監視すると効果的です。

詳細については，「1.3.3(1)(a)　監視テンプレート」を参照してください。

・プロセッサ使用率が高いプロセスを確認したい

カーネルCPU使用率，ユーザーCPU使用率，プロセッサごとのCPU使用率，およびプロセッサの混雑でプロセッサがボトルネックになっているおそれがあると判断した場合，過度にプロセッサを使用しているプロセス（PD_PDIレコードCPU %フィールド）を，リアルタイムレポートで見つけます。

プロセスに問題がない場合，限界を超えるシステム環境のため，プロセッサをアップグレードするか，プロセッサを追加するなどの目安となります。

定義例については，「1.3.3(1)(b)　監視テンプレート以外の定義例」を参照してください。

(2)　メモリー

メモリーのパフォーマンスを監視する方法について説明します。

(a)　概要

メモリーを監視すれば，物理メモリーの不足を検出したり，プロセスの不正な動作を検出したりできます。

メモリーは，次の図のように物理メモリーとスワップファイルから構成されています。物理メモリーやスワップファイルが十分でないからといってメモリーが不足しているだけとは限りません。メモリーの利用効率は，ページングとページフォルトで判断可能なため，あわせて監視してください。

メモリー空間の概念を次の図に示します。

図1-2　メモリー空間を示す概念図

物理メモリーが不足している場合，システム全体のパフォーマンスの低下を招きます。

また，プログラムが参照するメモリー領域は，一定時間以上アクセスされないとスワップファイル上に退避され，必要なタイミングで物理メモリーにロードされます。このようにして，少ない物理メモリーを有効利用します。しかし，スワップファイルへのアクセス速度は物理メモリーのアクセス速度に比べて，大幅に低速です。このため，メモリー利用効率が悪くページングやページフォルトが大量に発生している場合，システム処理の大幅な遅延が発生している状態を意味します。

• ページング
  物理メモリーとページングファイルとの間で発生するコードとデータの移動を指します。ページングファイルから物理メモリーへのロードをページインと呼び，物理メモリーからページングファイルへの退避をページアウトと呼びます。
  
• ページフォルト
  物理メモリーに存在しない領域をアクセスすることを指します。
  

ページングなどは，標準的な処理でも行われています。このため，システム安定稼働時のベースラインを測定し，適切なしきい値を決定してください。

監視テンプレートでは，Available Memoryアラームを提供しています。さらに詳細な情報を参照するには，次の表を参考にしてください。

表1-2　メモリーに関連する主なフィールド

使用レコード	使用フィールド	値の見方（例）
PI	Total Physical Mem Mbytes	物理メモリーの容量。
	Free Mem Mbytes	物理メモリーの空き容量。
	Alloc Mem Mbytes	物理メモリーの使用量。
	Alloc Mem %	物理メモリーの使用率。
	Total Swap Mbytes	スワップ領域の容量。
	Free Swap Mbytes	スワップ領域の空き容量。
	Alloc Swap Mbytes	スワップ領域の使用量。継続してしきい値（PI レコードTotal Physical Mem Mbytesフィールド）以上の場合，より多くの物理メモリーが必要な可能性がある。
	Alloc Swap %	スワップ領域の使用率。継続してしきい値（システムの負荷状態で判断）以上の場合，スワップ領域の拡張が必要な可能性がある。
	Page Scans/sec	ページスキャンが発生した1秒当たりの回数。継続してしきい値（150）以上の場合，メモリーがボトルネックになっているおそれがある。
	Swapped-Out Pages/sec	スワップアウト処理によってページが取り出された1秒当たりのページ数。継続してしきい値（200）以上の場合，メモリーがボトルネックになっているおそれがある。
	Buffers Mem %※	ファイルバッファに使用している物理メモリーのメガバイト数の割合。
	Buffers Mem Mbytes※	ファイルバッファに使用している物理メモリーのメガバイト数。
	Cache Mem %※	キャッシュメモリーとして使用している物理メモリーのメガバイト数の割合。
	Cache Mem Mbytes※	キャッシュメモリーとして使用している物理メモリーのメガバイト数。
	Effective Free Mem %※	実際にアプリケーションが使用することができる物理メモリーのメガバイト数の割合。
	Effective Free Mem Mbytes※	実際にアプリケーションが使用することができる物理メモリーのメガバイト数。

注※

PFM - Agent for Platformのバージョンが08-11以降で，監視対象OSがLinuxの場合だけ使用できます。

システムのメモリー不足は，メモリー不足が原因とは限りません。プログラムの不具合が原因で，メモリーが不足する場合もあります。プロセスごとのメモリー使用量を監視すれば，これらの原因を切り分けられます。不当にメモリーを占有していたり，メモリー使用量が増加しつづけているプロセスがある場合，そのプロセスのプログラムに不具合があると判断できます。

特定のプロセスに関するメモリー使用量を参照するには，次の表を参考にしてください。

表1-3　プロセスごとのメモリーに関連する主なフィールド

使用レコード	使用フィールド	値の見方（例）
PD_PDI	Real Mem Kbytes	各プロセスが使用している物理メモリーの使用量。 特定のプロセスがメモリーを大量に使用しているおそれがある。
	Virtual Mem Kbytes	各プロセスが使用している仮想メモリーの使用量。特定のプロセスがメモリーを大量に使用しているおそれがある。
	Swaps	各プロセスでスワップが発生した回数。プロセスのスワッピングからボトルネックを発生させているプロセスを洗い出す必要がある。

(b)　監視項目

・メモリーの使用状況を監視したい

仮想メモリーの使用状況は，メモリーの増設が必要かどうかの目安となります。

メモリーの使用状況が一時的に高い場合でも，継続的な高負荷状態ではないときは，パフォーマンスの低下を許容できる可能性があるため，ページスキャン数，スワップアウト処理とあわせて監視すると効果的です。

使用している仮想メモリー使用量（PIレコード Alloc Swap Mbytesフィールド）が，物理メモリー総量（PIレコード Total Physical Mem Mbytesフィールド）以上の場合，より多くのメモリーが必要な可能性があります。

定義例については，「1.3.3(2)(b)　監視テンプレート以外の定義例」を参照してください。

・ページスキャン数を監視したい

ページスキャン数（PIレコードPage Scans/secフィールド）は，監視テンプレートで提供しているPagescansアラームで監視できます。

スワップアウト処理，メモリー使用状況とあわせて監視すると効果的です。

過度にページスキャンしているプロセスを見つけ，対策を立ててください。プロセスに問題がない場合，限界を超えるシステム環境のため，メモリーを増設するなどの対策の目安となります。

詳細については，「1.3.3(2)(a)　監視テンプレート」を参照してください。

・スワップアウト処理を監視したい

スワップアウト処理（PIレコードSwapped-Out Pages/secフィールド）は，監視テンプレートで提供しているSwap Outsアラームで監視できます。

ページスキャン数，メモリー使用状況とあわせて監視すると効果的です。

過度にスワッピングしているプロセスを見つけ，対策を立ててください。プロセスに問題がない場合，限界を超えるシステム環境のため，メモリーを増設するなどの対策の目安となります。

詳細については，「1.3.3(2)(a)　監視テンプレート」を参照してください。

・プロセスのメモリー使用量を監視したい

メモリーの使用状況，ページスキャン数，およびスワップアウト処理で問題があると判断した場合，原因となるプロセスを特定してください。

サーバの活動状況が増加していない状態で，各プロセスのメモリー使用量（PD_PDIレコードReal Mem Kbytesなど）をリアルタイムレポートで数分〜数十分程度監視します。表示されている折れ線グラフで，増加しつづけているプロセスがないか確認します。

メモリーリークを発生させている，または過度にスワッピングしているプロセスを特定し，製造元に問い合わせるなどの対策の目安となります。

定義例については，「1.3.3(2)(b)　監視テンプレート以外の定義例」を参照してください。

・実際にシステムで使用できるメモリー量が知りたい（Linux限定）

Linuxは，可能な限りメモリーに一度取得した情報を保持します。そのため，PIレコードのFree Mem Mbytesフィールドで空きメモリー量を監視すると，徐々に値が「0」に近くなります。しかし，実際にそれらのメモリーはいつでも解放でき，アプリケーションの使用を妨げるものではありません。PFM - Agent for Platform 08-11以降では，この「いつでも解放できるメモリー量」をPIレコードのBuffers Mem MbytesフィールドおよびCache Mem Mbytesフィールドで監視できます。これらの値から「総合的な使用可能メモリー量」を計算し，出力しているのがPIレコードのEffective Free Mem Mbytesフィールドです。この値を参照することで，システムの使用可能なメモリー量を確認できます。

(3)　ディスク

ディスクのパフォーマンスを監視する方法について説明します。

(a)　概要

ディスクを監視すれば，ディスク資源の不足などを検出したり，ディスクによるボトルネックを把握したりできます。また，継続的にディスクを監視すれば，ディスク容量の使用量の増加傾向を把握し，システム構成決定や拡張するなどのタイミングを把握できます。

ディスクはプログラムやプログラムが参照するデータなどを保存しています。このため，ディスク容量が不足してくると，データが消失するなどの問題が発生するだけでなく，システムの応答速度が低下します。

プログラムからディスクのデータを入出力する場合，実行中に休止（応答を待っている）状態になることがあります。これは，ディスクがボトルネックになり始めていることを示します。

ディスクのボトルネックが原因で，プロセスの応答速度の低下などさまざまな性能劣化を引き起こす場合があります。そのため，ディスクに関連する性能劣化が発生していないことを確認するのは重要な作業です。

ディスクのI/O回数を監視する場合，次の点に注意してください。

PFM - Agent for Platformで取得しているのはOSがディスクデバイスから取得したI/Oの情報です。実際のディスクに対するI/Oに対する情報ではありません。アプリケーションからディスクへのI/O処理概念図を次に示します。

図1-3　I/O処理概念図

ディスクのI/O負荷に関する監視項目としては，Avg Service TimeフィールドとBusy %フィールドがあります。

Avg Service Timeフィールドは，1回のI/Oに掛かった平均時間を示します。非常に大きなサイズのI/Oが発生した場合やI/Oが遅くなっている場合に，この値は大きくなります。

Busy %フィールドは，収集間隔中にディスクデバイスが稼働していた時間の割合を示します。I/Oが集中している場合に，この値は大きくなります。

このように，Avg Service TimeフィールドおよびBusy %フィールドはディスクデバイスの負荷に関連する情報です。そのため，監視の要件に合わせてフィールドを選択するようにしてください。

Avg Service TimeフィールドとBusy %フィールドの関連を次の図に示します。

図1-4　Avg Service TimeとBusy %の考え方

監視テンプレートでは，Disk Spaceアラームを提供しています。さらに情報を参照するには，次の表を参考にしてください。

表1-4　ディスクに関連する主なフィールド

使用レコード	使用フィールド	値の見方（例）
PI_DEVD	Avg Service Time	I/Oの平均動作時間。非常に大きなサイズのI/Oが発生しているおそれがある。
	Avg Wait Time	I/Oの平均待ち時間。非常に大きなサイズのI/Oが発生しているおそれがある。
	Busy %	ディスクのビジー率。I/Oが特定のディスクに集中しているおそれがある。
	I/O Mbytes	I/Oの合計転送サイズ。非常に大きなサイズのI/Oが発生しているおそれがある。
	Total I/O Ops	I/Oが発生した回数。I/Oが特定のディスクに集中しているおそれがある。
	Queue Length	キューの長さ。継続してしきい値以上の場合，デバイスの混雑を示している。
PD_FSL	Mbytes Free	ファイルシステムの未使用領域。未使用領域が少ない場合，ディスク容量が不足している。
	Mbytes Free %
PD_FSR	Mbytes Free
	Mbytes Free %

・ディスクの空き容量を監視したい

ディスクの空き容量は，監視テンプレートで提供しているFile System Free(L)アラームまたはFile System Free(R)アラームを使用することで，監視できます。

論理ディスクの空き領域をアラームで監視するとディスクの容量不足を効果的に監視できます。

論理ディスクの空き領域（PD_FSLまたはPD_FSRレコードMbytes FreeまたはMbytes Free %フィールド）がしきい値以下になった場合，不要ファイルの削除やディスク増設など，対策の目安となります。

詳細については，「1.3.3(3)(a)　監視テンプレート」を参照してください。

・ディスクのI/O遅延を監視したい

ディスクのI/O遅延は，監視テンプレートで提供しているI/O Wait Timeアラームを使用することで，監視できます。

ディスクのI/O遅延（PIレコードWait %フィールド）は，データベースの更新など過度にI/Oを発生させているプロセスが存在していないかなど，対策の目安となります。

詳細については，「1.3.3(3)(a)　監視テンプレート」を参照してください。

・ディスクのI/Oを監視したい

ディスクのI/Oは，監視テンプレートで提供しているDisk Service Timeアラームを使用することで，監視できます。

ディスクのI/O（PI_DEVDレコードAvg Service Timeフィールド）は，非常に大きなサイズのI/Oを発生させているプロセスが存在していないかなど，対策の目安となります。

詳細については，「1.3.3(3)(a)　監視テンプレート」を参照してください。

・ディスクのビジー率を監視したい

ディスクのビジー率は，監視テンプレートで提供しているDisk Busy %アラームを使用することで，監視できます。

ディスクのビジー率は，過度なページング（プロセスによるページの読み取り，または書き込み）が発生していないかをアラームで監視できます。

ディスクのビジー率（PI_DEVDレコードBusy %フィールド）が，継続的にしきい値以上の場合，ディスク要求を発生させているプロセスを調べ，プロセスの分散処理をするなど，対策の目安となります。

ディスクのI/O遅延，ディスクのI/O，およびディスクの混雑とあわせて監視すると効果的です。

詳細については，「1.3.3(3)(a)　監視テンプレート」を参照してください。

・ディスクの混雑を監視したい

ディスクの混雑は，監視テンプレートで提供しているDisk Queueアラームを使用することで，監視できます。

ディスクの混雑は，過度なI/O要求が発生していないかをアラームで監視できます。

ディスクの混雑（PI_DEVDレコードQueue Lengthフィールド）が，継続的にしきい値以上の場合，ディスク要求を発生させているプロセスを調べ，プロセスの分散処理をするなど，対策の目安となります。

ディスクのI/O遅延，ディスクのI/O，ディスクのビジー率とあわせて監視すると効果的です。

詳細については，「1.3.3(3)(a)　監視テンプレート」を参照してください。

(4)　ネットワーク

ネットワークのパフォーマンスを監視する方法について説明します。

(a)　概要

ネットワークの情報を監視すれば，システムが提供している機能の応答速度の状況を確認できます。

ネットワークのデータの送受信量などを継続的に監視すれば，ネットワーク構成の決定や拡張などを計画的に行えます。

関連するレコードとフィールドを次の表に示します。

表1-5　ネットワークに関連する主なフィールド

使用レコード	使用フィールド	値の見方（例）
PI_NIND	Pkts Rcvd/sec	受信した1秒当たりのパケット数。高い値の場合，多量のパケット受信に成功したこと示す。
PI_NINS
PI_NIND	Pkts Xmitd/sec	送信した1秒当たりのパケット数。高い値の場合，多量のパケット送信に成功したこと示す。
PI_NINS
PI_NIND	Max Transmission Unit	最大パケットサイズ。MTUを自動で割り当てる環境で，高い値（1,500以上）の場合，データ受け渡しに再分割する処理が発生し，小さい値（1,500以下）の場合，制御信号とブロック数が増え，ネットワークのボトルネックになるおそれがある。

(b)　監視項目

・ネットワークインターフェースカードに帯域幅（一定時間内に転送できるデータの量）を超えるデータ受信がないか監視したい

ネットワークインターフェースカードの帯域幅は，監視テンプレートで提供しているNetwork Rcvd/secアラームを使用することで，監視できます。

ネットワークインターフェースカードの帯域幅をアラームで監視すると，ネットワークの送受信パケット数を監視できます。

パケット数が継続的にしきい値以上の場合，ネットワークインターフェースカードまたは物理ネットワークをアップグレードする判断材料となることがあります。

詳細については，「1.3.3(4)(a)　監視テンプレート」を参照してください。

(5)　プロセス

プロセスのパフォーマンスを監視する方法について説明します。

(a)　概要

システムは，個々のプロセスによって提供されています。このため，プロセスの稼働状況を把握するのは，システムの安定運用に欠かせません。

システムの機能を提供するプロセスが異常終了した場合，運用システムが停止し重大な影響が発生します。このため，プロセスの生成，消滅，および起動状況を監視し，早急に異常を検知し対策を立ててください。

PFM - Agent for Platformでは，収集のタイミングでプロセスを監視しています。このため，プロセスの存在確認をしている場合でも，プロセスが消滅したタイミングではなく，PFM - Agent for Platformが情報を収集したタイミングでプロセスの消滅したことを検知することに注意してください。

プロセスを監視するためのレコードとフィールドを次の表に示します。

表1-6　プロセスに関連する主なフィールド

使用レコード	使用フィールド	値の見方（例）
PI_WGRP	Process Count	プロセス数。しきい値（起動している必要があるプロセス数）以下の場合，プロセスが停止していることを示す。※
PD_PDI	Program	プロセス名。レコード収集されない場合，プロセスが停止していることを示す。
PD_APS	Program Name	プロセス名。レコード収集されない場合，プロセスが停止していることを示す。
PD_APP， PD_APP2	Application Name	アプリケーション定義名。
	Application Exist	アプリケーションの状態。NORMALの場合，各監視対象のうちどれかの状態がNORMALの状態であることを示す。ABNORMALの場合，各監視対象の状態がすべてABNORMALの状態であることを示す。
	Application Status	アプリケーションの状態。NORMALの場合，各監視対象の状態がすべてNORMALの状態であることを示す。ABNORMALの場合，各監視対象のうちどれかの状態がABNORMALであることを示す。
PD_APPD	Application Name	監視数の条件結果。Monitoring Statusフィールドの値がABNORMALの場合，プログラムまたはコマンドラインのうち，どちらかの起動数が指定範囲外であることを示す。
	Monitoring Label
	Monitoring Status

注※

/opt/jp1pc/agtu/agent/wgfileファイルで設定してください。

(b)　監視項目

・プロセスの消滅を監視したい

プロセスの消滅は，監視テンプレートで提供しているProcess Endアラームを使用することで，監視できます。

プロセスが異常終了した場合，運用システムが停止し重大な影響が発生します。早急に復旧させるために，プロセスの消滅をアラームで監視できます。

詳細については，「1.3.3(5)(a)　監視テンプレート」を参照してください。

・プロセスの生成を監視したい

プロセスの生成は，監視テンプレートで提供しているProcess Aliveアラームを使用することで，監視できます。

プロセスの生成は，アプリケーション単位やスケジュールされたプロセスの状況など，運用システムが正しく動作しているかどうかをアラームで監視できます。

wgfileファイルでワークグループを設定し，PI_WGRPレコードを使用することで，プロセスの生成や消滅，同一名称のプロセス数，アプリケーション単位のプロセス数，およびユーザーごとのプロセス起動数などさまざまな監視を行えます。

詳細については，「1.3.3(5)(a)　監視テンプレート」を参照してください。

(6)　利用ポート情報の収集例

PFM - Agent for Platformでは，ユーザーがテキストファイルに出力した独自のパフォーマンスデータ（ユーザー作成データ）を，PFM - Agent for Platformが提供するレコードに格納できる形式（ユーザーデータファイル）に変換する機能を提供しています。ユーザー独自のパフォーマンスデータの詳細については，「4.2.4　ユーザー独自のパフォーマンスデータ収集の設定」を参照してください。

ここでは，ユーザー独自のパフォーマンスデータとして利用ポート情報をPI_UPIBレコードに収集する例を示します。利用ポート情報は，次の表に示す形式で格納するものとします。

表1-7　ユーザー作成データのフォーマット

オプション	値
tt	"TCP"。
ks	ホスト名。
lr	ホストが持つTCPポートの総数。
lr	ホストが持つTCPポートのうち現在アクティブなポート数。
lr	ホストが持つTCPポートのうちリッスン中のポート数。

1. 利用ポート情報を収集するためのシェルスクリプトを作成する。
   この例では，利用ポート情報を収集するためにシェルスクリプトを利用します。シェルスクリプトの作成例を次に示します。
   

   Linuxでのシェルスクリプトの作成例（/homework/sample.sh）

   #!/bin/sh
   echo "Product Name=PFM-Agent for Platform (UNIX)" > /homework/userdata.tcp
   echo "FormVer=0001" >> /homework/userdata.tcp
   echo "tt ks lr lr lr" >> /homework/userdata.tcp
   #All TCP port
   ALL_TCP=`netstat -at | wc -l`
   ALL_TCP=`expr $ALL_TCP - 2`
   #Active TCP port
   ACTIVE_TCP=`netstat -at | grep ESTABLISHED | wc -l`
   #Listen TCP port
   LISTEN_TCP=`netstat -at | grep LISTEN | wc -l`
   #Output
   echo "TCP `uname -n` $ALL_TCP $ACTIVE_TCP $LISTEN_TCP" >> /homework/userdata.tcp

   注意

   ここで紹介するシェルスクリプトはLinuxでの作成例のため，ほかのOSでは正しく動作しないおそれがあります。また，環境によってはLinux上でも動作しないことがあるため注意してください。

2. 手順1で作成したシェルスクリプトを実行する。
   シェルスクリプトの実行結果として作成されるユーザー作成データを次に示します。
   

   ユーザー作成データ（/homework/userdata.tcp）

   Product Name=PFM-Agent for Platform (UNIX)
   FormVer=0001
   tt ks lr lr lr
   TCP jp1ps05 15 3 12

3. 手順2で作成されたユーザー作成データをユーザーデータファイルへ変換する。
   ユーザー作成データをユーザーデータファイルへ変換するコマンド（jpcuserコマンド）の実行例を次に示します。
   

   jpcuserコマンドの実行例

   /opt/jp1pc/agtu/agent/jpcuser/jpcuser PI_UPIB 
   -file /homework/userdata.tcp

4. 手順3で出力されたユーザーデータファイルをPFM - Agent for Platformで収集する。
   PFM - Agent for Platformがレコードを収集するタイミングで，ユーザーデータファイルの内容がユーザーレコードに格納されます。
   

(7)　PFM製品が導入されていない複数のホストからのパフォーマンスデータの収集例

PFM製品が導入されていないホスト固有のパフォーマンスデータを，PFM - Agent for Platformのユーザー作成データ収集機能を使って収集できます。また，複数のホストのパフォーマンスデータを一つのユーザーデータファイルに変換することで，同時に複数のホストの状態を監視することもできます。この場合，PFM製品が導入されていないそれぞれのホストでユーザー作成データを作成するために，シェルなどのスクリプトを準備する必要があります。ここでは，PFM製品が導入されていないホストのパフォーマンスデータを収集し，PFM - Agent for Platformのレコード情報として出力するまでの例を示します。

(a)　収集データ

ここでは「(6)　利用ポート情報の収集例」で作成したユーザー作成データを使用して情報を取得する例を示します。

(b)　前提条件

PFM製品が導入されていない複数のホストからパフォーマンスデータを収集するための前提条件を次に示します。

• PFM製品が導入されているホストとPFM製品が導入されていないホストの間で信頼関係が結ばれており，ファイルのやり取りが可能な環境である（ホスト間でNFSによる共有領域が設定されている）。
• PFM製品が導入されているホストのPFM - Agent for Platformのバージョンが08-11以降である。

(c)　データ収集の手順

PFM製品が導入されていないホストのデータ収集の流れを次の図に示します。

図1-5　PFM製品が導入されていないホストのデータ収集の流れ

図中の番号に従って処理の流れを説明します。複数のホストのパフォーマンスデータを収集する場合は，同様の手順をホストごとに実行してください。

1. PFM製品が導入されていないホストでユーザー作成データを作成する。
   パフォーマンスデータを収集するスクリプトを実行して，ユーザー作成データを作成します。ここでは「(6)　利用ポート情報の収集例」で作成したユーザー作成データを使用します。
   
2. リモートホスト間でファイルをコピーする。
   手順1で作成したユーザー作成データを，PFM製品が導入されているホストにコピーします。ここではNFSによってホスト間で共有されている領域「/nfshome/」にユーザー作成データをコピーします。cpコマンドの例を次に示します。
   

   cpコマンドの例

   #/homework/sample.sh
   #cp /homework/userdata.tcp /nfshome/userdata.tcp

   注意

   複数のホストのユーザー作成データを収集する場合は，ファイル名が重複しないようにしてください。ファイル名が重複している場合，ファイルをコピーするときに上書きするおそれがあります。

3. PFM製品が導入されているホストでjpcuserコマンドを実行する。
   PFM製品が導入されているホストでjpcuserコマンドを実行して，手順2でコピーしたユーザー作成データをユーザーデータファイルに変換します。手順1および2を実行したPFM未導入ホストのユーザー作成データを，一つのユーザーデータファイルに変換する例を次に示します。
   

   jpcuserコマンドの例

   /opt/jp1pc/agtu/agent/jpcuser/jpcuser PI_UPIB 
   -file ユーザー作成データ1 -file ユーザー作成データ2 -file ユーザー作成データ3

4. PFM製品が導入されているホストでレコードデータを収集する。
   手順3で出力されたユーザーデータファイルの内容を，PFM製品が導入されているホストでレコードデータとして収集します。
   

[目次][前へ][次へ]

All Rights Reserved. Copyright (C) 2009, 2012, Hitachi, Ltd.