update.アプリケーションエンジニアの多くは、眠れない夜を過ごしたことがあるでしょう。月に一度の...「月末締めバッチ」の日は。そんなデータ量の多い日や、初モノのバッチが動く日でも安心して眠れるためのバッチ設計を考えてみます。ログの設計まず何はなくともログです。したメッセージを出せていれば、専任の人がリカバリ可能にもなるってものです。Audit用のログなど業務要件の強いものを除いては、だいたい3種類に分けるようにしています。プログレスログリカバリログ例外ログ(調査のため)この分類でファイル単位も分けます。ログを必要とする人が、それぞれ異なるからです。プログレスログプログレスログは、特に長時間かかるバッチに対して、現在どのくらいまで処理が出来ているのかを目的として出力します。バッチの定期的なモニタリングと報告の必要が出てきます。「あと何分で終わるんだ。サービス開始までに間に合うのか!?」に応えなくてはならない。そんなときに、1必要なのはどこまで処理できていて、2あと何分かかるのか、です。1,2を出力するためには、処理対象の総件数を取得しておいて、一定間隔(5分目安)ごとにプログレスログが出力されるようにします。残件数とそのチェックポイントまで掛かった時間から、残り時間を算出しログに出力します。総処理対象は500000件で、終了予想時刻は16:10です。10000件(2.0%)処理しました。現時点での終了予想時刻は16:09:51です。20000件(4.0%)処理しました。現時点での終了予想時刻は16:09:52です。30000件(6.0%)処理しました。現時点での終了予想時刻は16:09:52です。40000件(8.0%)処理しました。現時点での終了予想時刻は16:09:52です。2行めで予測時間を出力するためには、バッチの実行時間の実績が必要になります。拙作JobStreamer上でJavaBatchを動かせば、これは自動的に出力されるようになる予定です。リカバリログデータの不整合など、業務として予測できるエラー(主に人的)の場合に出力します。運用と開発の分離は、J-SOX対応のために必須な現場がほとんどだと思います。した場合に、運用だけでリカバリ可能なイレギュラーパターンを事前に準備しておくことが、安心して眠れる夜のためには必要不可欠です。リカバリログは、運用者がログメッセージにしたがって、リカバリ作業を確実に行えるようにするためのものです。提携先システムからのファイルが届いてない場合にログを出力する場合、こういうメッセージをログに出力させます。XXXからのファイルが到着予定時刻03:00を越えても届きませんでした。5:00までに/home/xxx/sales/20151111.md5のファイルが存在すれば、JOB0101_import_salesを再実行してください。5:00を越えて到着しない場合は、連絡ルートAにしたがって連絡してください。例外ログバッチサーバの障害・バッチプログラムの障害と思われる場合に出力します。Javaの場合、いわゆるスタックトレースです。これは保守・開発チームで対応しなければならない類の例外です。通常バッチアプリケーション内ではハンドリングせず、上位のフレームワークまたはバッチコンテナでキャッチしログを出力します。これは通常のLoggerの使い方で、レベルをINFOまたはWARNで出力するログの想定です。その他のログ実運用では、バッチはジョブコントローラで起動しモニタリングすることが多いと思います。その場合、ジョブフローとして一連のバッチの成否を知りたいので、以下のようなジョブコントローラまたは起動用のシェルから検知ログを出力し、ジョブフローの成否にかかわらずメール送信しておくとよいでしょう。