ho1

どこでエラーを出力するべきか？
では、これらの方法でエラーを出力する処理は、ソフトウェアのどこに記述すれば良いのでしょうか。return true;
}
}
?>

class AppController extends Controller {
function write_log($systemName $level $message){
$ip = 2;
$data = array(
system => $systemName
level => $level
message => $message
client => $ip
created =>
);
$this->History->create();
$this->History->save($data);
}
}

・
・
--- End ---------------------------------------------------------------------------------------------

・Diary 2015/01/11(日) 16:08:55
--- Start -------------------------------------------------------------------------------------------
・

・監査ログ機能設計書
操作ログをはくよ
ユーザID、をログイン時に保持する

エラー処理、ログ処理は、基底クラスにまとめる

一般的なJ2EEフレームワークの呼び出し階層の例
サーブレット -> コントローラー -> 基底クラス -> ぎょうむロジック -> 汎用処理
　 isValiddata
1 サーブレット XXXServlet.doPost() HTTPリクエストを処理する入り口。
2 コントローラ BLInvoker.invoke() フレームワークが、リクエストパラメタから処理すべきロジックを選択し、実行する。MVCモデルのControllerにあたる。
3 業務ロジックの基底クラス BlBase.execute() 業務ロジックすべてに共通する前処理、後処理、例外処理(try ～ catch)、ロギングを行う。MVCモデルのModelにあたる。
4 業務ロジック BlCalc.execute() ユーザー定義の業務ロジック。
5 汎用処理 CheckUtils.isValidData() ユーザー定義の汎用処理。

modelにロギング処理をかくよ
ロギング【 logging 】
ユーザの操作やシステムの稼働状況、ネットワークのアクセス状況などを時系列で記録に残すこと。
記録データのことを「ログ」(log)という。

model ロギング処理どこに mvc
→php参考にするかiyo

コントローラー　は制御担当であって、処理担当では無い。
ビュー　　　　　はもちろん表示担当であってやっぱり処理担当ではない。

ログ出力するのは、model.pm だね

人にエラーを知らせる方法

発生したエラーについて人に知らせる方法には、ソフトウェアの開発者に知らせるための方法と、利用者に知らせるための方法と、２つの種類があります。

ログは、主にソフトウェア開発者がデバッグを行うために、エラーの情報をファイルに出力するものです。クラス名や変数名、値、ファイル名、行番号などを、そのまま出力します。

エラーメッセージは、ソフトウェアの利用者にエラーが起きたことを知らせるために、コンソールやウィンドウに出力するものです。一般の利用者が見て分かるような表現で出力します。利用者がエラーを確認して何らかの操作を行うまで、ソフトウェアの動作を停止させるために、メッセージボックスを使うこともあります。
どこでエラーを出力するべきか？

では、これらの方法でエラーを出力する処理は、ソフトウェアのどこに記述すれば良いのでしょうか。

１つは、ある関数でエラーが発生した時、エラーの出力もその関数の中で行ってしまう、という方針が考えられます。ログの出力は、たいていはこの方針で行われます。

もう１つは、発生したエラーの情報を呼び出し側に渡して、エラーの出力は呼び出し側で行う、という方針も考えられます。エラーメッセージの出力は、たいていはこの方針で行われます。

この２つの方針には、それぞれ利点と欠点があります。

詳細設計書ログ出力
かきのう

・保存する対象データは
操作時刻ユーザID 操作内容

操作内容
ログイン
入力確認

ふぉーまっと
時間ユーザ操作内容
2015/01/15 21:30:30 admin 入力確認ボタン
http://www.slideshare.net/fullscreen/Manabu_Shimohira/vc1-idc-20110120kmt/44
http://www.mdit.co.jp/logauditor/images2/logimage01b.gif
http://www.mdit.co.jp/logauditor/enterprise/
http://itpro.nikkeibp.co.jp/article/COLUMN/20080403/297901/

http://software.fujitsu.com/jp/manual/manualfiles/M080091/J2X14600/05Z200/secu06/secu0041.html
http://software.fujitsu.com/jp/manual/manualfiles/M060015/J2X13110/01Z200/dmins01/dmins018.html
http://infra.makeall.net/archives/1361

ここでは、監査ログ管理機能の構成を設計するために必要な以下の項目について説明します。

・構成例
・ログ収集対象期間
・ログファイルの管理方法ログファイルの転送方法
・必要な設計項目

■ログ収集対象
ユーザID
操作時間
操作内容

■ログふぉーばっと
YYYY/MM/DD　　YYYY：西暦年(～2038)　MM：月2桁(01～12)　DD：日2桁(01～31)
HH:MM:SS　　　HH：時(00～23)　MM：分(00～59)　SS：秒(00～59)

■ログ収集対象期間
監査ログ管理機能では、収集実施日から最大7日前までデータをさかのぼって収集します。
同じ日に複数回収集を行った場合は、前回収集したデータから当日分の差分データを収集します。
例）5/8にログ収集を実施した場合
１ヶ月を過ぎたデータについては、バックアップは取得しない

■ログファイルの管理方法
収集対象となるログファイル内のログレコードを、ログレコードの日付単位に分割して管理します。
例）2006年の5月8日にログ収集を実施した場合
以下のようにデータを分割して管理し

■ログファイルの運用方法
サイクリック（回帰的）な運用とし、ログファイルをローテーションして使用する。
サイクリック運用しているもの
（例）C:¥AppLog¥log_*

古い記録を上書きするサイクリック運用とすることで
ファイルサイズの肥大化を防ぎ、ログ記録スペースが枯渇しない運用とする。
また一定期間（一ヶ月以上）経過したログ情報は消失してしまう。

情報をファイルに保存、ログファイルはサイクリック使用でディスク容量のオーバーフローを防止する

［ログ機能］・イベントログ相当の運用情報をテキストファイルに出力、サイクリック運用を可能

ログファイルは回帰的（サイクリック）に使用される
ファイル名日
↓
log_01 2015.02.01
log_02 2015.02.02
log_03 2015.01.03
・
・
log_29 2015.01.29
log_30 2015.01.30
log_31 2015.01.31
←

http://software.fujitsu.com/jp/manual/manualfiles/M080091/J2X14600/05Z200/secu09/secu0063.html

なお通常「監査証跡」は「ログ」を指すので相手方担当者がイカレだったのだと思う

--