ここでは,システムリソースごとのパフォーマンスの監視方法およびパフォーマンスデータの収集例について説明します。
(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※ | 実際にアプリケーションが使用することができる物理メモリーのメガバイト数。 |
システムのメモリー不足は,メモリー不足が原因とは限りません。プログラムの不具合が原因で,メモリーが不足する場合もあります。プロセスごとのメモリー使用量を監視すれば,これらの原因を切り分けられます。不当にメモリーを占有していたり,メモリー使用量が増加しつづけているプロセスがある場合,そのプロセスのプログラムに不具合があると判断できます。
特定のプロセスに関するメモリー使用量を参照するには,次の表を参考にしてください。
表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 |
(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ポートのうちリッスン中のポート数。 |
#!/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
Product Name=PFM-Agent for Platform (UNIX)
FormVer=0001
tt ks lr lr lr
TCP jp1ps05 15 3 12
/opt/jp1pc/agtu/agent/jpcuser/jpcuser PI_UPIB
-file /homework/userdata.tcp
(7) PFM製品が導入されていない複数のホストからのパフォーマンスデータの収集例
PFM製品が導入されていないホスト固有のパフォーマンスデータを,PFM - Agent for Platformのユーザー作成データ収集機能を使って収集できます。また,複数のホストのパフォーマンスデータを一つのユーザーデータファイルに変換することで,同時に複数のホストの状態を監視することもできます。この場合,PFM製品が導入されていないそれぞれのホストでユーザー作成データを作成するために,シェルなどのスクリプトを準備する必要があります。ここでは,PFM製品が導入されていないホストのパフォーマンスデータを収集し,PFM - Agent for Platformのレコード情報として出力するまでの例を示します。
(a) 収集データ
ここでは「(6) 利用ポート情報の収集例」で作成したユーザー作成データを使用して情報を取得する例を示します。
(b) 前提条件
PFM製品が導入されていない複数のホストからパフォーマンスデータを収集するための前提条件を次に示します。
(c) データ収集の手順
PFM製品が導入されていないホストのデータ収集の流れを次の図に示します。
図1-5 PFM製品が導入されていないホストのデータ収集の流れ
図中の番号に従って処理の流れを説明します。複数のホストのパフォーマンスデータを収集する場合は,同様の手順をホストごとに実行してください。
#/homework/sample.sh
#cp /homework/userdata.tcp /nfshome/userdata.tcp
/opt/jp1pc/agtu/agent/jpcuser/jpcuser PI_UPIB
-file ユーザー作成データ1 -file ユーザー作成データ2 -file ユーザー作成データ3