skillup

技術ブログ

プログラミング全般

ログの設計指針について

投稿日:2020年9月22日 更新日:

今まで10以上近い現場で仕事をしてきましたが、どの現場でも絶対必要になる(かつどこもあまり対策が取られていない)技術としては

  • 検証したい状態の復元がすぐにできる(テストデータ作成)
  • ログの適切な設計
  • エラーハンドリング

でしょうか。おそらくあと10年たっても変わらないと思います。

いつもテストデータやエラーについては色々言っていたので、ログの設計に関して。

絶対入れる情報

時間ともし取得できればファイル行数

レベル分け

出すぎても、少なくすぎてもダメですね。

一般的にはざっくりDEBUG、INFO、WARN、ERRORぐらいに別れますかね。

個人的には下記のようにざっくり分けております。

DEBUG ・・一番詳細な情報。SQL、テキストエリアの文言、リクエストパラメーターなど全てだすと情報が多すぎて追い切れないところまで。詳細な調査をしたい時に見る情報。

INFO ・・メソッドの開始、終了など。処理がどこまで進んだか、どこで止まったかがわかるもの。開発時にはこれが指針となる。

WARN・・非推奨のメソッドやエラーではないが直しておきたい部分。

ERROR・・明らかにエラー、状態がおかしい時。

こんな風に分けてますが、実際に開発をしたり、運用をしていく上でレベルを調整していくのがいいかと思います。

個人的には開発時にはDEBUGとINFOの使い分けが大事で、運用時にはERRORの設計(漏れがないか)が大事だと思っています。

出す場所

開発時・・INFO以上を標準出力、運用時はWARN以上を標準出力にし、それ以下はファイル出力へ。

常時見る場所と、調査をしたい場所を使い分ける感じで。

参考URL

ログ設計指針

-プログラミング全般
-, ,

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

no image

ログのまとめに関して

何回か書いたログの設計方針に関して再度復習。 ログ設計指針について ログで大事なことを再度復習 DEBUG(SQLやパラメータ情報など詳細な情報までだす)、INFO(メソッドの詳細情報、開始と終了)、 …

no image

例外・エラーに関する考察

えー今現在、設計の仕事をしていますが、今までいい加減だったエラーの処理を見直すいいきっかけになってます。 半年前にも同じような記事書いてますねー。苦手意識は変わらないようです・・(汗) 例外処理に関し …

no image

ExcelVBAでの他のアプリの起動

2日続けてExcelVBA。 やはり細かく分けてすぐにプロシージャごとにテストできるのはものすごく大きなメリットですね。本日は別のアプリ起動と操作に関して。 自分がやったことはWordとメモを起動して …

no image

webの仕組み その2 リクエストとレスポンス

クライアント(ブラウザ)はサーバーとの接続を確立した後、各種リクエストを送信します。サーバーはそれにこたえテキストや画像などのリソースをクライアントに転送します(これがレスポンスです。) Firefo …

no image

新しいプロジェクトに入った時にやること

新しいプロジェクトに入った時に最初にすべきことややっておくことなど Contents1 仕様理解編1.1 ユーザーの行動遷移の理解1.2 キー系のデータの理解1.3 データグルーピング1.4 サンプル …

アーカイブ