実行ログ(トレースログ)/エラーログ/など種類は幾つか在ります。クラサバ・アプリケーションの本番稼動後のログを考えてみます。
開発時のトレース/ログはロジックの追跡、冗長/重複部分のチェック,処理時間の妥当性のチェックやデバッグに使うことが多いと思いますし、開発スタイルに応じてログの定義の仕方も異なるので、省きます。
業務的にみてログを追跡する場面の大半は正常ではない結果が生じたときの追跡ではないでしょうか。正常終了していれば,ログの最終結果を確認すれば良いでしょうから追跡することはありません(断定できないケースもあるかもしれません....)
後述しますが、正常な流れのなかで生ずるロールバックもあります。(理解を得にくい時もありますが)
端末が立ち上がらない時は物理的故障/OSの故障でしょうから、アプリログの範囲外 : 端末管理者の管轄 => ログが取れない。端末管理者に対しひたすら叫ぶ
NetWorkが繋がらない/ DBに対するコネクションが繋がらない : ネットワーク管理者/DB管理者の管轄 => ローカル端末にログを吐く仕組みを作って,ログを持参し,管理者にイチャモンを云う。
(上記の2件は,コンセントが抜けていたなど,端末側の落ち度はないものとします。)
アプリが立ちあぶってからのログは, トレースログ をとるか否かは自由なんですが, 可能なように実装しておき、不要な時はCompileOut (Pragmaで) するようにしてます。
例. xxxxルーチン開始. xxxxx処理終了 ..など
DBやリモート資源に対するアクセスはトラブルがつきものなので,失敗したときのログ機能は必須です。
業務アプリの性質上、問題が起こった際に追跡担当者は本部側(サーバー側)もしくは,本部を介してサーバー管理会社になるでしょう。ログの蓄積はサーバー側であるべきだと考えます。
端末側にログを蓄積して,サーバーからリモート取得することも可能ですが,端末にログが残る保証が取り難いです。
ネットワークが切れたり/ RDBがダウンするのはアプリ問題以前の話なので,割愛します
アプリの作りにも依存するのですが, DBのロールバック処理が生じるときは, RDBの重複エラーや,項目エラーなど、エラー時のみ生じると仮定しているアプリを時々みかけます。
DB上の制約エラー/ IOエラー以外で, 業務ルール的に不整合な状態が生じたときにロールバックさせることもママあります。(本来なら事前Checkで防ぐのがベターなのは当然なんですが)
例) スーパーの買い物
買い物開始......トランザクション開始(レベル1)
商品ピッキング
レジ開始...........トランザクション開始(レベル2)
レジ終了
決済不能な事態発生....財布かない/持ち合わせが足りない..
||
V
レベル2のロールバック (商品を一部返品するか,買い物じたいを止めるかで,レベル1の扱いは変わる)
このロールバックは正常処理だと考えています。(アプリ起因の不具合でなくヒューマン起因の不具合)
このような事からもトレースログは残すようにしたいものです。
成功したときにのみログに書くのでは DB_Accessログでなく SuccessLogになってしまい。無意味なログになります。
追跡できてこそのログです。できればサーバー側に蓄積できる仕組みを持ちたいと考えています。
PS.決済不能なのに「売上計上して,そのまま赤伝を切る」という処理をみたことがありますが、絆創膏に思えてなりませんでした。
(POS端連動で商品出庫処理などと絡んでて複雑な事情は察しできますが)
#誤字訂正 "自体"=>"事態"