skillup

技術ブログ

プログラミング全般

ログの設計指針について

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

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

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

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

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

絶対入れる情報

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

レベル分け

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

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

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

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

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

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

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

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

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

出す場所

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

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

参考URL

ログ設計指針

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

執筆者:


comment

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

関連記事

no image

APIに関して

RESTAPIのルーティングで気をつけることなんぞを。 直近のプロジェクトではRESTAPIを作ることが多かったんですが気をつけることなんぞを。 Contents1 仕様書はソースから2 ツール3 命 …

no image

Excelでのテストデータ作り

ExcelVBAでテストデータを作るときに役に立った関数などを紹介させていただきます。 user_id time 2143 2017/1/16 3:35 6724 2017/1/2 6:05 4528 …

no image

1度に1つのことを

今回のリーダブルコードの概念はやや抽象的。 要は一度に行うタスクは1つにする、というところがポイントになります。 そのための手法として下記のようなことを上げています。 コードが行っているタスクをすべて …

no image

emptyの扱いに関して

PHPで空白や存在確認として便利なemptyですが、乱用すると意図しない動きをすることがあるケースが多々あります。 Contents1 emptyの挙動に関して2 数値の03 検索などの全判定と値のな …

no image

トークン認証に関して

Contents1 トークンでの認証2 Laravelでのtoken トークンでの認証 APIアプリケーションを作る場合、認証方式としてはクッキーとセッションを利用したものよりもトークンを使った認証方 …