プロセス単位でのCPU使用率やメモリ使用率は採取(確認)できません。
しかし、メモリ使用量(テキスト、データ、およびスタック・スペースを含むプロセスのコア・イメージの物理ページ単位の大きさ) はプロセス情報表示画面に表示することが可能です。

可能です。SS_perfdata2csv コマンドを使用します。
[記述形式]
HP-UX： /opt/SS/bin/PerfCenter/SS_perfdata2csv
[-f mmddHHMM[yy]] [-t mmddHHMM[yy]]
[-d [CPU][MEM][SWAP][DISK][FS][PROC][PACKET]]
[-r] agentname

Windows： <SysMgrMG_Engine_HOME>¥SYSMANAGER¥BIN¥PerfCenter¥SS_perfdata2csv.exe
[-f mmddHHMM[yy]] [-t mmddHHMM[yy]]
[-d [CPU][MEM][SWAP][DISK][FS][PROC][PACKET]]
[-r] agentname

未知メッセージの抑止機能は2語以上の語から構成されるメッセージに対して有効です。
" 一致率(＝rate)"として指定した値が有効なのは、4語以上からなるメッセージに対してです。
2語、3語からなるメッセージについては、"一語対象外(＝oneword)"として指定した値により動作が変わります。

同一メッセージ抑止機能の正規表現ファイル(msgctl.regex または、control.regex)に、UNIXエージェントの場合「 .* 」、Windowsエージェントの場合「 * 」とだけ記述すれば、全てのメッセージが抑止対象になります。

この場合、単位時間当たりに発生したメッセージは、最初の一つ以外全て抑止されてしまい、同一メッセージ抑止・類似メッセージ抑止ではなく、マネージャ-エージェント間の流量制限のような利用になってしまいます。
このような運用は推奨いたしません。

この定義をすることで、ログファイル監視及び、syslog/イベントログ監視が、抑止処理により、負荷が高くなることはありません。
また、同一メッセージ抑止設定ファイル(msgctl.conf または、control.conf)で、「同一メッセージ抑止機能を使用する」指定をし、正規表現ファイルを配置しないケース、あるいは、正規表現ファイルに何も定義しないケースや、抑止したい同一メッセージを一つずつ記述したケースよりも、抑止処理としての負荷は高くなりません。

イベントID振り分け機能では、一つのIDに対して複数の条件を指定することが可能です。一つの条件で＆条件を定義することはできませんが

の二つの条件を記載していただくことで、"Aがある場合は出力。Bがある場合も出力"が可能です。

また、"A、Bがある場合は出力させたくない"、とありますが A、Bの両方が含まれたメッセージのみ削除フィルタに定義しておくことで、可能です。

AとBの間に何か他の文字列が含まれる場合は
A.*B (UNIXの場合)、 A*B (Windowsの場合)
のように定義することで、設定可能です。AとBの順序が不定の場合は、逆の条件も必要です。

UNIXのSyslog監視では、リアルタイムにsyslogメッセージを取得し、マネージャに通知するため、監視間隔の設定はありません。
また、Windowsのイベントログ監視では、リアルタイムにイベントログデータを取得/編集し、マネージャに通知するため、監視間隔の設定はありません。

しきい値チェックは、性能データ採取間隔ごとに行います。例えば、性能データ採取間隔を10分とした場合、10分おきにしきい値チェックを行い、そのタイミングでアラートが発生します。

しきい値チェックする対象データは、性能データ採取間隔の平均値(データによっては、累積値(パケット数)および瞬間値(瞬間プロセス数)があります。)となります。性能データ採取間隔を10分とした場合、10分間の平均値がしきい値を超過していた場合に、アラートが発生します。

SystemManagerVer3.0以降では性能しきい値の2段階監視機能が実装され、2段階での監視が可能になりました。

抽出フィルタ、削除フィルタともに複数の定義が可能です。
プログラムとしては、定義数の上限を設けておりませんが、エージェント上の監視プロセスが利用するメモリリソースが許す限り、設定可能になります。

ただ、当然ながらフィルタ定義が多くなる程、処理性能は低くなるので、バランスは考慮する必要があります。
実績ベースでは、80個程度のフィルタ定義であれば、問題なく動作しています。
なお、フィルタリング処理の流れとしては、以下のようになります。

ネットワーク機器のsyslogを直接は取り扱えません。
他サーバが出力したsyslogをエージェントマシンに送る方法を使えば、メッセージを監視(検出)できます。
ただし、送信元エージェントは、中継をした(マネージャにsyslogメッセージを送信した)エージェントマシンとなります。

UNIXエージェントでは、SCSI接続のディスクに限れば外付けでも監視可能です。
Windowsエージェントでは、ディスクの性能監視は行えません。

ディスクの障害を検出することはできません。
ディスク障害については、OSから、UNIXエージェントの場合はsyslogへ、Windowsエージェントの場合はイベントログへの通知が想定されます。Syslog、イベントログ監視機能を提供していますので、ディスクの障害通知がsyslog、イベントログに出力されれば要件を満たすことが可能です。

NICが複数存在する場合は、合計値を算出して監視及び表示します。
また、Ver3.2 以降ではNIC毎の性能監視をサポートしています。

なお、このサポートは、エージェント側のみで、コンソールのシステムツリー表示で、エージェントのネットワークには、個々のNICの情報は表示されません。

アラートメッセージ中に「超過した値」と「しきい値として指定された値」が含まれます。
また、その値は実際の使用サイズ等でなく、しきい値チェック用に算出された値となります。
例えば、メモリの場合、以下の様なメッセージとなり実際に使用されているメモリのサイズでなく、使用率となります。

(補足)

HPマネージャではVer2.1以前、WindowsマネージャではVer2.2以前は、アラートメッセージ中にこれらの値は含まれておりません。

性能情報監視メッセージについては、同一メッセージを抑止することはできません。

性能情報は、エージェントに蓄積しています。
性能データ1レコードあたりのディスク使用量は、以下の算出式で求めることができます。

上記で求めた1レコードあたりのディスク使用量に、蓄積件数を掛けて全体の容量を求めてください。
ただし、最大蓄積件数(初期状態では1000件)を超えて情報は蓄積されません。

はい。可能です。
“ [ “ および ” ] ” は正規表現において特別な意味を持ちます。
このような定義を行いたい場合は、フィルタ定義には、
ccc： ¥[
と記述してください。
詳しくは、オンラインマニュアル（regex(3g)、regcmp(3g)）をご覧ください。

Windowsの場合は正規表現を使いませんので、*ccc： [* と記述してください。

マネージャ側に設定ファイルを準備し、そのファイルをエージェントに配布・適用する機能(エージェント設定ファイル適用機能)を用いることで、マネージャからエージェント側に設定を反映させることが可能です。エージェント側での操作は不要です。

エージェント自身のプロセスの停止を通知することはできません。エージェント側の常駐プロセスとして以下があります。

このうち、SSAOd(NadmAOd)については、停止したタイミングで以下のメッセージの出力がありますが、意図的に停止したものか何らかの要因（例えばcoredump）なのかは判断がつきません。
メッセージ：
エージェントがシャットダウンにより停止しました。

物理メモリに関する値です。

全CPU使用率の平均値を対象にします。
また、Ver3.2以降は、CPU毎のしきい値監視もサポートしています。
しきい値監視定義ファイル(Thred)で、CPU単位でしきい値の設定ができ、監視契機で、CPU毎に取得したCPU使用率と、指定されたCPUのしきい値とから、しきい値監視の判定を行います。CPU毎のしきい値監視の設定については、SystemManagerのマニュアル「SystemManager利用の手引き」の「性能情報のしきい値設定」を 参照してください。

以下の資料を参照してください。
Ver3.0以降のマニュアルには追記しております。

アラートを受信したとき、任意のコマンドを実行できます。
メール転送やパトライト稼動等を行いたい場合は、これらを行うコマンドを登録していただければ可能となります。アラートを受信したとき、実行する任意のコマンドについては以下の点をご注意ください。

サマリツリーは表示時点までに一度でもクリックして情報を見たエージェントの情報だけを表示する機能です。
ですので、サマリ化したいエージェントをクリックしてからサマリツリーを表示をお願いします。

オンラインバックアップはできません。
SystemManagerでは状態を複数のファイルに保存しているため、バックアップのタイミングによっては、リストア時にデータの整合性が保てなくなり、正常に起動できなくなる可能性があります。
バックアップは、停止状態で行ってください。

先に定義した定義が優先されます。

ある特定の文字については、正しく表示されない可能性があります。以下の資料を参照してください。

現状は、CLUSTERPROのみ対応しています。

LinuxAGの場合、ログファイル監視などに使用できる正規表現について、()を表現する場合、¥のエスケープ文字は不要。その他のUNIXのOSでは()を表現する場合、¥が必要です。
Windowsは正規表現は使えません。

以下のようにコマンド設定をしてください。
AdminToolのコマンド設定ダイアログのアラートタイプの欄は、
<SystemManagerのインストールディレクトリ>¥FrameworkManager¥trapdef¥ 配下のDefファイルに定義されているアラートタイプ を表示しています。

SystemManagerのインストールディレクトリ は、デフォルトでは、
C:¥Program Files¥NEC¥SystemManager¥BackEnd¥
です。 (クラスタの場合は、共有ディスク上になります)

ですので、あらかじめ通知してくるアラートタイプをDefファイル内で以下の例のように定義しておいてください。(以下のように新規に別名のDefファイル作成を推奨します)

<>Defファイル内のEnterprise、GenericCode、SpecificCode は既にあるDefファイルの内容と重複しないようにお願いします。定義後、SystemManagerを再起動し、AdminToolよりコマンド設定を行ってください。

例：アラートタイプがSNMPの場合。
------------ tmp.def ------------
#ServerAgent Dummy1
Enterprise: 1.1.1.1.1.1.1.1.1
GenericCode: 6
SpecificCode: 1
Summary:
Logging: 1
Severity: 2
AlertType: SNMP
ESMKind:
Detail:
------------ tmp.def ここまで ------------

監視設定を除外した監視設定ファイルを再度適用してください。

エージェント停止による影響は、以下の通りとなります。

SystemManagerのsyslog監視としては、発行時のプライオリティについての分解能がありません。

ファシリティやプライオリティに応じて重要度を変更したい場合は、監視が必要なメッセージのプライオリティ、キーワードを抽出していただき、それらのメッセージに対してイベントID振り分け機能を用いて重要度定義をしていただく運用をお願いいたします。

イベントID振り分け機能についてはマニュアルの「イベントID振り分け機能」をご参照ください。

情報採取ツールでは下記の処理をしています。
後述の【注意】を除き、SystemManager自身やシステム全体に影響を及ぼすような処理はしていません。

ログファイル監視において、既に監視対象になっているログのイベントIDを変更する運用はサポートしていません。

監視対象になっているログのイベントIDを変更したい場合は、一旦該当ログを監視対象から外した定義を適用し、その後イベントIDを変更した定義を適用してください。

できません。
定義ファイル(FaltLogSG)に同じ監視ファイルの監視定義を2つ以上記載しても、同じメッセージを2回は出さない仕様になっています。
SystemManagerでは、同じログファイルに対し異なるIDや重要度で通知を行いたい場合、「イベントID振り分け機能」の利用を推奨しています。

フィルタ定義によるメッセージ抑止機能は利用できませんが、それぞれ以下の運用方法で一部のアラートを抑止することが可能です。

プロセス監視機能：

連続する同一の異常通知アラートを抑止する機能があります。
詳細は、SystemManagerのマニュアル「SystemManager利用の手引き」の「プロセス監視正常復帰アラート」をご参照ください。

しきい値モニタ監視機能：

アラート通知を連続通知する/しないの設定や連続○回しきい値を越えたら通知する、などの設定がございます。
詳細は、SystemManagerのマニュアル「SystemManager利用の手引き」の「しきい値モニタ監視」をご参照ください。

性能情報の蓄積では期間指定による管理はしておりません。
最大蓄積件数のみの管理となります。蓄積できるおよその期間は、性能蓄積設定画面の[予測データ蓄積期間]より確認できます。

メッセージ抑止機能など、該当機能の使用有無を定義ファイルに設定可能なものに関しては、使用有無を設定するパラメータに "OFF(false)" を定義したファイルを適用してください。
上記以外の機能については、空の定義ファイルを適用してください。

はい。可能です。
「性能情報収集の設定」画面で性能情報の採取を一旦OFFとしてください。
ただし、この場合、監視間隔等の設定値はデフォルトに戻りますので、ONにする際に再度設定をお願いします。

SG適用時、SGが適用されたことを示すアラートは通知されますが、その後、任意のタイミングで確認する方法はありません。お客様ご自身で、適用SG・適用マシンの情報を管理してください。

エージェントのアンインストールで、マネージャ側のエージェント情報が正しく削除されなかった可能性がありますので、以下の方法をお試しください。

一定回数を超えたら同一メッセージを抑止する、という設定方法はできません。

猶予回数の判定は、監視間隔ごとに一度行われます。監視間隔は、「性能情報収集の設定」ダイアログの「採取間隔」で設定できます。

SystemManagerのログ監視フィルタでは、以下のOSの正規表現を利用してパターンマッチングを行っております。

UNIXエージェントおよびLinuxエージェントの正規表現の特殊文字については、regcmp(3g)、regex(3g)等のオンラインマニュアルをご参照ください。
Windowsエージェントについては、特殊文字は \ と * だけとなっております。
¥ は、直後に ¥ か * が存在した場合のみエスケープシーケンスとして働きます。

設定情報はファイルで管理しておりますが、直接編集して不正な内容が記述される等を防ぐため、保管場所は公開しておりません。 恐れ入りますがご理解をお願いします。

SystemManager Ver3.2以前では、内部で一時的に構築するイベントログの構築メッセージが 2048 バイトを超える場合、質問されたメッセージを通知する仕様となります。
Ver3.3以降では、内部で一時的に構築するメッセージが大きくなっても、イベントログ監視メッセージを正しく構築する様に変更しており、 上記のメッセージは通知されません。

SystemManagerでは監視対象ファイルが破損している(open、read等が不可能な)場合に、その監視対象ファイルに対しては一切監視を行えません。また、ファイルが読み込めない状態であることを示すイベント等は通知しません。

ログ監視機能の監視開始時刻を指定することはできません。

構成情報については、AGの再起動後にGUIからインベントリ情報の採取を行ったタイミングで認識します。また性能情報については、OSが増設CPUを認識後、最初の性能情報取得タイミングで認識します。

Network Node Manager 7.50以降で、Exeteded TopologyのOAD(OverlappingAddressDomain)の設定をしている場合、OPBASEやMCOへアラートが通知されない可能性があります。OADの設定をする場合は、SystemManager メッセージ変換オプションの設定をしてください。SystemManager メッセージ変換オプションの設定は、「SystemManager メッセージ変換オプション」のマニュアルを参照してください。

Unixのエージェント(HP-UX、Linux、Solaris、AIX)では、watchtabでの指定は正規表現であるため、部分一致、完全一致のいずれにも対応可能です。
例えば

というプロセスがある状態で、watchtabに"ABC"と指定した場合、ABCとABCDEの両方が監視対象となります。 "^ABC$"と指定した場合はABCのみが監視対象になります。

Windowsのエージェントでは、watchtabでの指定は正規表現ではありません。
その代りワイルドカード"*"をサポートしているため、部分一致、完全一致のいずれにも対応可能です。
例えば

というプロセスがある状態で、watchtabに"ABC"と指定した場合、ABCのみが監視対象になります。 "ABC*"と指定した場合はABCとABCDEの両方が監視対象となります。

文字コードがSJIS、EUC であれば可能です。ただし、共有ディスク上にイベントID振り分けの定義ファイルを置く場合、文字コードはEUCで記述してください。

はい。起動条件に一致するコマンドは全て起動されます。

監視対象のログファイルには、監視可能なサイズの上限があります。
UNIX-AGの場合は、2G バイト 未満です。
WinAGの場合、4G バイト 未満です。

監視中に、監視対象のログファイルが、監視可能なサイズの上限を超えてしまった場合、以下の影響があります。
エージェントのバージョンにより仕様が異なりますので、それぞれについて記載します。

■UNIX-AGがVer3.3.24未満、WinAGがVer3.3.28未満
監視中に、監視可能なサイズの上限を超えた場合、以降ログが出力されていても、ログファイル監視メッセージは通知されなくなります。
なお、監視可能なサイズの上限を超えた場合でも、マネージャには何のメッセージも通知しません。

■UNIX-AGがVer3.3.24以降、WinAGがVer3.3.28以降
監視中に、監視可能なサイズの上限を超えた場合、以降ログが出力されていても、ログファイル監視メッセージは通知されなくなります。
ただし、その上限を超えた場合の処理について以下の改善を行っております。

性能蓄積件数を10000件から5000件に減らす場合、古いほうの5000件が削除されます。3000件が蓄積されている場合は、削除後も参照可能です。

正常に動作しない場合がありますので、"Flog.xxxxx"のファイル名でご利用ください。
"Flog"以外のファイル名でフィルタを適用している場合、後から"Flog"のフィルタを適用したときにイベントIDが重複してしまいフィルタが無効となる可能性があります。

万が一"Flog"以外のファイル名でフィルタを適用していた場合、以下の手順で正しいファイル名のフィルタを適用してください。

1つのマネージャあたり、接続されるエージェントは 100台を推奨します。
100台を超えるエージェントも接続自体は可能ですが、接続するエージェントが増えるたびにマネージャのリソースに負荷がかかるため、お客様で動作確認の上ご使用をお願いします。(開発側の動作確認は100台まで行っています。)

ディスク毎に取得したディスクアクセス率(性能情報採取間隔の平均値)の中で最大の値が、しきい値の判定に用いられます。

それぞれのコマンドの仕様は以下の通りです。

■dup_ssbsbkup.sh

バックアップ対象：

SystemManager自身のデータをバックアップします。

バックアップ方式：

バックアップデータは1世代です。
実際にはバックアップデータは2つ作成されますが、2つとも同じバックアップデータ(片方はファイル破損などの為の予備)となります。

リストア方式：

1世代管理なので、前回のバックアップデータをリストアします。
/var/opt/SS/share/backup1が破損していた場合は、backup2を使用します。

以下の文字は使用できないため、使用しないでください。
& , < , > , " , '

以下の文字は使用できないため、使用しないでください。
& , < , > , " , '

UNIX 系 OS の場合
ネットワーク上のドライブをマウントし、OS がローカルのディスクと同様に認識することができれば、監視可能です。ただし、ネットワークドライブがアンマウントされている間は監視できないことに留意してください。

Windows 系 OS の場合
ネットワークドライブとして接続したドライブや、subst コマンドで関連付けたドライブの監視は行えません。

■接続処理について
エージェントでは、マネージャとのコネクションの切断を検知した場合、1分間隔で再接続を試みます。
したがって、マネージャが起動された時点やネットワークが復旧した時点で、SystemManagerのエージェント－マネージャ間のコネクションも自動的に復旧します。

■アラートに関して
SystemManagerでは、マネージャの停止やネットワーク障害等でマネージャとエージェントのコネクションが確立されていない間のアラートを、エージェント上に保留する機能があります。
エージェントで発生したアラートの内、マネージャに通知出来なかったものについては、保留上限に設定された件数までエージェント上に保存します。
(デフォルトでは保留件数の上限は200件です。この数値は変更可能です。)
エージェントに保存したアラートは、エージェント-マネージャ間のコネクションが回復した時点で再度マネージャへ送信します。

なお、保留件数の上限を超えた分のアラートについては、エージェント上から破棄する為、エージェント-マネージャ間のコネクションが回復した後もマネージャへは通知せず、破棄した件数のみを通知します。

保留件数の上限を変更する場合は、エージェント上で以下の操作を行ってください。

現在の保留件数の上限について確認したい場合は、エージェント上にある上記の設定ファイルを直接ご参照ください。

■性能情報の参照について
コンソールから閲覧できる現在性能情報については、マネージャ－エージェント間のコネクションが確立されていない間は参照できません。
性能情報の蓄積が行われている場合、性能情報はエージェント上に保存されておりますので、マネージャとコネクションが確立されていない状態でもデータの欠落は発生しません。