10.2.1. システム全般のQ&A

ここでは、千手システムを使用する際の基本的な疑問に対するQ&Aについてまとめています。使用前に一読して下さい。

  1. 管理対象ノードの情報、ジョブスケジュール等の各種データを登録後に通常のユーザーがこれらを更新／削除できないようにできますか？

    可能です。千手ドメインにログインするユーザー毎に6段階の権限を設定することが可能です。(詳細は、 千手システムのユーザーアカウント を参照して下さい。)

  2. Senju DevOperation Conductorの稼働するサーバーのIPアドレスを変更したいのですが、Senju DevOperation Conductorの再インストールは必要でしょうか？

    いいえ。必要ありません。

    • 運用管理サーバー(千手マネージャ)のIPアドレスを変更する場合

      運用管理サーバーの hosts ファイルに記述のIPアドレスを変更して下さい。変更後、千手ブラウザから[反映(ノード定義)] を行って下さい。さらに、管理対象ノードおよび千手ブラウザの hosts ファイルに記述の運用管理サーバーに関するIPアドレスを変更して下さい。

    • 管理対象ノード(千手エージェント)のIPアドレスを変更する場合

      管理対象ノードの hosts ファイルに記述のIPアドレスを変更して下さい。さらに、運用管理サーバーの hosts ファイル中の管理対象ノードに関するIPアドレスを変更して下さい。変更後、千手ブラウザから [反映(ノード定義)] を行って下さい。

    • 千手センサーのIPアドレスを変更する場合

      プローブノードの hosts ファイル中の千手センサーに関するIPアドレスを変更して下さい。 変更後、IPアドレスを変更した千手センサーを監視対象ノードとした監視タスクの一時停止及び再開を行って下さい

    参考

    上記手順の詳細、及びその他のノードについては、 リリースノート を参照して下さい。

  3. Senju DevOperation Conductorの稼働するサーバーのホスト名を変更したいのですが、Senju DevOperation Conductorの再インストールは必要でしょうか？

    いいえ。必要ありません。

    • 運用管理サーバー(千手マネージャ)のホスト名を変更する場合

      ホスト名(千手ドメイン名)を変更する場合、ライセンスキーの再発行が必要になります。なお、ホスト名(千手ドメイン名)は変更せず、マシンのホスト名(実ホスト名)を変更する場合、ライセンスキーの再発行は必要ありません。

    • 管理対象ノード(千手エージェント)のホスト名を変更する場合

      ホスト名(ノードID)を変更する場合、該当ノードが所属する運用管理サーバーや該当ノードで使用している機能の設定も変更する必要があります。ホスト名(ノードID)は変更せず、マシンのホスト名(実ホスト名)を変更する場合もそれに応じた作業が必要になります。

    参考

    上記手順の詳細、及びその他のノードについては、 リリースノート を参照して下さい。

  4. Senju DevOperation Conductorの環境変数を変更することによって千手システムの挙動を変化させたいのですが、可能でしょうか？

    Senju DevOperation Conductorの環境変数は出荷時に正常に稼働する状態に調整されております。Senju DevOperation Conductorの環境変数をユーザーで変更された場合、千手システムの正常稼働を保証できなくなります。万が一、ユーザーで非公開環境変数の変更を行われた場合は、千手システムの通常サポートの範囲外となりますのでご注意下さい。

  5. 運用管理サーバーに接続できるコンソールの数はいくつですか？

    1台の運用管理サーバーに同時に接続できる千手ブラウザの数は最大7つまでです。また、1つの千手ブラウザから同時に接続できる運用管理サーバーはデフォルト3台(最大5台)までです。

  6. マシンタイム(日付、時刻)を変更したいのですが注意点はありますか？

    マシンタイム(日付、時刻)を大きく変更すると、システムが正常に機能しなくなる場合があります。そのため、マシンタイム(日付、時刻)を変更される際は、 リリースノート に記載されている時刻変更時の手順を実施して頂けますようお願いいたします。

  7. Unix/Linux版千手システムにて、リモートコマンド実行コマンドで文字コード指定でUTF8を指定して実行しましたが、コマンド出力結果が正しく表示されませんでした。どのようなことが原因として考えられますか？

    以下の原因が考えられます。

    • 必要なコードテーブルがインストールされていない。 Unix/Linux版千手システムにて、文字コード指定でUTF8が指定されている場合、OSのシステム関数であるiconv関数を用いて文字コードの変換を行います。

      iconv関数では、コードテーブルを使用しますが、必要なコードテーブルがインストールされていない可能性があります。その場合は、文字コード変換に失敗します。

      使用するコードテーブルを、以下の表に記します。

      OS(千手の文字コード)

      変換に必要なコードテーブル

      HP-UX(Shift_JIS)

      sjis、utf8

      Solaris(EUC)

      eucJP、utf8

      Solaris(Shift_JIS)

      PCK、utf8

      AIX(Shift_JIS)

      IBM-932、UTF-8

      Linux(EUC)

      EUC-JP-MS、UTF-8

      iconvコマンドで、実際に文字コードを変換することにより、コード変換ができるかを確認することができます。以下のコマンド実行により、コマンドが失敗する場合は、コードテーブルを別途インストールする必要があります。コードテーブルのインストールについては、ベンダーにお問い合わせ下さい。

      • iconvコマンドの使用法

      iconv -f (変換前のコードテーブル名) -t(変換後のコードテーブル名) (変換対象ファイル名) > (変換後ファイル名)

      (実行例：HP-UX(Shift_JIS)にて、Shift_JISのテキストファイルbefore_sjis.txtを、UTF-8に変換し、after_utf8.txtとして保存する)

      % iconv -f sjis -t utf8 before_sjis.txt > after_utf8.txt
  8. ランブックオートメーションや、モニタリング、コンフィグレーション等で、アプライアンス機器にてコマンド実行する場合や、情報取得する際にtelnet接続を用いる場合、注意するべき点はありますか？

    telnet接続でコマンド実行する場合、接続先のアプライアンス機器にてshのシェルが使用可能である必要があります。

10.2.2. イベントのQ&A

ここでは、イベントサブシステムを使用する際の基本的な疑問に対するQ&Aについてまとめています。使用前に一読して下さい。

  1. メッセージアクションの同一のルールグループ内にて、同じ内容のルールで日付によって切り替わるようなルールを作成する場合は、どうすればよいでしょうか？

    1つのルールグループ内に、同名のルールIDを定義することはできません。同じ内容のルールで有効期間が異なる定義を作る場合は、「[名前].YYYYMMDD」のようにルールIDが別名になるようにし、有効期間をそれぞれのルールに指定して下さい。

  2. メッセージアクションのルールの条件設定で通常(I)レベルを条件として設定しましたがルールが適用されません。どうすればよいでしょうか？

    通常、メッセージアクションの全般設定のメッセージルールの適用条件は[障害メッセージのみルールを適用する]が設定されているため、障害メッセージのみルールが適用されます。通常メッセージにルールを適用させる場合は、メッセージアクションの全般設定のメッセージルールの適用条件で[フィルタを通過したメッセージのみルールを適用する]を選択して下さい。

  3. メッセージアクション機能を一時的に停止したいのですが、どうすればよいでしょうか？

    メッセージアクションの機能を停止するにはルールグループの定義をすべて削除する必要があります。データの書き出しにより、変更前のデータを保存してから定義の削除を行って下さい。

  4. メッセージモニタに<重複>と表示されアクションが実行されませんでした。どうすればよいでしょうか？

    通常、メッセージアクションの全般設定で同一ルールでの連続したメッセージアクションを抑止するために、重複メッセージ判定が設定されています。重複メッセージと判定された場合、アクションは実行されません。ただし、重複メッセージでも実行するアクションを設定することで、重複メッセージと判定されてもアクションを実行することが可能です。

  5. 対応種別振り分けを追加することは可能でしょうか？

    可能です。必要に応じてパラメータの「対応種別」に追加して下さい。パラメータの登録方法は パラメータ を参照して下さい。

  6. UNIX/Linux版の管理対象ノードにて、コマンド実行結果ファイルの保存方式でUTF-8／Unicodeを指定して実行しましたが、コマンド実行結果ファイルが正しく保存されませんでした。どのようなことが原因として考えられますか？

    UNIX/Linux版の管理対象ノードにて、コマンド実行結果ファイルの保存方式でUTF-8やUnicode(UTF-16LE)に指定されている場合、OSのシステム関数であるiconv関数を用いて文字コードの変換を行います。 iconv関数では、コードテーブルを使用しますが、必要なコードテーブルがインストールされていない可能性があります。その場合は、文字コード変換に失敗します。

    使用するコードテーブルを、以下の表に記します。

    OS(千手の文字コード)

    変換に必要なコードテーブル

    HP-UX(Shift_JIS)

    sjis、utf8

    Solaris(EUC)

    eucJP、utf8

    Solaris(Shift_JIS)

    PCK、utf8

    AIX(Shift_JIS)

    IBM-932、UTF-8

    Linux(EUC)

    EUC-JP-MS、UTF-8

    iconvコマンドで、実際に文字コードを変換することにより、コード変換ができるかを確認することができます。以下のコマンド実行により、コマンドが失敗する場合は、コードテーブルを別途インストールする必要があります。コードテーブルのインストールについては、ベンダーにお問い合わせ下さい。

    • iconvコマンドの使用法

      iconv -f (変換前のコードテーブル名) -t(変換後のコードテーブル名) (変換対象ファイル名) > (変換後ファイル名)

      (実行例：HP-UX(Shift_JIS)にて、Shift_JISのテキストファイルbefore_sjis.txtを、UTF-8に変換し、after_utf8.txtとして保存する)

      % iconv -f sjis -t utf8 before_sjis.txt > after_utf8.txt
  7. セクションが終了コード143で異常終了しました。なぜでしょうか？

    終了コード143はsjRBA_rexdが起動しているcshが子プロセスの終了を検知して終了した際の終了コードになります。終了コード143はcshが起動したプロセスがシグナルを受けて終了したことを表しています。

  8. ランブックチェッカからブックのチェックを行い正常終了だったセクションが異常終了となりました。なぜでしょうか？

    ランブックチェッカでは稼働のノードのチェックは行われません。そのため、登録されていないノードが指定されていたり、ノードが指定されていない場合でも、セクションは正常終了となります。

  9. セクションテンプレートの定義を変更しました。このセクションテンプレートを使用している既存のブックに変更は反映されますか？また、変更した内容が有効になるのはいつからですか？

    既に作成済みのブック及び実行ブックへは、変更内容は反映されません。次回ブック作成時から、変更内容が反映されます。

  10. 同じ名称の、定義有効日が異なる連絡先グループ、およびブックがあり、それぞれの有効期間が重複している部分がある場合、どの連絡先グループ／ブック定義が有効になりますか？

    同一名称で、複数の定義が存在する場合、定義有効日が一番新しい定義が、常に有効になります。

  11. 同じセクションを、1ブック内に複数個定義することはできますか？

    できません。チャプターが異なれば、同じセクションをそれぞれに(1つずつ)定義することができます。

  12. 同一ブック内に、同一チャプターを複数個定義することはできますか？

    できません。異なるブックには定義が可能です。

  13. 起動待ちのセクションが残っているのに、実行ブックが正常終了となりました。なぜでしょうか？

    分岐条件に当てはまらなかったセクションとその後続セクションは起動待ちのままとなります。分岐条件に当てはまったセクションとその後続セクションが正常終了している場合、実行ブックは正常終了となります。

  14. ブックには定義有効終了日の設定ができませんが、指定の日付からブックを無効にするような設定は可能でしょうか？

    指定の日付からブックを無効にしたい場合は、無効にしたいブックと同名のブックを作成し、定義有効日にブックを無効にする日付を指定し、有効/無効を無効に設定してください。

  15. ブックやセクションの環境変数にアルファベットの大文字小文字のみ異なる環境変数名を指定することはできますか？

    セクションの稼働ノードにWindowsノードを指定する場合は、環境変数名のアルファベットの大文字小文字が区別されません。アルファベットの大文字小文字のみ異なる環境変数名の環境変数を指定した場合、どちらか片方の値しか有効にならないため、同一ブック内でアルファベットの大文字小文字のみ異なる環境変数名は使用しないで下さい。

  16. セクションに指定した起動コマンドが、指定されたパスに存在しない場合や実行権限が無い場合はどのようなメッセージが出力されますか？

    セクションの稼働ノードのOSによって出力されるメッセージが異なります。Windowsの場合は、 !RBA007 のメッセージ「セクション状況通知 [起動エラー]」と、 !RBA006 のメッセージ「セクション状況通知 [異常終了]」が出力されます。UNIX/Linuxの場合は、 ! RBA006 のメッセージ「セクション状況通知[異常終了]」のみが出力されます。

  17. 千手ウェブサービス稼働ノードで、!DCM854メッセージが出力され、メッセージ履歴データファイルの格納が失敗した場合の対応方法を教えて下さい。

    !DCM854 のメッセージ内容からメッセージ履歴データファイルを確認します。ファイルサイズ超過の場合は、一つの履歴データファイルが 5MBを超えないようにファイル分割をして下さい。分割は、1行の途中で切らないように注意して下さい。

    千手ウェブサービス稼働ノードで、分割したファイルをメッセージ履歴データ登録コマンド(sj_dbstore_msg.exe)で千手データベースに格納します。

    (実行例)
    sj_dbstore_msg.exe -f %SENJUHOME%\SjPcc_Msg_Fail_XXXXXXXX_20120114_200600_1.log

    注釈

    • 格納に失敗したファイルは、 %SENJUHOME%\log\SjPcc_Msg_Fail_ で始まるファイル名になります。

    • 格納に成功した場合は、指定したファイルは削除されます。

  18. 千手ウェブサービス稼働ノードで、送信元が sj_dbstore_ope の !DCM854メッセージが出力されました。どのようなことが原因として考えられますか？

    前日のWebコンソールへのログインの際に、ユーザー名の欄にタブが含まれている場合、このメッセージが出力されます。

    Webコンソールでログインする場合は、ユーザー名の欄にタブを入力しないようにしてください。

10.2.3. モニタリングのQ&A

ここでは、モニタリングサブシステムを使用する際の基本的な疑問に対するQ&Aについてまとめています。使用前に一読して下さい。

10.2.3.1. モニタリング全般のQ&A

  1. システム情報の監視を行っていますが、CPU使用率、仮想メモリ使用率、稼働プロセス数はどの時点で取得した値ですか？

    CPU使用率、仮想メモリ使用率、稼働プロセス数を取得するタイミングは、起動時間から検査間隔毎に値を取得します。

    • 仮想メモリ使用率、稼働プロセス数

      ある時点での瞬間的な値であって、一定時間帯での平均値ではありません

    • CPU使用率

      指定した検査間隔期間内の平均値です。ただし、SNMP(Host Resources MIB)による取得の場合、CPU使用率は検査間隔内の平均値ではなく、直前の一分間の平均値となります。

  2. 千手ブラウザのノードモニタの[プロセス]タブの千手起動プロセスフィールドにおいて、未起動のプロセスを選択し、プロセスを起動させたところ画面上に「成功しました」と表示されました。しかし、[最新の情報に更新]を選択するとこのプロセスが異常終了の状態になりました。

    起動したプロセスの実行モジュールが管理対象ノードに存在していないか、あるいはプロセスに実行権がない場合が考えられます。本機能は管理対象ノードの遠隔起動を要求する機能です。

    「成功しました」のメッセージはこの起動の要求に成功したことを意味しており、実際にプロセスが起動したかどうかはノードモニタの[プロセス]タブにおいて[最新の情報に更新]を選択して確認して下さい。

  3. 千手ブラウザの「ノードグループ」→「ノード」のプロパティのディスクタブにおいて、ある管理対象ノードのディスク使用量監視のしきい値を変更しました。この後、グローバルノードモニタではディスクの異常は表示されていないのに、ノードモニタでは指定しきい値以下のディスク使用量をもつディスクが異常となり赤く表示されました。どのような原因が考えられますか？

    千手システムでは、グローバルノードモニタに表示するデータをまとめて送信しているため、最大で2分間画面が更新されません。そのため、グローバルノードモニタとノードモニタで値の差が生じる場合があります。

  4. シェルスクリプトや javaプログラムなど、プロセス名だけでは実際のプログラムが判断できないようなプロセスの監視を行うことは可能ですか？

    UNIX/ Linux 版監視対象ノード上においては、シェルスクリプト名や javaのクラス名や、その引数をパラメータとして指定することにより監視可能です。例えば、実行中のシェルスクリプトは ps コマンドでは以下のように出力されます。

    /bin/csh /home/bremen/bin/AAAsystem.csh -a abc

    /bin/csh /home/aqua/bin/BBBcheck.csh 300

    プロセス監視のパラメータとして /bin/csh を指定すると、上記の2スクリプトはどちらも先頭の /bin/csh に一致するため、監視対象として扱われることになります。
    詳細情報カテゴリのプロセス別CPU使用率/メモリ使用量および同一プロセス名稼働数の監視において、 BBBcheck.csh 300 と指定すると、 BBBcheck.csh 300 に部分一致する後者のシェルスクリプトのみが監視対象となります。
    プロセスカテゴリのプロセス別CPU使用率/メモリ使用量および同一プロセス名稼働数の監視においては、パラメータとして指定したプロセス名とパスを除いた先頭一致となっているため、 csh /home/aqua/bin/BBBcheck.csh 300 と指定する必要があります。
    なお、Windows版監視対象ノードにおいては、パラメータとして指定したプロセス名での完全一致(大小文字は区別しない、拡張子は見ないで比較)となっているため、このような監視は行うことはできません。
  5. 状況によってプロセス数が変化するプロセス(Apacheなど)を監視すると、プロセスが終了する度に異常と報告されます。プロセスが1つでも残っていれば、異常と報告されないようにする監視方法はありますか？

    二つの方法を利用することが可能です。状況に応じてご選択下さい。

    • 「同一プロセス名稼働数」監視を使用する方法

      親子関係が無くバラバラに起動されるようなプロセスに対して有効です。稼働しているプロセス数を指定して、正常/異常を判断します。

    • 詳細情報の親プロセスのみを監視する監視項目を使用する方法

      UNIX/Linux版監視対象ノード上の親子関係のあるプロセス(psで親プロセスIDが1(init プロセス) では無いプロセスは子プロセス)が対象になります。initプロセスになっている親プロセスが消えない限り正常に監視を行うことが可能です。

  6. ホームページは正常に表示できますが、Apache関連の監視の結果、状態が常に「異常」と表示されています。どのような原因が考えられますか？

    監視するApacheサーバーのmod_statusモジュールが使用できない設定になっている可能性があります。監視できる設定であるかを確認する方法を以下に記します。

    • Webブラウザにて、URLに[http://(監視対象Apacheサーバー)/(情報取得ページ)/server-statusauto]を指定します。

      例) http://www.nridata.co.jp/server-statusauto

    • 上記の結果Webブラウザに全アクセス数等の情報が表示されることを確認します。情報が表示されなかった場合、mod-statusモジュールを使用できるように設定して下さい。

      参考

      詳細は、 セットアップガイド の カスタマイズ／オプション機能の設定 を参照して下さい。

  7. 設定した検査間隔以内に監視結果が取得できなかった場合は、どうなるのでしょうか？

    WMI監視項目、コマンドによる監視項目、JMX監視項目は、検査間隔内に監視結果が取得できなかった場合、検査間隔経過後WMI、コマンド、JMXの情報取得を取り止めます。コマンドによる監視項目の場合は該当プロセスを強制終了させます。検査間隔以内に監視結果が取得できなかった場合、ノードモニタには状態は「－」で値は空欄で表示されます。この場合のみ、検査間隔経過後ではなく1分後に再度情報取得を開始します。SNMP監視項目は、検査間隔以内に監視結果が取得できなかった場合でも情報取得を取り止めてはいません。これは、監視タスク登録時に指定されたタイムアウトおよびリトライ回数のほうを優先しているためです。そのため、検査間隔を超える監視条件の場合、実際に監視を行う間隔が指定された検査間隔より長くなります。

  8. SNMP監視機能を使っていますが、一部の千手エージェントおよび千手センサーで異常な値を取得します。どうしてでしょうか？

    Senju DevOperation ConductorのSNMP監視機能では、監視対象ノードのSNMPエージェントが返してくる値をもとに計算処理を行っているため、正しい値が取得できているかどうかはSNMPエージェントの実装に依存しています。詳細は実装ベンダーに確認願います。

  9. SNMP監視を行っていますが、エラーメッセージに「通信タイムアウト」、「SNMP応答エラー」などと出力されます。この状態を回避するためにはどうすればよいでしょうか？

    SNMPエージェントが稼働している状況でこのような状態になった場合は、監視タスクに指定されているOIDが監視タスクに指定されている条件(ノードID、SNMPバージョン、SNMPコミュニティ名)で取得可能か、監視対象ノードのSNMPエージェントで、指定したSNMPバージョン・SNMPコミュニティ名が実装されているかをご確認下さい。取得方法の例を以下に示します。

    • Linux等のsnmpgetコマンドを用いて取得する方法

      snmpget -v SNMPバージョン -c SNMPコミュニティ ノードID OID

      (実行例)

      % snmpget -v 2c localhost -c public system.sysUpTime.0
system.sysUpTime.0 = Timeticks: (49847533) 5 days, 18:27:55.33
    • AIX の snmpinfo コマンドを用いて取得する方法

      snmpinfo -m get -c SNMPコミュニティ -h ノードID OID

      % su root -c snmpinfo -m get -c public -h localhost 1.3.6.1.2.1.1.3.0
root's Password:
1.3.6.1.2.1.1.3.0 = 437699708
  10. プロセス一覧の表示がOSによって異なりますが、Senju DevOperation Conductorではどのような方法で一覧を取得しているのでしょうか？

    Senju DevOperation Conductorではプロセス一覧を取得する際にUNIX/Linux版はpsコマンドを用いております。各OS毎のpsコマンドのオプションは以下のとおりです。

    • Solaris: /usr/bin/ps -eo pid,ppid,vsz,time,args

    • AIX: /usr/bin/ps -eo pid,ppid,vsz,cputime,args

    • HP-UX: ps -eo pid,ppid,vsz,time,args

    • Linux: /bin/ps -ewwo pid,ppid,vsz,bsdtime,args

    postgresプロセスを例にするとHP-UXでは以下のように表示されます。

    % ps -ef | grep post
senju 12997 12996  0 Aug  6  ?    0:00 postgres: stats buffer process...
senju 12998 12997  0 Aug  6  ?    0:04 postgres: stats collector process
senju 12996 00001  0 Aug  6  ?    0:10 /home/senju/psql/bin/postmaster..

    solarisでは以下のように表示されます。

    % ps -ef | grep post
senju   408   407  0   Aug 08 ?        0:01 /export/home/senju/psql/bin/postmaster
senju   406   ..1  0   Aug 08 ?        0:03 /export/home/senju/psql/bin/postmaster
senju   407   406  0   Aug 08 ?        0:00 /export/home/senju/psql/bin/postmaster
  11. モニタリングの監視タスクを登録したときに、メッセージモニタに表示されるメッセージの内容に含まれる "通常" 、 "通常2" などは何を意味しているのでしょうか？

    メッセージモニタの内容に含まれる文字列は、計算結果の比較方法の略称です。略称がメッセージに含まれる文言となります。

    略称

    比較方法

    内容

    通常

    通常

    計算結果と判定条件の値を判定方法に従って比較し状態を判定します。

    通常2

    通常(無くなった監視対象を異常とする)

    計算結果と判定条件の値を判定方法に従って比較し状態を判定します。計算結果が前回は存在したが、今回存在しなくなった場合は状態を異常と判定します。

    絶対値

    絶対値

    計算結果の絶対値と判定条件の値を判定方法に従って比較し状態を判定します。

    差分1

    前回との差分(新たな監視対象を正常とする)

    差分の値(前回の計算結果と今回の計算結果の差分)と判定条件の値を判定方法に従って比較し状態を判定します。前回の計算結果が存在しない場合は状態を正常と判定します。

    差分2

    前回との差分(新たな監視対象を異常とする)

    差分の値(前回の計算結果と今回の計算結果の差分)と判定条件の値を判定方法に従って比較し状態を判定します。前回の計算結果が存在しない場合は状態を異常と判定します。

    初回差分1

    初回との差分(新たな監視対象を正常とする)

    差分の値(初回の計算結果と今回の計算結果の差分)と判定条件の値を判定方法に従って比較し状態を判定します。初回の計算結果が存在しない場合は状態を正常と判定します。

    初回差分2

    初回との差分(新たな監視対象を異常とする)

    差分の値(初回の計算結果と今回の計算結果の差分)と判定条件の値を判定方法に従って比較し状態を判定します。初回の計算結果が存在しない場合は状態を異常と判定します。

    常に正常

    常に正常

    判定せずに常に状態を正常と判定します。

    合計

    合計

    全ての監視対象の計算結果の合計と判定条件の値を判定方法に従って比較し状態を判定します。
  12. 1つのプローブノードからWebLogic ServerおよびJBoss Application Serverを同時に監視することはできますか？

    このような監視を行うことはできません。WebLogic ServerおよびJBoss Application Serverを同時に監視する場合は、それぞれに対して1つずつプローブノードを用意して下さい。なお、監視時には、プローブノードに監視対象のAPサーバーと同じJava実行環境を設定し、その設定をAPサーバー監視用設定コマンドで登録しておく必要があります。

    参考

    詳細につきましては、 セットアップガイド の カスタマイズ／オプション機能の設定 を参照して下さい。

  13. 1つのプローブノードからWebLogic Serverの異なるバージョンまたはJBoss Application Serverの異なるバージョンを同時に監視することはできますか？

    このような監視を行うことはできません。WebLogic Serverの異なるバージョンまたはJBoss Application Serverの異なるバージョンを同時に監視する場合は、それぞれに対して1つずつプローブノードを用意して下さい。なお、監視時には、プローブノードに監視対象のAPサーバーと同じJava実行環境を設定し、その設定をAPサーバー監視用設定コマンドで登録しておく必要があります。

    参考

    詳細につきましては、 セットアップガイド の カスタマイズ／オプション機能の設定 を参照して下さい。

  14. APサーバー監視の監視タスクが一時停止してしまいます。どのような原因が考えられますか？

    APサーバー監視の監視タスクが一時停止してしまう原因としては、プローブノードで設定されているAPサーバー種別とは異なるAPサーバーの監視を行う監視タスクを登録されたことが考えられます。1つのプローブノードでWebLogic ServerおよびJBoss Application Serverを同時に監視することはできません。このため、APサーバー監視の監視タスクを登録する際に異なるプローブノードを指定するか、もしくは該当プローブノードにおいてAPサーバー監視用設定コマンドを実行し、監視を行うAPサーバー種別を変更する必要があります。

    参考

    詳細につきましては、 セットアップガイド の カスタマイズ／オプション機能の設定 を参照して下さい。

  15. 千手マネージャ/千手エージェントにて、APサーバー監視のデーモンプロセスsjANM_monJmxdが異常終了してしまいます。どのような原因が考えられますか？

    APサーバー監視のデーモンプロセスsjANM_monJmxdが異常終了してしまう原因としては、以下のような設定漏れが考えられます。

    • 該当千手マネージャ/千手エージェントにてAPサーバー監視用設定コマンドでの設定が正しく行われていない。

    • 必要なjarファイルがコピーされていない。

    OSによっては、上記設定がされていないとsjANM_monJmxdがcore dumpにより異常終了することがあります。

    参考

    詳細につきましては、 セットアップガイド の カスタマイズ／オプション機能の設定 を参照して下さい。

  16. APサーバー監視の監視タスクで値が取得できません。どのような原因が考えられますか？

    APサーバー監視の監視タスクで値が取得できない原因としては、以下のような設定漏れが考えられます。

    • 監視対象のAPサーバーが正常に稼働していない。

    • APサーバーで、情報取得が出来るように設定されていない。

    • 監視対象のAPサーバーがWebLogic Serverの場合に t3 以外、監視対象のAPサーバーがJBoss Application Serverの場合に jnp 以外のプロトコルを指定している。

    • 必要なjarファイルがコピーされていない。

    • 監視対象のAPサーバーとは異なるバージョンのAPサーバーのjarファイルがコピーされている。

    参考

    詳細につきましては、 セットアップガイド の カスタマイズ／オプション機能の設定 を参照して下さい。

  17. APサーバー監視の監視タスクを登録後メッセージモニタにメッセージの付加文言にConnection Error(null)というメッセージが表示されて監視が正常に行えません。

    APサーバー監視で設定したjarファイルがAPサーバーで稼働しているjarファイルと異なるバージョンであることが考えられます。

    参考

    詳細につきましては、 セットアップガイド の カスタマイズ／オプション機能の設定 を参照して下さい。

  18. AP サーバー監視で指定するパラメータに入力すべき値を確認する方法はありますか？

    各APサーバーが提供している Web コンソールや専用コンソールから確認可能です。

    • WebLogic監視
      • ポート番号

        Webコンソールの左ペインツリーにて、 ドメイン名 －「サーバー」－ 管理サーバー名 を選択し、右ペインにて、「コンフィギュレーション」－「一般」を選択し、「リスンポート」の内容を確認

        WebLogic Server 10.3.4では、WebLogicServer管理コンソールのドメイン・ツリーにおける表示位置が変更されたため、以下となります。

        Webコンソールの左ペインツリーにて、 ドメイン名 －「サービス」－「データ・ソース」－ JDBCデータソースのサマリー の内容を確認

      • 管理対象サーバー名

        Webコンソールの左ペインツリーにて、 ドメイン名 －「サーバー」－ 管理サーバー名 の内容を確認

      • JDBC接続プール名

        Webコンソールの左ペインツリーにて、 ドメイン名 －「サービス」－「JDBC」－ JDBC接続プール名 の内容を確認

      • Webアプリケーション名

        Webコンソールの左ペインツリーにて、 ドメイン名 －「デプロイメント」－「アプリケーション」－ エンタープライズ・アプリケーション名 － Webアプリケーション名 の内容を確認

        または、Webコンソールの左ペインツリーにて、 ドメイン名 －「デプロイメント」－「Webアプリケーションモジュール」－ Webアプリケーション名 の内容を確認

      • 実行キュー名

        Webコンソールの左ペインツリーにて、 ドメイン名 －「サーバー」－ サーバー名 を選択し、右ペインにて、「モニタ」タブ－「一般」－「すべてのアクティブなキュー のモニタ...」の一覧の内容を確認

        デフォルトの実行キュー名はWebLogic Server 8.1では weblogic.kernel.Default , WebLogic Server 7.0では default となっています。

      • トランザクションリソース名

        Webコンソールの左ペインツリーにて、 ドメイン名 －「サーバー」－ サーバー名 を選択し、右ペインにて、「モニタ」タブ－「JTA」－「すべてのリソース別トランザクション のモニタ...」の一覧の内容を確認

    • JBoss Application Server監視
      • ポート番号

        JMX Consoleのjbossドメインのservice=Naming MBeanのPort Attributeを確認

      • ホスト名

        JMX Consoleのjboss.webドメインのtype=Manager MBeanの内容を確認。なお、デフォルトのホスト名は localhost となっています。

      • Contextパス

        JMX Consoleのjboss.webドメインのtype=Manager MBeanの内容を確認。なお、デフォルトのContextパスは / となっています。

      • サーブレット名

        ドメインはjboss.webの場合、JMX Consoleのjboss.webドメインのj2eeType=Servlet MBeanの内容を確認。

        jboss.management.localの場合、JMX Consoleのjboss.management.localドメインのj2eeType=Servlet MBeanの内容を確認。なお、デフォルトのサーブレット名は default となっています。

      • ウェブモジュール名

        ドメインはjboss.webの場合、JMX Consoleのjboss.webドメインのj2eeType=Servlet MBeanの内容を確認。

        jboss.management.localの場合、JMX Consoleのjboss.management.localドメインのj2eeType=Servlet MBeanの内容を確認。なお、デフォルトのウェブモジュール名は //localhost/ となっています。

      • J2EEアプリケーション名

        ドメインはjboss.management.localの場合、JMX Consoleのjboss.management.localドメインのj2eeType=Servlet MBeanの内容を確認

      • J2EEサーバー名

        ドメインはjboss.management.localの場合、JMX Consoleのjboss.management.localドメインのMBeanの内容を確認。なお、デフォルトのJ2EEサーバー名は Local となっています。

      • JCAリソース名

        ドメインはjboss.jcaの場合JMX Consoleのjboss.jcaドメインのservice=ManagedConnectionPool MBeanの内容を確認。ドメインはjboss.management.localの場合、JMX Consoleのjboss.management.localドメインのj2eeType=JCAResourceMBeanの内容を確認

      • J2EEサーバー名

        ドメインはjboss.management.localの場合、JMX Consoleのjboss.management.localドメインのMBeanの内容を確認。なお、デフォルトのJ2EEサーバー名は Local となっています。

      • スレッドプール名

        JMX Consoleのjboss.webドメインのtype=ThreadPool MBeanの内容を確認

      • GCポリシー(JBoss)

        JMX Consoleのjava.langドメインのtype= GarbageCollector MBeanの内容を確認

  19. 監視タスク定義データの書き出し機能で書き出したファイルのノード名を変更し、 「追加のみ」 で読み込ませたところ、「監視タスクID:'追加のみ'のため変更しません」とエラーになりました。書き出した監視タスクを別ノードに追加したい場合はどうすれば良いのですか？

    該当監視タスクIDの監視タスクが、既にドメイン内に存在しているためにエラーとなっています。同一IDの監視タスクが存在する場合、その監視タスクを変更する動作になります。監視タスクを追加する場合は、監視タスクIDを 0 に変更してから、読み込み処理を行って下さい。 監視タスクIDが 0 の場合、千手システムで監視タスクIDを自動的に設定します。

  20. Oracle監視を行おうとすると、「メッセージ:ORACLE 監視の実行に失敗しました。」という!ISM124メッセージが出力されます。どのようなことが原因として考えられますか？

    Oracle監視に失敗する原因として以下のようなことが考えられますので、ご確認下さい。

    1. Oracle監視を行うためのsqlplusコマンドが正しく実行できていない可能性があります。インストールガイドに従い、Oracle Clientをインストール、設定して下さい。

    2. Oracle Clientインストール後、千手システムがsqlplusコマンドを認識できていない可能性があります。ノードモニタからsjANM_monExtdプロセスを停止および起動するか、千手の再起動を行って下さい。

    3. 監視タスクパラメータにおけるユーザー名の大文字小文字が間違っていると、Oracle監視に失敗する場合があります。登録されているユーザー名を大文字小文字含めて正しく入力して下さい。

  21. 千手エージェントから千手センサーとして登録しなおし、さらに千手センサーから千手エージェントに登録しなおしたときに、監視が一時停止のままになってしまいました。

    千手エージェントから千手センサーとして登録しなおし、さらに千手センサーから千手エージェントに登録しなおした場合、千手の再起動をしてください。

  22. 毎日午前9:00、あるいはブラウザを起動してマネージャにログインした時に、ライセンスが無いという以下の警告ダイアログが表示されます。
    ../_images/image0075.jpg

    モニタリングサブシステムのエクステンションは、ライセンスが無いエクステンションについても監視タスクが表示され、1エージェントだけ設定・評価できます。新しい用途のサーバー追加時などの評価時に一時的にトライアルとしてご利用いただけます。 ライセンスが無いエクステンションの監視タスクを設定している場合は、毎日午前9:00、あるいはブラウザを起動してマネージャにログインした時に警告ダイアログが表示されます。 警告ダイアログを表示しないようにするには、ライセンスを購入していただくか、該当の監視タスクを削除してください。 なお、千手ブラウザオプションにより、ライセンスが無いエクステンションについては監視タスクを表示しないようにすることも可能です。

  23. WindowsのTelnetサーバーに対してリモートサーバーのTELNET所要時間監視で「TELNET受信量が受信バッファサイズを超えています。」とのエラーが発生してしまい、監視が正常に行えません。

    WindowsのTelnetサーバー最大接続数の初期設定値は2になっていますので、同一のTelnetサーバーに対して複数のTELNET所要時間監視タスクを設定し、かつ監視間隔が短い場合、接続待機時間が長くなり、受信バッファが溢れることがあります。 解決方法として、Telnetサーバー最大接続数を増やすこと、監視間隔を大きくすることを挙げられます。Telnetサーバー最大接続数を増やした場合、Telnetサービスを再起動する必要があります。

    参考

    WindowsのTelnetサーバーの設定について、ご利用になっているWindowsのマニュアルを参照してください。

  24. UNIX/Linux版の管理対象ノードにて、ログ監視時に「メッセージ:文字コード変換に失敗しました。」という!ANM292メッセージが出力されます。どのようなことが原因として考えられますか？

    UNIX/Linux版の管理対象ノードにて、監視対象ログの文字コードがUTF-8以外に指定されている場合、OSのシステム関数であるiconv関数を用いて文字コードの変換を行います。iconv関数では、コードテーブルを使用しますが、必要なコードテーブルがインストールされていない可能性があります。その場合は、文字コード変換に失敗します。

    使用するコードテーブルを、以下の表に記します。

    OS(千手の文字コード)

    変換に必要なコードテーブル

    HP-UX(Shift_JIS)

    sjis、utf8

    Solaris(EUC)

    eucJP、utf8

    Solaris(Shift_JIS)

    PCK、utf8

    AIX(Shift_JIS)

    IBM-932、UTF-8

    Linux(EUC)

    EUC-JP-MS、UTF-8

    iconvコマンドで、実際に文字コードを変換することにより、コード変換ができるかを確認することができます。以下のコマンド実行により、コマンドが失敗する場合は、コードテーブルを別途インストールする必要があります。コードテーブルのインストールについては、ベンダーにお問い合わせ下さい。

    • iconvコマンドの使用法

      iconv -f (変換前のコードテーブル名) -t(変換後のコードテーブル名) (変換対象ファイル名) > (変換後ファイル名)

      (実行例：HP-UX(Shift_JIS)にて、Shift_JISのテキストファイルbefore_sjis.txtを、UTF-8に変換し、after_utf8.txtとして保存する)

      % iconv -f sjis -t utf8 before_sjis.txt > after_utf8.txt
  25. 千手ブラウザのツリービューで、ドメインの下の コマンド → 千手コマンド → バーチャリゼーション → HyperV：仮想マシンのシャットダウン でHyper-Vサーバーでの仮想マシンをシャットダウンする時に、「ERROR：指定された仮想マシン「仮想マシン名」のシャットダウンに失敗しました。」とのエラーが発生してしまい、仮想マシンのシャットダウンが正常に行えません。

    主に以下の原因を考えられています。

    1. Hyper-V統合サービス セットアップがインストールされない

    2. 仮想マシンは既に停止中

    3. 仮想マシンは存在しない

    解決方法として、仮想マシンは起動中か、Hyper-V統合サービスセットアップがインストールしているかどうかを確認してください。

  26. ファイル改竄監視を行っていますが、「新たな監視対象」という!ISM124メッセージが検査官間隔ごとに出力されます。この状態を回避するためにはどうすればよいでしょうか？

    監視タスクの計算結果の比較方法が「初回との差分」となっている場合に、監視タスク起動時の初回の情報取得に失敗した場合に発生します。エラーメッセージを出力させないようにするためには、該当監視タスクを一時停止していただき、再開することで正常に監視を行うことが出来ます。ただし、監視タスク再開時に情報取得に成功する必要があります。

  27. Oracle監視で、Oracleバージョンが10.2以降の環境のUNDO表領域を監視対象にして以下監視タスクを設定した場合、監視結果がOracle Enterprise Manager画面の表示と異なる場合があります。どのようなことが原因として考えられますか？

    ORACLE:テーブルスペース サイズ(MB)

    ORACLE:テーブルスペース 使用量(MB)

    ORACLE:テーブルスペース 空き容量(MB)

    ORACLE:テーブルスペース 使用率(%)

    Oracleでは、Oracle EnterpriseManager(OEM)に表示されるUNDO表領域の使用量の算出方法がOracleバージョンにより異なります。そこで、Oracle監視でもOracleバージョンに応じた算出方法を用意しております。Oracleバージョンが10.2以降の場合、環境変数 SjANM_oraExtChk を設定することにより、Oracle Enterprise Manager画面の表示と同じ使用量が算出できます。環境変数の設定方法については、 Oracle監視で、Oracle10.2以降の環境でUNDO表領域の情報取得を行う場合の設定 を参照してください。

  28. VMware監視にてログイン情報(VC/ESXユーザー名、VC/ESXパスワード)が間違っていても正常に監視が行えていました。どのようなことが原因として考えられますか？

    VMware監視では複数の項目を監視されていると思います。複数の監視タスクに同一の「VC/ESXサーバーホスト名」が設定されていた場合、正常に監視が行えた監視タスクが接続情報をキャッシュするため、ログイン情報が間違っていても正常に監視が行える場合があります。

  29. sjANM_taskchangeコマンドにて、プロセス稼働監視[UNIX]の監視タスクを一時停止させてから監視対象のプロセスを停止しましたが、「!ANM112 プロセスが異常終了しました。」が出力されました。なぜ、メッセージが出力されるのでしょうか？

    コマンドにて監視タスクの動作を変更しても、実際に変更されるまでに時間がかかる場合があるためです。

    コマンドの動作概要は以下になります。

    • sjANM_taskchangeは、該当ノードの監視タスクの動作を変更するよう千手マネージャに依頼します。

    • 依頼を受けた千手マネージャは、該当千手エージェントに監視タスクの動作を変更するよう指示します。

    • 千手エージェントは、該当監視タスクの動作を変更します。

    実際の該当監視タスクの状態をノードモニタまたは、プロセス稼働状態問い合わせコマンド デベロッパーズガイド「千手コマンドの一覧」 の sjANM_ps－プロセス稼働状況の表示－ で確認してから該当のプロセスを停止して下さい。なお、sjANM_pschangeコマンドも同様の動作となります。

  30. プロセス稼働監視[UNIX]にて、プロセスが異常終了した旨のメッセージ「!ANM112 プロセスが異常終了しました。」が出力された際、実機で確認すると該当のプロセスは稼働してしています。なぜ、メッセージが出力されるのでしょうか？

    OSがUNIX/Linuxの場合プロセス稼働監視では、psコマンドの結果を利用しています。psコマンドの動作により監視対象プロセスの子プロセスの起動／終了を検知した場合 「!ANM112 プロセスが異常終了しました。」 メッセージが出力されます。

    psコマンドの結果として表示されるプロセス名についてOSベンダより以下の報告を受けています。

    • 親プロセスがシステムコールfork()、execvp()で子プロセスを起動した場合、システムコールfork()後、子プロセスは親プロセスと同じ名称になり、その　後execvp()されるとその子プロセスの名称に変更される。

    • システムコール fork() と execvp()のわずかな間に、psコマンドが実施されると、親プロセスのプロセス名称で表示される。

    お客様の想定外で監視対象プロセスの起動／停止を検知した場合、監視対象のプロセスが子プロセスを起動することがあるかを確認してください。なお、監視タスクの同一プロセス名稼働数[UNIX]、稼働プロセス数[UNIX]においても、psコマンドの結果を利用していますので、同様に子プロセスの稼働／停止を検知する場合があります。

10.2.3.2. Windows(管理対象ノードがWindowsの場合)固有のQ&A

  1. 管理対象ノードがWindowsの場合に、モニタリングの設定をしたにもかかわらず監視が行われないことがありますが、考えられる原因は？

    Windowsエージェントインストール時に入力した自ホスト名と、管理対象ノードの登録で入力したノード名が異なっている可能性があります。管理対象ノードは大文字／小文字の区別を行います。管理対象ノードの登録で登録されたノード名とWindowsエージェントインストール時に設定した自ホスト名が同じかどうかを確認して下さい。

  2. メッセージモニタにコード 「!SYSL02」 のメッセージ「システムのエラーメッセージを受信しました。」で通知されるイベントログ出力時間が、現在の時刻とずれているのはなぜですか？

    現地時間帯を設定する環境変数 TZ の値が日本時間に設定されていないことが考えられます。Senju DevOperation Conductorではインストール時に TZ をシステム環境変数に JST-9 で設定しています。この値を削除したり、変更するとイベントログの出力時間が正しく表示されない可能性があります。

    コントロールパネルのシステムから、システム環境変数 TZ を JST-9 に設定して下さい。

  3. メッセージモニタにコード 「!SYSL03」 のメッセージ「syslogデーモン出力用のファイルがオープンできません。(OpenEventLog(System)(1717))」と出るのはなぜですか？

    OSの一機能であるRPCサーバーかイベントログサービスが何らかの原因により異常な状態になっていることが考えられます。RPCサーバー、イベントログサービスに異常がないか調べて下さい。最も簡単な回復方法はWindowsの再起動です。

  4. 特にCPUを占有するようなアプリケーションを稼働させていないのに、CPU使用率が100%と表示されるのはなぜですか？

    OpenGLを用いたスクリーンセーバーを稼働させると、これがCPUを占有します。なおかつ、これを制御している csrss プロセスは他のプロセスよりも優先順位が高いため、バックグラウンドで稼働しているプロセスにCPUが割り当てられにくくなります。このため、OpenGLを用いたスクリーンセーバーは使用しないことをお勧めします。

  5. システム情報監視を行っていますが、仮想メモリの全容量が起動直後と比較して値が異なっていることがあるのはなぜですか？

    Windows版では物理メモリの容量とディスク上の PAGEFILE.SYS を合わせて、OSの管理領域等を除いた値、すなわちユーザーが利用できる仮想メモリの値を表示します。値が途中で変化するのは、仮想メモリの設定でページファイルサイズに幅をもたせた場合等に、これらの値が変化するためです。例えばWindowsが出力する仮想メモリ不足警告のダイアログで[OK]ボタンを押すと、自動的に仮想メモリの全容量が増加されます。

  6. あるアプリケーションを削除しようとしましたが、千手が稼働しているとDLL(ダイナミック・リンク・ライブラリ)等の削除に失敗してしまいます。Senju DevOperation Conductorとは関係ない製品の削除を行う際にも千手を停止しないといけないのですか？

    Senju DevOperation Conductorのモニタリング機能はイベントログを読み込んだり、パフォーマンスのデータを取得したりしています。この時、他製品のDLLをロードしないと取得できないデータがあるため、Senju DevOperation Conductorがこれらのファイルを使用していることがあります。製品にもよりますが、削除時にイベントビューアやパフォーマンスモニタを停止しないと削除できないファイルは、千手も停止した後、削除を行って下さい。

  7. ユーザー起動プロセスの監視を行いたいのですが、プロセス名は大文字、小文字どちらで入力すればよいのですか？また拡張子まで付けないといけませんか？

    Windowsが管理している稼働中プロセス名の大文字、小文字は起動シーケンスによらず、ファイル名に依存します。ファイル名に大文字、小文字の区別がないため、プロセス名にも実際のところ大文字、小文字の区別がありません。そのためSenju DevOperation Conductorでは大文字、小文字を区別していません。 千手ブラウザの ノードグループ → ノード のプロパティの画面ではどちらで入力しても自動的に大文字で登録されるため、どちらで入力しても構いません。 また、Windowsでは8.3形式の名前のプロセスには拡張子は付加されず、それ以外の物には拡張子が付加されるようになっています。このため、Senju DevOperation Conductorでは拡張子を見ない仕組みになっていますので、登録時には拡張子を付けなくても構いません。

  8. イベントログを自動的に上書きされない設定にしたいのですが、Senju DevOperation Conductorのインストール時にイベントログの設定を「必要に応じて上書き」の設定にしなければなりません。この設定を変更しても問題無いのでしょうか？

    「イベントを上書きする」、「イベントを上書きしない」設定にすると、イベントログがいっぱいになった時、新しくイベントログに書き込もうとしてもすべて捨てられていまい、結局重要な情報がログに残らないことがあります。 設定を変更しても監視は続けられますが、イベントログがいっぱいになった時、ログが捨てられる危険があります。イベントログを残したいのであれば、最大ログサイズを大きくするか、または定期的にファイルに保存するようにして下さい。

  9. 長期間に渡りシャットダウンせずに運用していると仮想メモリ不足になります。どのアプリケーションが大量にメモリを占有しているか、切り分けを行いたいのですがどうすればよいですか？

    マシン起動時には十分仮想メモリが残っていたにも関わらず、長期間シャットダウンせずに運用を続けていると、仮想メモリが不足するような場合は、プロセスのメモリリーク(確保したメモリ領域の開放漏れ)が考えられます。 メモリリークには大きく分けて2つのタイプがあります。プロセス固有のメモリ領域を食い潰していくタイプのものと、OSのメモリ領域を増加させるものです。 前者の場合、問題のあるプロセスをいったん停止させることにより、そのプロセスが確保していた領域が開放され、仮想メモリ不足は解消されますが、後者の場合、シャットダウンしない限り解消されません。

    問題のあるプロセスを見つけるためには、Windowsに標準で付属されているパフォーマンスモニタを利用します。

    1. 「グラフに追加」画面でオブジェクトに Process 、カウンタに PrivateBytes を指定し、インスタンスに表示されているすべてのプロセスを選択して、[追加]ボタンを押します。

    2. グラフに表示された物のうち最も値が大きいプロセス名を探して下さい。

    3. 同様にして、カウンタの値を Handle Count や Virtual Bytes 、 Pool Nonpaged Bytes (各値の説明はパフォーマンスモニタの[説明]ボタンを押して参照して下さい)等に変更して切り分けを行って下さい。

    値が最も大きいからといって必ずしもそのプロセスがメモリリークしているとは限りませんが、起動時に比べて大きく値が増加しているのであればリークの可能性があると考えられます。 Senju DevOperation Conductorの常駐系のプロセス名は sj , Sp , ftu , PCB , SENJU で始まるものです。これら以外のプロセスがリークしている場合、メモリリークの原因はSenju DevOperation Conductorではありません。 なお、運用の方法によってはOS自体がリークすることもあります。できる限り長期の運用は避け、ウィークリーやマンスリーでのシャットダウンをお勧めします。長期の運用が避けられない場合は、メモリの増強や、ページファイルのサイズを大きめに設定する必要があります。

  10. 長期間に渡り千手を稼働させていたところ、 sjANM_evtwatchd というSenju DevOperation Conductorのプロセスが、仮想メモリを起動時よりも多く使用しているようですがなぜですか？

    sjANM_evtwatchd というプロセスは主にOS障害監視(イベントログの監視)を行っています。

    これらのデータを取得するために他製品(そのマシンにインストールされているSenju DevOperation Conductor以外のアプリケーション)のDLL(ダイナミック・リンク・ライブラリ)をロードすることがあります。このDLLの内部でメモリリーク(確保したメモリ領域の開放漏れ)があると、 sjANM_evtwatchd が使用する仮想メモリが増加します。 この様な障害はDLLの方を修正しない限り解決されません。アプリケーションを順にインストールしながら、どのアプリケーションに問題があるのかを切り分け、アプリケーションの提供元に問い合わせて下さい。

  11. Windowsの千手センサーを監視している状態でWindowsの千手センサーがダウンすると、プローブノードのイベントログ(システム)に以下のようなエラーメッセージがメッセージモニタに定期的に出力されます。どうすればよいですか？

    メッセージID：!SYSL30

    メッセージ内容：システムのイベントを受信しました。(YY/MM/DD hh:mm:ss Microsoft-Windows-DistributedCOM エラー なし 10009 N/A (ノード名) 構成されているどのプロトコルを使っても、DCOM がコンピュータ (ノード名) と通信できませんでした。)

    停止中のWindowsの千手センサーに対してWMIによる監視を行った場合、プローブノードのシステムのイベントログにMicrosoft-Windows-DistributedCOMからエラーレベルのメッセージが記載される可能性があります。 この際にプローブノードのシステムのイベントログをデフォルトのSJSYSTEMイベントログフィルタで監視していると、エラーメッセージが定期的に出力されます。エラーメッセージを出さないようにするためには下記の対処が必要です。

    • Windowsの千手センサーが停止した場合は、そのノードに対してWMIを使用して監視している監視タスクを全て一時停止する。

    • システムのイベントログフィルタに抑止処理として、種類エラー/ソースMicrosoft-Windows-DistributedCOMを追加する

10.2.4. ジョブスケジュールのQ&A

ここでは、ジョブスケジュールサブシステムを使用する際の基本的な疑問に対するQ&Aについてまとめています。使用前に一読して下さい。

10.2.4.1. [ジョブ／ネット定義時]

  1. 千手ブラウザの「ジョブスケジュール」→「トリガ」にてトリガを削除しようとしたら拒否されました。トリガが削除できる条件は何でしょうか？

    以下の2条件をすべて満たしている場合に、トリガは削除できます。

    • 削除するトリガを含む、ジョブ／ネットが存在しない。

    • 削除するトリガを含む、ジョブ／ネットがフレーム登録されていない。

  2. フレーム間で先行関係をつけるにはどうすればよいでしょうか？

    先行フレーム内のジョブ／ネットでトリガを発行し、そのトリガを後続フレーム内のジョブ／ネットの起動条件に指定して下さい。

  3. 前日の同じフレーム内のジョブ／ネットが終了していれば今日のジョブ／ネットが動きだすようにしたいのですが？

    起動条件となるジョブ／ネットが終了すると、そのジョブ／ネットの運用日付の翌日の日付でトリガを発行するようにして下さい。そして後続ジョブ／ネットの起動条件にそのトリガを加えて下さい。

  4. システム作成時に指定する自動サイクル運用の基準時刻が有効となるのはいつから？

    その基準時刻を定義した日の翌日からです。

  5. 動作環境および、ジョブ・ネットの定義や構成を変更しました。このジョブやネットを使用している既存の実行システムに反映されますか？また、変更した内容が有効になるのはいつからですか？

    既に作成済みの実行システムへは、変更内容は反映されません。次回実行システム作成時(自動サイクル運用の場合は、次回の運用基準時刻)から、変更内容が反映されます。

  6. ファイル待ちトリガの定義を変更しました。このファイル待ちトリガを使用している既存の実行システムに反映されますか？

    既に作成済みの実行システムへの反映は、実行システムとして作成されたフレームの起動状況でトリガ情報の反映動作が異なります。

    1. フレームが起動している場合　：トリガ情報は変更されません。

    2. フレームが起動していない場合：トリガ情報は反映されます。

    注釈

    • フレーム連携トリガの定義変更についても、ファイル待ちトリガの動作と同様になります

    • イベント待ち／ファイル待ち／フレーム連携トリガの時刻によるトリガ設定についても、ファイル待ちトリガの動作と同様になります

  7. 一つのジョブ／ネットにスキップと一時停止の両方を指定するとどちらが優先されるのでしょうか？

    スキップが優先されます。

  8. ファイル待ちトリガにおいて、Senju DevOperation Conductorの管理対象以外のノードのファイルを監視することは可能でしょうか？

    直接監視することはできません。監視する必要がある場合は、以下のような工夫が必要です。

    1. NFSマウントして、Senju DevOperation Conductorの管理対象ノードから当該ファイルが見えるようにする。

    2. ファイル転送機能を利用して、当該ファイルが作成されたらSenju DevOperation Conductorの管理対象ノードにもファイルが作成されるようにする。

  9. ファイル待ちトリガにおいて、トリガがONになるのはどのタイミングでしょうか？

    当該ファイルが生成されたときです。従って、1バイトも書き込みが行われなくてもトリガがONになります。ファイルが完成した時点ではないのでご注意下さい。

  10. ファイル待ちトリガの定義で、指定するディレクトリ名は絶対パスで指定するのでしょうか？

    絶対パスで指定して下さい。

  11. 1つのジョブ／ネットにスキップとリソースの両方を指定するとどちらが優先されるのでしょうか？

    スキップが優先されます。

  12. 「動作環境」は複数の場所で設定できますが、優先順位はどのようになりますか？

    設定した場所により、優先度は次のようになります。(1の方が、優先度が高い)

    1. 「ジョブ」エンティティのリストビューで、ジョブのプロパティを開き設定。

    2. 「ネット.定義有効日」エンティティのリストビューで、ネット内のジョブのプロパティの「全般」タブで設定。

    3. 「ネット.定義有効日」エンティティのリストビューで、ネット内のネットのプロパティの「全般」タブで設定。

    4. 「システム」エンティティのリストビューで、システム内のフレームのプロパティを開き設定。

    なお、ジョブエディタでジョブのプロパティにて設定した場合は、下記のようになります。

    • 「全般」タブで設定した場合は、上記 2 と同じ優先度

    • 「ジョブ」タブで設定した場合は、上記 1 と同じ優先度

    また、ジョブエディタでネットのプロパティにて設定した場合は、下記のようになります。

    • 「全般」タブで設定した場合は、上記 3 と同じ優先度

  13. 「カレンダー」は複数の場所で設定できますが、優先順位はどのようになりますか？

    稼働日カレンダーは設定場所による優先順位はありません。「非稼働日」の設定が優先されますので、ジョブが稼働するためには、当該ジョブ並びに上位のネットやフレームに設定されているすべての稼働日カレンダーが「稼働日」の必要があります。

  14. ファイル待ちトリガは、ファイル日付も確認しているのですか？

    ファイル待ちトリガは、対象のファイルの日付は確認しておりません。そのため、トリガが生成されたときに、指定のパスにファイルが存在すると、ファイル日付の新古にかかわらずONになります。使用済みの古いファイルは削除するようにして下さい。

  15. 同じ名称の、定義有効日が異なるネットがあり、それぞれの有効期間が重複している部分がある場合、どのネット定義が有効になりますか？

    同一ネット名称で、複数の定義が存在する場合、定義有効日が一番新しいネット定義(注：一番新しく定義したネット定義ではありません)が、常に有効になります。

  16. 同じジョブを、1ネット内に複数個定義することはできますか？

    できません。ネットが異なれば、同じジョブをそれぞれに(1つずつ)定義することができます。

  17. 同一フレーム内に、同一ネットを複数個定義することはできますか？

    できません。異なるフレームには定義が可能です。

  18. 一週間後にリリースする(定義有効日が一週間後)ネットを、予め既存のフレームに定義しておいた場合、一週間後にそのネットは稼働するようになるのですか？

    フレーム内に、定義有効日に至っていないネットが存在する場合(代替となる、同じ名称の他のネット定義も存在しない場合)、実行システム作成の際に、そのフレームの登録は中止されます(自動サイクル運用のときも同様です)。このようなネットを定義有効日前に定義したいときは、実際の定義有効日までは稼働しないようなカレンダーを設定し、定義有効日は当日にするようにして下さい。なお、当該ネットがフレームのときは、ネット定義有効日が未来でも、フレームの運用開始日で制御することができます。

10.2.4.2. [フレーム登録時]

  1. フレーム登録がなかなか終わりません。

    フレーム登録はジョブ／ネット数が多いとかなり時間がかかることがあります。予めご了承下さい。また、不要になった古い運用日付の定義が残っている時はその運用日付を削除することにより、時間を短縮することができる場合もあります。

  2. ジョブチェッカからジョブ／ネット／フレームのテストを行ったら、コマンドのファイルが存在するにもかかわらずNGになりました。なぜでしょうか？

    原因として、以下の理由が考えられます。

    • ジョブの場合、そのジョブを動作するノードで千手が起動されていなければテスト機能は使用できません。

    • ジョブの場合、そのジョブのコマンドにパスが通っていない、もしくは、コマンドに実行権が無いと、ジョブのテストはNGになります。

  3. 定義していないリソースをジョブやネットに指定していましたがフレームの作成は正常に行われました。ただし、実行システムのジョブやネットのプロパティのリソースタブで参照するとリソースのリソース値は512になっていました。なぜでしょうか？

    これは、ジョブスケジュールのネットの簡易投入のコマンドのために用意された機能です。ネットの簡易投入ではリソースを別なリソースに置き換えて投入できます。置き換えたリソースはリソース定義に既に登録されていてもいなくても構いませんが、新たなリソースとしてリソース定義へ反映されることはありません。 リソース定義から誤ってリソース値1のリソースを削除してしまった場合にも、当該リソースを使用したフレームはリソース値512として作成されますので、ご注意下さい。

  4. 自動サイクル運用の設定で、システムの運用基準時刻とフレームの起動時刻の関係がよく分かりません。

    システムの運用基準時刻には、当日運用日付以外(前日以前)の当該システムの初期化、当日運用日付の追加、実行システムの作成、システム投入が順に行われます。システムが投入された後、内部のフレームは、それぞれの起動時刻に起動します。つまり、システムの運用基準時刻には、フレームは投入までが行われ、この時刻にフレームが起動するわけではありません。

  5. 自動サイクル運用対象のシステムやフレームを予め作成している(実行システムを作成している)とき、自動サイクル運用はどうなりますか？

    作成したシステム名やシステム内のフレーム状態により、自動サイクル運用の運用基準時刻に下記のメッセージを出力します。（作成したシステムの未投入／投入に関係なく同じ動作になります）

    • 作成したシステム名が自動サイクル運用のシステム名と同一の場合

      既に作成されているフレーム以外のフレームについては、自動サイクル運用の運用基準時刻に自動サイクル運用により作成されます。

      このとき、作成したフレームについて下記のメッセージを出力します。

      !PEX494 オペレーション [フレーム登録[登録フレーム重複]]

      また、自動サイクル運用のシステム内のすべてのフレームを作成されていた場合はあわせて下記のメッセージを出力します。

      !PEX582 オペレーション [フレーム登録[登録システム重複]]

      いずれの場合も自動サイクル運用の運用基準時刻の処理は成功となります。

      !PEX457 オペレーション [自動運用[成功]]

    • 作成したシステム名が自動サイクル運用のシステム名と異なる場合

      既に作成されているフレーム以外のフレームについては、自動サイクル運用の運用基準時刻に自動サイクル運用により作成されます。

      このとき、作成したフレームについて下記のメッセージを出力します。
      !PEX455 オペレーション [フレーム登録[登録フレーム重複]]
      !PEX439 オペレーション [フレーム登録[フレーム登録中止]]
      自動サイクル運用の運用基準時刻の処理は成功となります。

      !PEX457 オペレーション [自動運用[成功]]

      なお、自動サイクル運用のシステム内のすべてのフレームを作成されていた場合はあわせて下記のメッセージを出力します。
      !PEX451 オペレーション [フレーム登録[登録フレームなし]]
      !PEX438 オペレーション [フレーム登録[システム登録中止]]
      自動サイクル運用の運用基準時刻の処理は失敗となります。
      !PEX458 オペレーション [自動運用[失敗]]
  6. 自動サイクル運用を行うシステムに、起動時刻が設定されていないフレームが含まれているとき、動作はどうなりますか？

    実行システムは作成されますが、そのフレームについては投入されません。

  7. 自動サイクル運用を行うフレームには、必ず稼働日カレンダーを設定しなければいけないのですか？

    必ずしも設定する必要はありませんが、自動サイクル運用を行うフレームに、カレンダーが設定されていない場合、すべての日付が稼働日扱いになります。自動サイクル運用に関係なく、カレンダーが設定されていないネット・ジョブは、すべての日付で稼働日となります。

  8. 既存のフレームで使用しているネットに、「定義有効終了日」を設定したら、フレームが作成されなくなりました。

    フレーム内に定義有効日に至っていない、または運用日付より前の定義有効終了日が設定されたネットが存在する場合、他に適用できる異なる定義有効日の(同じ名称の)ネットが存在しなければ、実行システム作成の際(自動サイクル運用を含む)、そのフレームの登録が中止されます。

10.2.4.3. [ジョブ／ネット稼働時]

  1. 一時停止指定されているジョブ／ネットを起動すると、一瞬稼働中の色になってから一時停止の色になりました。

    一度起動がかかったジョブ／ネットは、必ず一度稼働中になってから別の状態に遷移します。この過渡期の稼働中の状態は一瞬なので普通は見えませんが、タイミングによってその状態が表示されることがあります。

  2. 一時停止しているジョブ／ネットの一時停止を解除したのに起動されません。なぜでしょうか？

    そのジョブ／ネットの上位に一時停止指定されているネットがあると、起動されません。一時停止指定がされているネットの一時停止を解除して下さい。

  3. スキップ指定をしていないジョブがスキップ待ちで表示されています。なぜでしょうか？

    以下の理由から、このような表示になります。

    1. 当該ジョブの上位ネットのいずれかにスキップ指定がされていると、そのジョブは起動待ちではなくスキップ待ちになります。ジョブ／ネット自体にスキップ指定がされているかどうかは、該当フレームを投入する前に、ジョブモニタの[ランチャート]タブでプロパティを参照して下さい。

    2. 自動再ラン機能がOFFに設定されている場合に、千手ブラウザの コマンド → 千手コマンド → ジョブスケジュール から「管理プロセスの再起動」を行って、管理プロセス(状態管理サーバー)を再起動させたとき、稼働中であったフレームは自動的にリカバリ起動されますが、このとき既に正常終了したジョブは自動的にスキップ待ちになります。「フレームの再ラン」後に「正常終了」に遷移します。

  4. 上位ネットが一時停止指定のため一時停止状態のとき、この影響を受け一時停止状態となっている配下のジョブ／ネットに対してスキップ指定を行いました。その後、スキップ指定を行ったジョブ／ネットの一時停止を解除したときどのような動作になりますか？

    ジョブ／ネットにより、動作が異なります。

    • ジョブの場合

      一時停止解除が行われ、ジョブはスキップ終了します。

    • ネットの場合

      配下のネット自体には一時停止指定されていないため「既に一時停止が解除されていました。」とアウトプットビューに出力されますが、ネットの状態は一時停止のままです。

  5. 上位ネットが一時停止状態のときネットの一時停止を解除しました。このとき下位ネット／ジョブはどのような動作になりますか？

    上位ネットに対して一時停止の解除を行ったタイミングの下位のネット／ジョブの状態により、動作が異なります。

    • 状態が“一時停止待ち”の場合

      上位ネットに対しての一時停止が解除されたことで下位のネット／ジョブが起動しますが一時停止指定により起動しません。また、状態は“一時停止待ち”から“一時停止”に遷移します。

    • 状態が“一時停止”の場合

      上位ネットに対しての一時停止の解除と一緒に下位のネット／ジョブの“一時停止”も解除されます。

  6. ジョブ／ネットに指定した開始予定時刻になっていないが、ジョブ／ネットを起動させたい場合はどうすればよいでしょうか？

    ジョブモニタの[ランチャート]タブからジョブ／ネットの開始時刻を削除して下さい。

  7. ジョブを連続モードで初期化しても、後続ジョブの一部しか初期化されませんでした。なぜでしょうか？

    以下の理由から、このような動作になります。

    1. 途中に稼働中のジョブ／ネットがあると、そのジョブ／ネット以降は初期化されません。

    2. ネットを越えての連続初期化はできません。

  8. フレームを初期化した後、再ランすると「未投入です」と言われて再ランできませんでした。どうすればよいでしょうか？

    ジョブ／ネットを初期化した場合は再ランできますが、フレームの場合は直接再ランすることはできません。フレームを再度投入して下さい。

  9. フレームの即時投入を行うにはどうすればよいでしょうか？

    ジョブモニタの[フレーム]タブから、当該フレームを選択し、[ツール]→[投入]メニューを選択し、投入ダイアログで起動日付に +00 、起動時刻に +0000 と指定して[OK]ボタンを押して下さい。

  10. 千手ブラウザの「コマンド」→「千手コマンド」→「ジョブスケジュール」→「ネット内ジョブ稼働状況」などジョブの操作を行うとき、「運用日付」「フレーム名」「ネット名」「ジョブ名」を指定しますが、フレームの直下にジョブがある場合は、「ネット名」に何を指定したらよいのでしょうか。

    フレーム名を指定して下さい。この場合「フレーム名」＝「ネット名」となります。

  11. 先行ジョブが正常終了したのにジョブが稼働しません。なぜでしょうか？

    以下の条件が満たされていないと、ジョブは稼働しません。条件が満たされているかチェックして下さい。

    1. 起動条件として指定しているトリガがオンになっていること。

    2. そのジョブの開始予定時刻が到来していること。

  12. 作成時に一時停止指定していたジョブを一度起動した後、そのジョブを初期化して再ランすると一時停止しませんでした。

    再ラン時にもう一度一時停止させたい場合は明示的に一時停止を指定して下さい。スキップも同じです。ただし、フレームを初期化して再投入した場合は、定義時の一時停止、スキップ指定がそのまま反映されます。

  13. フレームを初期化すると、そのフレームの中でオンになったトリガの状態は元に戻りますか？

    戻りません。フレームの再ランなどでトリガの状態を元に戻す必要がある場合は、そのトリガがイベント待ちトリガであった場合､ ジョブモニタ([トリガ]タブ) からトリガのオフを行って下さい。ファイル待ちトリガの場合は、監視ファイルの削除を行って下さい。そのトリガがもう必要ないときは、おなじくジョブモニタの[トリガ]タブから当該トリガの消去を行って下さい。

  14. 正常時コマンド(または異常時コマンド)が実行されません。なぜでしょうか？

    原因として、以下の理由が考えられます。

    1. 正常時コマンド、異常時コマンドは、運用管理サーバー上で千手稼働アカウントで実行されます。ジョブの動作環境上では動作しないのでご注意下さい。

    2. 指定したコマンドは正しいでしょうか？ジョブチェッカから行う「テスト」機能や、ジョブモニタの[フレーム]タブから行う「テストラン」では、正常時コマンドおよび異常時コマンドの正当性チェックは行われませんのでご注意下さい。

    3. 同一ジョブに対する正常時コマンドは、同時に2つ以上起動できません。正常時コマンドが実行されたままジョブを初期化して再ランし、再度ジョブが正常終了しても、前の正常時コマンドが実行中だと正常時コマンドは実行されません。異常時コマンドも同様です。

  15. ジョブを強制停止すると、そのジョブの子プロセスも強制終了されるのでしょうか。

    ジョブを強制停止した場合は、そのプロセスグループを終了するので、子プロセスも終了されます。

  16. ジョブがキューイングのまま起動されません。なぜでしょうか？

    原因として、以下の理由が考えられます。

    1. 当該ジョブで指定されている動作環境で、同一運用日付のジョブが、動作環境定義時に指定した最大数だけ稼働していると、ジョブはキューイングされます。他のジョブが終了するのをお待ち下さい。

    2. 当該ジョブで指定されている動作環境の管理プロセス(動作環境サーバー)が異常終了した場合、そのジョブは起動時に自動的にキューイングになります。動作環境サーバーが再起動されると自動的にキューイングされているジョブは起動されます。

    3. ジョブに指定されている動作環境サーバーが動作環境プールに所属している場合、動作環境プールの同時稼働ジョブ数を超えたジョブはキューイングされます。この状態で同じ動作環境プールに所属する他の動作環境サーバーが停止するとキューイング中のジョブが起動されなくなる場合があります。 千手コマンドグループ の「動作環境サーバー再起動」で動作環境サーバーを再起動して下さい。これにより動作環境プールに設定された上限内でキューイング中のジョブが起動されます。

  17. 動作環境サーバーが異常終了しました。どうしたらよいでしょうか？

    まず、当該動作環境で指定されている稼働ノードが稼働中であるか、またネットワークが切断されていないかを確認して下さい。次に、当該ノードが稼働中であり、ネットワークも接続されていることが確認されれば、 千手コマンドグループ の「動作環境サーバー再起動」で当該動作環境サーバーを再起動して下さい。なお、その動作環境でノードグループが指定されている場合、そのノードが落ちても残りのノードだけで負荷分散機能が働き、フレームの実行は継続されます。ただし、当該ノードで稼働していたジョブは異常終了扱いになります。

  18. 動作環境サーバーを再起動しようとしたのですが、再起動できません。

    原因は以下が考えられます。

    • その動作環境サーバーが既に稼働している

    • その動作環境サーバーを使用するフレームが起動していない

    • その動作環境サーバーが稼働するノードで、Senju DevOperation Conductor(または、必要なSenju DevOperation Conductorのプロセス)が稼働していない

  19. ジョブが稼働しているノードに障害が発生しました。急遽別のノードでジョブを稼働させたいのですが？

    千手ブラウザの コマンド → 千手コマンド → ジョブスケジュール の「動作環境サーバーの再起動」で、代替ノードIDを指定して動作環境サーバーを再起動して下さい。ただし、この時に指定されたノードはジョブスケジュールサブシステムが稼働する設定で千手が起動されていることが前提となります。

  20. 動作環境サーバーを再起動するとき、指定のノード以外のノードが選択できるのはなぜですか？

    不慮のトラブルにより、動作環境サーバーの稼働ノードが使用できなくなった場合、その動作環境サーバーの稼働ノードを、一時的に代替することができるようにするためです。逆に、動作環境サーバーを再起動するときには、本来稼働すべきノード以外でも起動することができるため、注意して下さい。

  21. フレームの起動時刻が到来したとき、「動作環境サーバー起動失敗」というメッセージが出ました。どうすればよいでしょうか？

    まず、当該動作環境で指定されている稼働ノードが稼働中であるか、またネットワークが切断されていないかを確認して下さい。次に、当該ノードが稼働中であり、ネットワークも接続されていることが確認されれば、千手ブラウザの コマンド → 千手コマンド → ジョブスケジュール の「管理プロセスの再起動」で当該ノードを指定した後、千手ブラウザの コマンド → 千手コマンド → ジョブスケジュール の「動作環境サーバーの再起動」で当該動作環境サーバーを再起動して下さい。

  22. フレームの起動時刻が到来したのにジョブ／ネットが稼働しません。なぜでしょうか？

    原因として、以下の理由が考えられます。

    1. フレームの先頭のジョブ／ネットの起動条件(トリガ、開始予定時刻)が満たされていない。

    2. 何らかの理由でフレームの起動に失敗している。当該フレームを初期化して、再度、即時を指定して投入して下さい。

  23. 既に終了しているはずのジョブ／ネットが稼働中の表示のまま変わりません。なぜでしょうか？また、このような場合どうすればよいでしょうか？

    ネットワークの一時的な障害などにより、制御情報が損失した場合にこのような現象が発生することがあります。この場合は、

    1. 千手ブラウザの[ツール]→[状態の再取得]→[ジョブスケジュール]か、ジョブモニタの[ツール]→[状態の再取得]を押して下さい。(この操作は処理時間がかなりかかるため、モニタ表示に異常／障害が発生したとき以外は、実行しないで下さい。)

    2. 1.を行っても稼働中のままの場合、当該ジョブを「強制停止」して下さい。一度ジョブが異常終了の状態になるので、実際のジョブの実行状況を確認後、スキップ指定･再ランなどによって回復処理を行って下さい。

  24. 管理プロセスの再起動を行うと、「起動待ち」と表示されたフレームが起動待ち状態のままで動きません。なぜでしょうか？

    自動再ラン機能がOFFに設定されている場合に管理プロセスの再起動を行った際、管理プロセスが停止する前に稼働中であったフレームは自動的に再起動されますが、通常の起動と違い「起動待ち」と表示されます。 「フレームの再ラン」後に、ジョブは実際の状態が反映されます。なお「フレームの再ラン」前に、千手ブラウザの コマンド → 千手コマンド → ジョブスケジュール の「管理ステータスの参照」で、ジョブ／ネットの実際の状態を参照することができます。

  25. 自動再ラン機能がOFFに設定されている場合に、管理プロセスの再起動を行った後、「起動待ち」と表示されたフレームを再ランしたら、自動的に途中までジョブがスキップされました。なぜでしょうか？

    リカバリ起動が行われたときは、既に正常終了したことが確認されているジョブは、自動的にスキップ指定されます。それらのジョブのスキップ指定が適当かどうかを判断して、必要であればスキップ／一時停止の指定／解除の操作を行った後、フレームの再ランを行って下さい。 上記のスキップ指定されたジョブは再ラン後、管理プロセスの再起動が行われる前の「正常終了」と表示されます。

  26. 管理プロセスの再起動を行うと、「フレーム起動失敗」とメッセージが出ました。どうすればよいでしょうか？

    管理プロセスの再起動を行ったときに、管理プロセスがダウンしていた間に起動時刻の過ぎてしまった投入済みフレームに対してこのメッセージが出力されます。この場合は、自動再ラン機能がOFFに設定されている場合、そのフレームを投入すべきかどうかを判断して、必要であれば再投入を行って下さい。

  27. 千手稼働アカウント以外のアカウントでジョブを実行したいのですが？

    ジョブを稼働させる動作環境サーバーのユーザー名に設定することにより任意のアカウントで実行させることができます。ただし、Windowsマシンでは事前に設定が必要です。 千手稼働アカウント以外でのジョブ実行 を参照して下さい。

  28. 動作環境サーバーが異常終了しました。その動作環境で稼働していたジョブはどうなりますか。

    千手システムでは異常終了扱いにします。実際に正常に終了したか否かは手作業で判定し、その結果によって再ラン、もしくはスキップ指定後再ランなどの操作を行って下さい。

  29. ファイル待ちトリガを使用した場合、指定ファイルの監視はいつまで行われますか？

    次のいずれかの場合です。

    1. ジョブモニタのトリガタブから、当該トリガを消去 した場合

    2. 当該トリガを使用するフレームが投入されてから10日経過後。

  30. ファイル待ちトリガで指定したファイルを削除するとどうなりますか？

    ファイルが監視中であれば、トリガがOFFになります。監視が終了するまで、ファイルの生成と削除とともにトリガのON、OFFが行われます。

  31. ジョブモニタの[フレーム]タブからフレームの投入を行うときに、絶対時刻で起動時刻を指定した場合、基準となる日付はいつですか？

    投入を行った日付です。

  32. ジョブ／ネットに開始予定時刻を絶対時刻で指定しました。この絶対時刻の基準となる日付はいつですか？

    そのジョブ／ネットの所属するフレームの運用日付です。

  33. 絶対時刻の基準となる日付をフレームの運用日付から運用当日に変更したいのですが？

    デベロッパーズガイド「千手コマンドの一覧」 の sjPEX_shiftdate－開始予定日付変換－ コマンドで変更出来ます。

  34. 動作環境の作成において、ノードグループを指定した場合の最大稼働数とは何をさすのでしょうか？

    そのノードグループに所属しているノード毎の最大稼働数です。従って、実際に起動できるジョブの最大数は、「動作環境で定義された最大稼働数」×「ノードグループのノード数」となります。

  35. 異常終了していないジョブが「異常終了」と表示されます。なぜでしょうか。

    千手システムでは、UNIX/Linux版はwait()システムコールで取得するstatus情報を、Windows版はWin32 APIのGetExitCodeProcess()で取得するstatus情報を元に正常終了/異常終了を判断しています。以下のいずれかに該当しないかをご確認下さい。

    1. 当該ジョブの動作環境サーバーが異常終了している場合、ジョブは異常終了扱いになります。この場合は、動作環境サーバーの再起動を行って下さい。

    2. 当該ジョブの終了しきい値が正しく設定されているか確認して下さい。

  36. 起動条件にトリガを使用しているジョブ／ネットがスキップ指定されている場合、トリガは有効でしょうか？

    無効です。トリガのON／OFFに関わらず、起動がかかれば即スキップ終了します。

  37. ジョブで稼働させるコマンドを手動で起動した場合、うまく動きませんでした。なぜでしょうか。

    原因として、以下の理由が考えられます。

    1. ジョブスケジュールによって起動される場合には、動作環境で指定した環境変数が自動的に設定されます。手動で動かす場合も同様に環境変数を設定して下さい。

    2. ジョブスケジュールによって起動される場合には、状態管理サーバー稼働ノードID、運用日付名、フレーム名、ネット名、ジョブ名が環境変数で設定されます。これらの環境変数を参照している場合も(1)と同様です。トリガ送信コマンド sjPEX_sendtrigger を用いている場合、オプションを省略すると、自動的にこれらの環境変数が参照されますので、このコマンドを使用している場合もご注意下さい。

    3. 千手が起動されていないと、コンソールへのメッセージ送信ができません。コマンド内でメッセージ送信を行っている場合、コンソールにはメッセージが表示されません。

  38. マシンタイムを変更すると、ジョブ／ネットが起動しなくなりました。

    マシンタイム(日付、時刻)を大きく変更すると、システムが正常に機能しなくなる場合があります。そのため、マシンタイム(日付、時刻)を変更される際は、 リリースノート に記載されている時刻変更時の手順を実施して頂けますようお願いいたします。

  39. 動作環境でノードグループを指定しているのに、各ノードで稼働しているジョブ数が均等ではありませんが、どういう場合にこうなるのでしょうか？

    ジョブは起動時に、ノードグループ内の当該動作環境で稼働しているジョブ数が最も少ないノードで起動されます。従って、それらのノードが他の動作環境にも属している場合、全体のジョブ数が均等になるとは限りません。また、あるノードで稼働している複数のジョブが他のノードで稼働しているジョブより先に終了した場合など、一時的に各ノードのジョブ数が均等でない状態になります。他の要因としては、ネットワーク障害などで各ノードと動作環境サーバーとの接続が切れた場合に、動作環境サーバーの再起動を実行すると、最初に起動された動作環境サーバーにジョブが集中してしまうことがあります。

  40. ジョブ名を選択するところで、リストボックスから選択すると正常に動作するのに、直接ジョブ名を文字入力すると正常に動作しません。

    以下の点を確認して下さい。

    1. ジョブ名は正しいですか？ (特に半角・全角の違いなど)

    2. 全角の空白がジョブ名の最後についていませんか？

  41. sjPEX_sendtriggerコマンドで、投入していないフレームで使用しているトリガが発行できてしまいます。

    異なるフレーム間で先行関係を持たせる場合や、翌日分のフレームと先行関係を持たせる場合に、まだ投入されていないフレームで使用されるトリガを発行できる必要があるため、このような仕様になっています。

  42. 千手ブラウザで定義していないトリガが、sjPEX_sendtriggerコマンドで発行できてしまいます。

    sjPEX_sendtriggerコマンドは、エージェント側でも実行可能です。エージェント側での定義データのチェックが困難であるため、デフォルトではこのような動作になっています。発行されたトリガは、定義されていないトリガもジョブモニタの[トリガ]タブに表示されます。なお、環境変数を設定することで、千手ブラウザで定義していないトリガに対しての発行を抑止することができます。 定義に存在しないトリガ発行時の動作設定 を参照して下さい。

  43. 起動条件にリソースを使用しているジョブ／ネットがスキップ指定されている場合、リソースは有効でしょうか？

    無効です。リソース指定の有無に関わらず、起動がかかれば直ちにスキップ終了します。

  44. リソースの待ち状態になっているジョブ／ネットを待ち状態から外したいのですが？

    当該ジョブ／ネットに対して初期化を行うことでリソースの待ち状態から外すことができます。初期化後にリソース待ち状態から外されたことは「先行条件状態参照」コマンドによって確認することができます。

  45. リソース指定のあるネットが異常終了したのでネットの初期化をしました。その後、ネット内のジョブ／ネットを再ランして異常終了したネットを稼働させようとしたところ「起動条件が満たされていないので再起動出来ません。」と出力されました。なぜでしょうか？

    リソース指定のあるネットが異常終了した時は、再ランに備えてリソースを獲得したままとなりますが、ネットの初期化を行うとリソースは解放されます。このためネット内のジョブ／ネットに再ランを行っても、上位ネットはリソースを獲得した状態にないため、起動条件は満たされていません。このような時には、ネット内のジョブ／ネットを再ランさせるのではなく、リソースをまだ獲得していない上位ネットに対して再ランを行って下さい。

  46. リソースを用いてネットの排他を行わせようと、以下のようなフレームを定義して実行させたところ、ネットＡとネットＢのどちらも起動待ちとなり稼働しませんでした。なぜでしょうか？

    • フレームＡはネットＡを含み、ネットＡはジョブＡを含んでいる。

    • ネットＡにはリソースＲが、ジョブＡにはリソースＳが指定されており、ジョブＡはフレームの起動から2分後起動するよう開始予定時刻が指定している。

    • フレームＢはネットＢを含み、ネットＢはジョブＢを含んでいる。

    • ネットＢにはリソースＳが、ジョブＢにはリソースＲが指定されており、ジョブＢはフレームの起動から2分後起動するよう開始予定時刻が指定している。

    • リソースＳ，リソースＲのリソース値は1として定義している。

    上記の場合では、ネットＡとネットＢの間のリソース獲得でデッドロックが発生しています。

    先ず、ネットＡとネットＢが起動した時点でネットＡはリソースＲを占有し、ネットＢはリソースＳを占有した状態で、各々の内部のジョブの開始時刻が到来するのを待ちます。ジョブＡ、ジョブＢの開始予定時刻が到来した時点で、ジョブＡはリソースＳを占有しようとしますが、リソースＳはネットＢに既に占有されていることから、リソースを獲得できずにリソースＳの空きを待ちます。同様にジョブＢはリソースＲを占有しようとしますが、リソースＲはネットＡに占有されていることから、やはりリソースＲの空きを待ちます。このようにして相互にリソースを獲得できない状態が発生します。

    リソースは外側のネットから内側のジョブ／ネットという順序で獲得しますので、リソースを用いてジョブ／ネット同士を排他させる場合には、ネットとネット内部のジョブ／ネットといった階層毎に同じリソースを使用しないとリソースの獲得が競合してデッドロックが生じるケースがあります。異なるネット間で同一のリソースを使用している場合、リソースの獲得順序、ジョブ／ネットの起動順序を考慮してデッドロックを回避して下さい。例として、ネットＡとネットＢにはリソースＲを、ジョブＡとジョブＢにはリソースＳを指定するようにします。このように、同じ外側のネットからネット内部に向けて階層毎に同じリソースを指定することでデッドロックを回避できます。

  47. 動作環境サーバーの起動と終了のタイミングは？

    動作環境サーバーは、その動作環境が設定されている(その動作環境サーバーを使用する)フレームが起動するときに起動し、その動作環境サーバーを使用するフレームがすべて初期化されると、終了します。以上の動作を、図を用いて説明します。

    ../_images/image0064.jpg

    • 08:00 フレームＡの起動時刻です。

    • 09:00 フレームＢの起動時刻です。

    • 10:00 フレームＡを初期化する時刻です。

    • 11:00 フレームＢを初期化する時刻です。

    • 12:00 フレームＣの起動時刻です。

    • 14:00 フレームＣを初期化する時刻です。

    • フレームＡでは、動作環境Ｄを使用します。

    • フレームＢでは、動作環境ＤとＥを使用します。

    • フレームＣでは、動作環境Ｄを使用します。

    時間の経過と共に、動作環境サーバーの起動と終了を追ってみましょう。

    1. 08:00 フレームＡ起動に伴い、動作環境サーバーＤが起動しました。

    2. 09:00 フレームＢ起動に伴い、動作環境サーバーＥが起動しました。(フレームＢは動作環境Ｄも使用しますが、フレームＢ起動時に、フレームＡにより既に動作環境サーバーＤが起動していたため、重複して動作環境サーバーＤを起動することはなく、未起動の動作環境サーバーＥが起動します。)

    3. 10:00 フレームＡが初期化されましたが、動作環境サーバーＤはフレームＢでも使用しているため、この時点では、動作環境サーバーＤは終了しません。

    4. 11:00 フレームＢが初期化され、動作環境サーバーＤとＥが終了しました。(フレームＢが初期化されたときに、他のフレームで動作環境サーバーＤとＥは使用されていなかったため、この時点で、動作環境サーバーＤとＥは終了します。)

    5. 12:00 フレームＣ起動に伴い、動作環境サーバーＤが起動しました。

    6. 13:00 フレームＣが初期化され、動作環境サーバーＤが終了しました。

  48. フレームで使用する動作環境サーバーとは、何を指すのですか？

    「フレームで使用する動作環境サーバー」とは、フレームに含まれるネットやジョブに設定されている動作環境で稼働する動作環境サーバーを指します。

  49. トリガの生成、消滅のタイミングは？

    動作環境サーバーの起動、終了と同じタイミングです。 動作環境サーバーの起動と終了のタイミングは？ の回答の動作環境または動作環境サーバーを、トリガと読み替えて下さい。なおこの動作は、イベント待ちトリガ，ファイル待ちトリガおよびフレーム連携トリガで共通です。

  50. 自動サイクル運用で、実行システムが翌日運用日付でスケジュールされてしまったのですが。

    自動サイクル運用を行うシステム中のフレームで、システムの運用基準時刻より前(または、同時刻)に起動時刻が設定されているものがある場合、運用基準時刻の処理が行われた日の翌日日付が、その実行システムの運用日付になります。フレームの起動時刻を、システムの運用基準時刻より後に設定して下さい。

  51. 自動サイクル運用で、前日分の処理が終了していないとき、当日の自動サイクル運用に影響はありますか？

    Senju DevOperation Conductorでは、運用日付が異なれば、同じシステムでも全く別の処理として扱われるため、前日以前の処理の如何にかかわらず、当日分は処理されます。つまり、前日以前の処理は、当日の処理に影響を与えません。

  52. 状態管理サーバーや動作環境サーバーとは、サーバーマシンのことですか？

    状態管理サーバーや動作環境サーバーとは、千手システムが起動するプロセスで、サーバーマシンのことではありません。

  53. 起動条件に開始時刻指定を行っているジョブ／ネットがスキップ指定されている場合、時刻指定は有効でしょうか？

    無効です。時刻に関係なく、起動がかかれば直ちにスキップ終了します。

  54. ジョブの動作環境にSenju DevOperation Conductor 2018以前の x64版Windowsノードを指定し、当該ジョブの起動コマンドとして %Windir%\system32 ディレクトリ以下にあるプログラムを指定してジョブを起動したところ、メッセージモニタに「ジョブのコマンドが存在しません」というエラーメッセージが表示されジョブが起動されませんでした。なぜでしょうか。

    Senju DevOperation Conductor 2018 以前は32bitアプリケーションであるため、x64版Windowsにおける %Windir%\system32 ディレクトリ以下へのアクセスが %Windir%\SysWOW64 ディレクトリへリダイレクトされ、上記の「ジョブのコマンドが存在しません」というエラーが発生する場合があります。このような場合は、千手コマンド sj_cProc64 をご使用いただくことで本問題を解消することができます。千手コマンド sj_cProc64 の使用方法については、 デベロッパーズガイド「千手コマンドの一覧」 をご参照下さい。

  55. テストランで異常時ネットが実行されません。なぜでしょうか？

    テストランでは、異常時ネットを設定したジョブに問題が無い限り異常時ネット内ジョブの正当性チェックは行われませんのでご注意下さい。ジョブに異常があった場合、テストランでは異常時ネットが稼働しますが、本番投入の場合異常時ネットはスキップ終了になります。

  56. 動作環境の環境変数にアルファベットの大文字小文字のみ異なる環境変数名を指定することはできますか？

    ジョブの動作環境にWindowsノードを指定する場合は、環境変数名のアルファベットの大文字小文字が区別されません。アルファベットの大文字小文字のみ異なる環境変数名の環境変数を指定した場合、どちらか片方の値しか有効にならないため、アルファベットの大文字小文字のみ異なる環境変数名は使用しないで下さい。

  57. 運用日付を過去日付でフレームを投入した際に、設定された起動時刻にフレームが起動しませんでした。

    起動時刻の判定では、時刻だけではなく投入されたフレームの運用日付と当日運用日付の比較を行います。そのため、過去日付でフレームが投入された場合、既に起動時刻を過ぎていると判定されるため、運用日付が過去日付の場合は設定された起動時刻は無効となります。起動時刻を有効にするには デベロッパーズガイド「千手コマンドの一覧」 の 「sjPEX_shiftdate－開始予定日付変換－」 コマンドで起動時刻の基準日付を変更して下さい。

  58. フレーム間連携トリガを利用している環境で、いつの間にか連携元のフレームが初期化されてしまいトリガがオンにならなかった

    日替わり処理では過去運用日付のフレームを自動的に初期化・削除します。デフォルトでは7日(運用日付が基準)を過ぎたフレームが対象となります。また、一度トリガがオンになっていれば、連携元のフレームが初期化された場合でもトリガはオフになりません。

  59. 開始時刻の遅延監視と終了時刻の遅延監視が同時刻に検知されるように設定してしまった場合、先にどちらが検知されますか？

    全く同時刻になってしまった場合、どちらが先に検知するかは特定できません。

  60. 分岐ジョブに指定されたスキップ指定により、分岐ジョブとその後続の分岐先ネットがスキップ終了しています。そこで特定の分岐先ネットだけ初期化＆再ランしましたが再度スキップ終了してしまいました。どうすれば分岐先ネットを稼働させることができますか？

    分岐ジョブを初期化し、強制分岐を行ってください。(分岐ジョブを初期化することで分岐先ネットも一緒に初期化されます。)

  61. 時刻によるトリガ設定で自動ONになったファイル待ちトリガの状態がOFFになりました。なぜでしょうか？

    原因として、時刻によるトリガ設定でONの状態になった後に、ファイルの消去を検知したことでOFFの状態に戻ったと考えられます。

10.2.4.4. [その他]

  1. 千手ブラウザの「コマンド」→「千手コマンド」→「ジョブスケジュール」の「管理プロセスの再起動」は、Senju DevOperation Conductorのすべての管理プロセスを再起動するのでしょうか？

    ジョブスケジュールサブシステムの管理プロセスのみです。ただし、パラメータとして「未稼働のプロセスのみ」を選択した場合は、既に起動されているプロセスに関しては、再起動は行われません。

  2. テストランを行うと、正常時コマンドや異常時コマンドは実行されますか？

    実行されませんが、実行されるべきところでメッセージコンソールにその旨を表示します。

  3. ジョブチェッカのフレームチェックタブのテストとジョブモニタのフレームタブにあるテストラン動作はなにが異なるのでしょうか？

    テストランはフレーム単位の実行ですが、ジョブチェッカはフレーム全体または選択されたジョブ/ネットのみに対してチェックすることができます。

    • ジョブチェッカのフレームチェックタブのテスト

      フレームチェックタブのテストでは、ジョブが稼働するノードにおいて、ジョブの起動コマンドで指定されたパス及びモジュールの存在確認と実行権について確認します。なお、このテスト状況はメッセージモニタには出力されません。

      具体的なチェック項目は以下のとおりです。

      1. モジュールが指定されたパスに存在するかどうかの確認

      2. モジュールに実行権限があるかどうかの確認

    • ジョブモニタのフレームタブにあるテストラン

      テストランでは動作環境サーバーを起動し、稼働日カレンダーに従って、ジョブの実行状況をシミュレートします。実際のジョブ実行の代わりにジョブチェッカと同様の確認コマンドが稼働します。なお、イベントトリガ、ファイル待ちトリガおよびフレーム連携トリガについてはトリガは生成されますがトリガの状態は無視されます。

      具体的なチェック項目は以下のとおりです。

      1. モジュールが指定されたパスに存在するかどうかの確認

      2. モジュールに実行権限があるかどうかの確認

      3. フレーム構成の確認

      上記の1. 2.は、2つのチェック項目をクリアすれば正常終了し1つでもチェックを通らなければ終了コード 1 となり異常終了となります。千手センサー指定の動作環境の場合でノードがWindowsノードの場合は、1. 2.の2つのチェック項目のうち1.のチェックのみを行います。 モジュールに実行権限が無い場合でも、1.のチェック項目をクリアすれば正常終了となります。そのためテストランの結果が正常終了でも、実際のジョブ実行時に異常終了となる場合があるため、ご注意下さい。 3.は、動作環境サーバーの起動を確認し起動ができない場合異常終致します。また、稼働日カレンダーの設定に従ってネット/ジョブの起動を確認します。

  4. テストランを行うと、異常時ネットは実行されますか？

    テストランでは、異常時ネットを設定したジョブに問題がある場合のみ、異常時ネットが起動します。ジョブに問題が無い限り異常時ネット内のジョブのチェックは行われません。 また、モジュールが指定されたパスに存在していない場合や実行権限がなく、テストランで異常時ネットが起動する場合、モードが本番の場合では異常時ネットはスキップ終了となります。

  5. テストランを行うと、遅延時アクションは実行されますか？

    実行されません。

  6. ファイル待ちトリガの状態をONにしたあと、千手コマンド「管理情報の参照」の参照対象に 「ファイル待ちトリガ」 を指定して実行すると、該当トリガの状態がOFFと出力されました。なぜでしょうか？

    千手コマンド「管理情報の参照」では、指定されたノードよりファイル待ちトリガ情報を取得しています。そのため、ファイル待ちトリガに指定したファイルの生成・削除以外でトリガの状態が更新された場合は、千手ブラウザやジョブモニタの状態と異なる場合があります。

10.2.5. キャパシティのQ&A

ここでは、キャパシティサブシステムを使用する際の基本的な疑問に対するQ&Aについてまとめています。使用前に一読して下さい。

  1. グラフの画面に、横軸は表示されますが、棒、折れ線グラフなどグラフ自体が全く表示されません。何が原因でしょうか？

    グラフ登録時に選択したサマリテーブルに、モニタリングで登録した監視タスクの履歴データがまだ蓄積されていない事が考えられます。履歴データが蓄積されるまでは、グラフを表示することができません。

10.2.6. コンフィグレーションのQ&A

ここでは、コンフィグレーションサブシステムを使用する際の基本的な疑問に対するQ&Aについてまとめています。使用前に一読して下さい。

  1. ファイルの取得項目で、ファイルは存在するのに取得が出来ません。何が原因でしょうか？

    ファイルサイズが０バイトであるような特殊なファイルの取得は出来ません。ファイル自体の取得は出来ませんが、コマンド実行において、内容を表示させる事が出来る場合は、コマンド実行の項目にて、その内容を取得することが可能です。

  2. 千手マネージャのマシンタイム(日付、時刻)を過去に変更したところ、その後、コンフィグレーションの定義を変更して反映(コンフィグレーション)を行っても、定義の変更が反映されなくなりました。

    マシンタイム(日付、時刻)を変更すると、システムが正常に機能しなくなる場合があります。そのため、マシンタイム(日付、時刻)を変更される際は、「リリースノート」に記載されている時刻変更時の手順を実施して頂けますようお願いいたします。

10.2.7. 千手ブラウザのQ&A

ここでは、千手ブラウザを使用する際の基本的な疑問に対するQ&Aについてまとめています。使用前に一読して下さい。

  1. ジョブスケジュールで、フレーム登録はどうやって行うのですか？

    千手ブラウザでは、システムまたはフレーム単位でフレーム登録が可能です。システム毎の一括登録では、千手ブラウザの ジョブスケジュール → システム の下から対象のシステムを選択し、コンテキストメニューの[実行システムの作成]を実行して下さい。フレーム単位での登録は千手ブラウザの ジョブスケジュール → ネット．定義有効日 から対象のフレームを選択し、コンテキストメニューの[フレーム作成]を実行、または千手ブラウザの ジョブスケジュール → システム →＜システム＞からネットを選択して、[フレーム作成]を実行することにより行われます。

  2. 「反映」とはどのような時に行うのですか？

    定義を追加や変更、削除した場合、項目によりその時点で運用管理サーバーや管理対象ノードに適用されるものとされないものがあります。この場合には、後者を運用管理サーバーや管理対象ノードに適用するために「反映」を行います。詳しくは、各サブシステムの反映についての記述を参照して下さい。

  3. ジョブモニタのランチャートタブで、ジョブ／ネットの状態が「監視対象外」から変化しません。ジョブ／ネットの稼働状態を表示するためにはどうすればよいのですか？

    千手ブラウザでは、デフォルトで同時に3フレームまでの詳細状況を監視することができ、監視対象としたフレームでは、ジョブ／ネットの稼働状態がジョブモニタで詳細にモニタできます。監視対象フレームはユーザーが任意に設定でき、また監視中に対象を動的に切り替えることが可能です。 監視対象フレームの選択方法は、千手ブラウザまたはジョブモニタでメニューから[詳細監視フレーム設定]を選択し、｢監視フレームの設定｣ダイアログにて選択を行う方法と、ジョブモニタの[ランチャート]タブのフレームの「詳細監視」チェックボックスをチェックする方法があります。 フレームの「詳細監視」チェックボックスを用いた場合、既に3フレームが詳細監視されていた時には最も過去に詳細監視を設定したフレームの詳細監視が解除されて新たにチェックしたフレームの詳細監視が設定されます。 監視対象でないフレームでは、ジョブ／ネットの状態が「監視対象外」として表示されます。千手ブラウザにログインした直後は、全フレームが監視対象外であることにご注意下さい。

  4. 「しばらくお待ち下さい」ダイアログの[キャンセル]を押すとどうなるのですか？

    当該処理の応答を待たずにダイアログを閉じます。当該処理は実行されます。

  5. 実行結果ダイアログの[閉じる]を押すとコマンドの実行は取り消しとなるのですか？

    取り消しとはなりません。ただし、ダイアログから実行結果を確認することはできなくなるため、通常は閉じないで下さい。

  6. ユーザーコマンド に登録できるコマンドに制限はありますか？

    GUIアプリケーションは正常に実行できません。

  7. 状態が表示されるプロパティを開きっぱなしにすると状態が変わらないのですが。

    プロパティでは開いた時のスナップショットが表示されます。このため開き直さない限り開いた時の状態が表示されたままになります。

  8. すべてのメッセージを消去しても応答要求メッセージが消えないのですが。

    応答要求メッセージは応答するまで消えません。

  9. ライセンスキー の変更ができません。

    千手ユーザーグループでAdministratorsまたは、Managers権限に所属するユーザーでないとライセンスキーの変更はできません。

  10. 千手ブラウザと千手マネージャの時刻合わせは必要ですか？

    千手ブラウザを起動する前に、できるだけ千手マネージャと千手ブラウザ側のマシン時刻を合わせて下さい。

  11. 千手ブラウザのメニュー項目で、[サーバーへの再接続]と、[状態の再取得]は、どのようなときに使うのですか？

    [サーバー再接続]とは、千手ブラウザとサーバープロセスとの通信が途絶えた場合に選択し接続を回復させるもので、「接続が切れました(ジョブスケジュール又はランブックオートメーション)」とエラーダイアログが表示されたときに行います。

    [状態の再取得]とは、サーバープロセスが管理しているデータを千手ブラウザに送ってもらい表示し直すもので、ジョブモニタやランブックモニタの表示がおかしいときに行います。[状態の再取得]は負荷が大きい処理のため、問題発生時のみ使用するようにして下さい。

  12. 千手ブラウザでは、メッセージモニタが立ち上がっていない状態でも、自動応答コマンドを実行するのですか？

    実行します。千手ブラウザを起動していなくても、自動応答コマンドは実行されます。自動応答コマンドは、運用管理サーバー上で実行されます。

  13. 千手ブラウザのユーザー(千手ユーザー)と千手マネージャのインストール時に登場する千手稼働アカウント("senju"や"root")はどのような関連があるのですか？

    千手ユーザーとOS上のアカウントは全く関連はありません。また、千手ユーザーはジョブスケジュールの動作環境設定時に登録するユーザー名とも関係ありません。

  14. 千手ブラウザから千手ドメインにログインする際のユーザーのパスワードを忘れてしまいました。どうすればよいですか？

    自分のパスワードを忘れてしまった場合は、千手ユーザーグループのAdministratorsグループに所属するユーザーに、自分のパスワードを変更してもらって下さい。

  15. 千手ブラウザを他のアプリケーションといっしょに同一ノードで稼働させたいと思います。この時も、物理メモリの容量はリリースノートに掲載されている推奨値分だけ用意すればいいのですか？

    必要なメモリ容量は、ご使用のシステム環境によって異なる場合がありますので注意して下さい。特に物理メモリが不足すると、Windowsの特性から処理性能が著しく低下します。仮想メモリが不足しない限り千手ブラウザは稼働しますが、パフォーマンスが悪くなることがあります。このような時にも、以下の対処により幾分千手ブラウザの処理の負荷を軽減することができます。

    • 状態表示機能を使用しない。

      各ツール画面は必要のない時には閉じておく。(特にメッセージが大量に出力されている時は、メッセージモニタを閉じておくと効果が期待できます。)

    • 不要なエンティティを削除する。(例：古い運用日付は早めに削除する。)

      また、千手ブラウザを稼働させる時には、使用していない他のアプリケーションを終了させることも、パフォーマンスの向上には効果的です。

    以上の処理を行っても千手ブラウザのパフォーマンスが改善されない、あるいは運用上の理由等により上記の対処が行えない場合は、物理メモリの増設をご検討下さい。

    参考

    物理メモリ不足時のWindowsの特性につきましては、Microsoft社が公開しているチューニングガイドなどを参照して下さい。

  16. 千手ブラウザからWindowsマネージャに接続して、ユーザーコマンドに標準出力をmoreでフィルタするコマンドを指定しましたが、実行結果ダイアログ上では表示が一画面ずつ一時停止をせずにすべて表示してしまいます。

    Windowsマネージャでは実行結果ダイアログ上でmoreコマンドを実行し、表示を一画面ずつ一時停止させることはできません。すべて一度に表示されます。スクロールしてしまった出力を見る場合は実行結果ダイアログのスクロールバーを用いて下さい。

  17. 千手ブラウザで「ライセンスの期限切れが近づいています」のポップアップが表示されたので、新たにライセンスキーを取得し千手ブラウザからライセンスキーを入れ替えました。しかし、他の千手ブラウザで「ライセンスの期限切れが近づいています」のポップアップが表示されました。複数の千手ブラウザを利用している場合、全ての千手ブラウザでライセンスキーを入れ直す必要があるのでしょうか。

    ライセンスキーを入れ直す必要はありません。期限切れの確認は千手ブラウザが保持しているライセンスキーを対象に行われます。千手ブラウザから入れ替えたライセンスキーはマネージャに登録されますが、他の千手ブラウザには反映されません。ドメインのプロパティを開きライセンスキーを反映させてください。(プロパティを開くと、自動的に千手ブラウザに反映されます。)

  18. 異常状態の伝搬方法で設定するアイテムセットとはどのようなときに設定するのですか？

    アイテムセットに指定したすべてのアイテムで異常が発生した場合に、上層のアイテムに異常状態を伝搬する場合に指定します。例えば、メールサービスの下位のアイテムに冗長化された2台のメールサーバー(メールサーバーA、メールサーバーB)が存在するとします。2台のうちいずれかが正常に稼働していれば上位のアイテムであるメールサービスには影響がない場合は、2台のメールサーバーをアイテムセットに登録します。これにより仮にメールサーバーAで障害が発生してもメールサービスは異常となりません。 ただし、メールサービスには影響がなくても、メールサーバーAで発生している障害を検知するために、この場合は警告状態を上層に伝搬します。

  19. 登録できるアイテム数の上限に達したためアイテムが登録できません。まとめて削除する機能はありますか？

    古いアイテムの一括削除機能で、指定された日付より古い定義有効日のアイテムの削除を行うことができます。(詳細は、 古いアイテムの一括削除 を参照して下さい。)

  20. 同じ名称で定義有効日が異なるアイテム定義あります。リレーションモニタで表示した際に、どのアイテム定義が有効になりますか？

    同一名称で、複数の定義が存在する場合、リレーションモニタの表示日付を含んだ過去で一番近い定義有効日が有効になります。ただし、自動生成アイテムの場合、該当アイテムの定義有効日が表示日付を含んだ過去で一番近い最新の自動生成日以外の場合は、リレーションモニタには表示されません。

  21. 監視タスクセットに設定した監視タスクがリレーションモニタで表示されません。なぜでしょうか？

    監視タスクセットに指定する監視タスクは、指定ノードの監視タスクで異常とするを選択した場合はアイテムに設定したノードで監視している監視タスクを、異常とする監視タスクを個別指定を選択した場合は指定した監視タスクの中から設定して下さい。

    上記に当てはまらない監視タスクを監視タスクセットに指定しても、リレーションモニタでは表示されません。

  22. リレーションモニタでツリービューにアイテムが表示されません。なぜでしょうか？

    定義内容が以下のいずれかに該当しないかをご確認下さい。

    • アイテムが無効になっている

    • アイテムの下位のアイテムの関係が無効になっている

    • リレーション定義のアイテムの表示順序が逆になっている

    • リレーション定義の表示設定で必要なアイテムカテゴリ／アイテムが非表示設定されている、または必要なアイテムグループが指定されていない。

    • 指定されている表示アイテムグループに必要なアイテムが登録されていない

    • リレーション定義の表示するアイテムで表示範囲が設定されている

    • 表示日付で有効な定義有効日のアイテム定義が存在しない

  23. リレーションのシミュレーション結果をクリアするにはどうすればよいでしょうか？

    リレーションモニタの[ツール]メニューの[シミュレーション]を選択するか、ツールバーから[シミュレーション]を実行し、シミュレーションの条件設定ダイアログで結果をクリアしたい条件を削除して[OK]ボタンを押して下さい。