skillup

技術ブログ

プログラミング全般

ログの設計指針について

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

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

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

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

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

絶対入れる情報

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

レベル分け

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

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

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

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

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

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

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

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

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

出す場所

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

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

参考URL

ログ設計指針

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

執筆者:


comment

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

関連記事

no image

コードの抽象化

リーダブルコードも終盤に少しずつ近づいてきました。 今まではどちらかというとコードの点や線の技術に注目してきましたが、これからは面的な要素に注目していきます。 リーダブルコードでは「無関係の下位問題を …

no image

バッチスクリプトで気をつけたい点

実務でバッチ処理を作る際に気をつけるべきと思ったこと。 基本的にエラーをいかに捉えていかにログに吐くかを最初に考える。まずはエラーありき。失敗するもの、想定した値がこない、あるいは値がないを前提として …

no image

命名規則について

リーダブルコードシリーズ第2段、名称について。 コードにおいては名称がとても大切で、正しい命名づけなどはなかなか難しいです。 以下に大事で重要だと思ったポイントを。 Contents1 具体的でわかり …

no image

リーダブルコードまとめ

リーダブルコードほぼ読み切ったのでまとめを。チェックリスト化して、常にこれを見ながらコードは書いたほうがよさげ 前半のまとめや参考リンクでみたものとマージします。 Contents1 変数の名称2 コ …

no image

Simple Factoryパターンについて

今回はデザインパターンの一種であるSimple Factoryパターンに関して。 Contents1 Simple Factoryパターンとは2 サンプルコード3 解説 Simple Factoryパ …