こんにちは。ES/1 Shelty担当の大朝です。
ES/1 Shelty 3.2.0において、JP1/AJS3に関連する一部の機能を強化しました。
本記事では、下記の3点について順にご紹介いたします。
非時系列グラフのインスタンス数拡張
ジョブスケジュールマップのCSVダウンロード機能
ジョブネットの閾値監視
これまでの非時系列グラフは、障害調査やジョブ実行傾向の分析に利用されるケースが多く、特にAJSのジョブネット単位での追跡では「10件では比較対象が不十分」という声が寄せられていました。
また、ネットワーク機器・リソース監視カテゴリでは、1つの監視対象が多数のインターフェースやプロセスを持つことも多く、表示可能件数が制限となり、調査に手間がかかる状況がありました。
このような背景から、より現場の分析作業に合った形で情報を確認できるよう、3.2.0では選択可能なインスタンス数を10件から20件へ拡張しました。
さらに、統合ダッシュボード画面（INTDASH）＞ダッシュレットを開く ＞ オプション ＞ TopN件においても、最大20件まで選択可能になりました。
これにより、例えば下図のように、分析対象としてジョブネット20件を指定した上で、その中から上位15件のみを抽出して表示するといった、より柔軟な分析が可能になりました。
また、以下のカテゴリについても選択できるインスタンス数を10から20に変更しました。
Ping性能情報
プロセス・ユーザ毎のリソース使用量（プロセス単位 Linux）
プロセス・ユーザ毎のリソース使用量（ユーザ単位 Linux）
プロセス・ユーザ毎のリソース使用量（プロセス単位 Windows）
MIB-2（インターフェース情報）（対象機器IP単位）
MIB-2（インターフェース情報）（インターフェース単位）
MIB-2（インターフェース情報64bit）（対象機器IP単位）
MIB-2（インターフェース情報64bit）（インターフェース単位）
ジョブスケジュールマップ画面（JOBSCHD0）において、画面表示内容をCSV形式でダウンロードできる機能を追加しました。
ジョブネットおよびジョブの実行状況をCSV形式で出力できます。
なお、 画面上でフィルタが行われていた場合、フィルタ後の表示がそのままCSVに反映されます。
画面右上の「CSVダウンロード」ボタンをクリックすることで、画面上に表示されているジョブネットおよびジョブの実行状況をCSV形式で取得できます。
■ジョブネット
ファイル名：ジョブネット_YYYYMMDD_hhmmss
ファイル日付：ダウンロード操作の実行日時
時刻：YYYY/MM/DD hh:mm:ss ※異常により値が不明なものは「―」と表記
■ジョブ
ファイル名：ジョブ_${ジョブネット名}_YYYYMMDD_hhmmss
ファイル日付：ダウンロード操作の実行日時
時刻：YYYY/MM/DD hh:mm:ss ※異常により値が不明なものは「―」と表記
ジョブスケジュールマップは、ジョブ全体の流れや実行状態を俯瞰する際に活用できます。
今回の改善により、以下のような場面でさらに便利にご利用いただけます。
フィルタ後の結果をそのまま資料化したい
取得したデータを二次加工して利用したい
日次・週次レポート作成を効率化したい
従来は、手作業で画面の情報を転記したり、キャプチャ画像で代用したりするケースが多く、情報共有に時間がかかる点が課題となっていました。
本改善により、画面で確認している内容をそのままCSVで保存・共有できるようになり、運用効率の向上が期待できます。
JP1/AJS3のジョブネット情報をもとに、処理時間・終了状況・遅延状況などの閾値監視が可能になりました。
総ジョブ件数（未終了ジョブも含む）
終了ジョブ件数（正常・警告・異常の合計）
正常終了ジョブ件数
警告終了ジョブ件数
異常終了ジョブ件数
未終了ジョブ件数
総ジョブ処理時間（終了したジョブの実行時間）
総ジョブ処理時間（正常終了）
総ジョブ処理時間（警告終了）
総ジョブ処理時間（異常終了）
ジョブネット開始遅延件数 ※JP1/AJS3の追加設定が必要
ジョブネット終了遅延件数 ※JP1/AJS3の追加設定が必要
ES/1 Sheltyでこれらに閾値を設定することで、時間超過・未終了・遅延・異常終了の増加など、様々なパターンを検知できます。
設定前に、あらかじめご確認いただきたいポイントが2つあります。
1つ目は、閾値監視を行うには、データ集約機能をオンにしている必要がある点です。
2つ目は、JP1/AJS3のログ仕様とES/1 Sheltyのデータ集約タイミングの関係により、「実際のジョブイベント発生」と「ES/1 Sheltyが閾値判定を行うタイミング」にはタイムラグが発生する場合がある点です。
下記でその理由をご説明いたします。
ジョブネットの「開始」「終了」「開始遅延」「終了遅延」のログはそのイベントが起こったタイミングでログに出力されます。
ES/1 Sheltyはこのログを読み、毎時10分に集約データを生成します。（例9:00-10:00のデータを10:10に集約)
ここで重要なのがES/1 Sheltyの閾値判定は「集約データ」に対して行われるという点です。
つまり、閾値判定は集約データが作成されるタイミングまでは実施されません。
以下では具体的なユースケースをもとに、どのような場面でどの程度のタイムラグが生じるのかに加えて、ES/1 Sheltyでの閾値設定例を解説いたします。
● いつ検知されるか？
1. ジョブネット1の「開始」は9:00で、「終了」は9:45である
2. ES/1 Sheltyで9:00台の集約データは、10:10に作成される（毎時10分）
3. ES/1 Sheltyの閾値検査は、次の11:00の検査タイミング実行される（毎時検査）
4. ES/1 Sheltyで異常を発報するのは、上記の11:00のタイミングとなる
● 閾値設定例
総ジョブ処理時間 ＞ 2,700 秒（45 分）
→30分で終わるはずのジョブネットが45分以上かかった場合に検知されるが、実際のイベント終了（9:45）より最大1時間程度の後（11:00頃）の検知となる。
こちらのパターンは、ES/1 Sheltyの「総ジョブ処理時間」の閾値では検知できません。
● いつ検知されるか？
1. ジョブネット1の「開始」は9:00で、「終了」は10:35である
2. 9:00の開始ログはES/1 Sheltyに取り込まれる
3. ES/1 Sheltyで9:00台の集約データは、10:10に作成される（毎時10分）
この時点では、ジョブネット1は 「未終了ジョブ」 として集約される
4. 10:30を過ぎて終了ログが取り込まれる
5. ES/1 Sheltyで10:00台の集約データは、11:10に作成される（毎時10分）
しかし、9:00台の集約データは更新されない
6. 次の11:00の閾値検査（毎時検査）で判定が行われ、そのタイミングで 「未終了ジョブ」として異常が発報される
→「未終了ジョブ」として9:00台の集約データに格納され、実際に発報されるのは集約後かつ次回検査となる11:00頃となる。
● 閾値設定例(ES/1 Sheltyで検知する方法)
1. 未終了ジョブ件数 ＞ 0
2. JP1/AJS3側で「終了遅延ログ」を出すように設定した上で、ES/1 Sheltyで遅延件数を監視
極端に短い処理時間を検知する例です。
● いつ検知されるか？
1. ジョブネットの開始・終了ログはいずれも9:00台に発生する
2. ES/1 Sheltyで9:00台の集約データは、10:10に作成される（毎時10分）
3. 次の11:00の閾値検査（毎時検査）で判定が行われる
4. ES/1 Sheltyで異常を発報するのは、上記の11:00のタイミングとなる
→終了が早すぎても遅すぎても、判定は集約データ作成（10:10）後の11:00 の検査時となるため、①と同じタイミングで発報される。
● 閾値設定例
総ジョブ処理時間 ≦ 1秒
以上がユースケース別にみたタイムラグ発生の仕組みとES/1 Sheltyでの閾値設定例です。
本記事でご紹介した機能強化により、JP1/AJS3連携における情報の把握や分析作業がより効率的になります。
ES/1 Sheltyは今後も、日々の運用で発生する「ちょっとした困りごと」の解消につながる機能改善を行っていきます。
お困りの際はサポートSEまでお気軽にお問い合わせください。