ログ設計の目的
・障害発生時に発生原因や障害影響を対処しやすくするため
・障害発生時に発生原因や障害影響を調べるため（障害対応）
・監査対応時に業務状況を証明するため（監査対応）
インプットとなる成果物
「個人開発 Habitica-外部連携 概念設計」
4.ユースケース記述/自前で実装する機能/バッチ処理側
参照
成果物
API取得するまでの流れ
DBに書き込みの流れ
ログフォーマット
| 項目名 | 値 | 説明 |
|---|---|---|
| 日時 | YYYYMMDDhhmmss | メッセージの出力日時 |
| レベル | INFO もしくは WARN もしくは ERROR | メッセージの分類 |
| メッセージID | 個別 | |
| メッセージ | 個別 |
ログ出力先
task_collect_tool/src/batch/Habitica/task/log.txt
ログ出力タイミング
・処理が完了したとき
・処理の途中で例外処理が発生した時に発生する。
メッセージ分類
| 分類 | エラーコード | 備考 |
|---|---|---|
| エラー | Error | 処理が中止される場合に出力される（例外）今回の場合はシステム上の例外のみ |
| 警告 | Warning | |
| 通知 | Info | 正常処理のメッセージ |
ログメッセージ一覧
| 分類 | エラーコード | エラーメッセージ | 備考 |
|---|---|---|---|
| Error | 28P01 | データベースアクセスです。 | PostgreSQLの標準エラーを利用 |
| Warning | 23505 | 主キー重複エラーです。 | PostgreSQLの標準エラーを利用 |
| Error | 42P01 | 対象のテーブルが存在しません。 | PostgreSQLの標準エラーを利用 |
| Error | 22XXX | カラムに入る値と型が異なります。 | PostgreSQLの標準エラーを利用 |
| Error | 08003 | クエリタイムアウトエラーです。 | PostgreSQLの標準エラーを利用 |
| Error | 001 | ネットワークが繋がっていません。 | HTTP403 |
| Error | 002 | Habiticaのアクセスキーが違います。 | HTTP401 |
| Error | 003 | レスポンスの取得結果が１件もありません | HTTP200 |
| Error | 004 | レスポンスの形式があっていません。 | HTTP200 |
| Info | 005 | 処理が完了しました。 |
クラス図
感想
例外設計とログ処理がごっちゃになってますね。
後日しっかりブラッシュアップします
各外部連携方法（ファイル、DB,API）の異常系処理を洗い出して、アクティビティ図にまとめておく良いと思いました。
（毎回明確な基準がないまま進めてるから、時間もかかるし漏れあるし）
参考書籍
ログフォーマット ログ出力先
書籍：システム設計の謎を解く p253
ログ管理 運用
書籍：運用設計の教科書 4.6ログ管理
postgresqlのエラーについて