これはなに
読むやつです。読んだのはこれ
https://speakerdeck.com/uzulla/are-you-writing-a-log-or-just-out-a-log
整理
導入
- 概要
- ログは行動とセット
- ログとは？
- アクセスログとか
- これは古来からあるログ
- イベントが起きたときに残す
- 人間や機会が読む
- 構造化されたテキスト
- ログの種類
- アクセスログ
- apatchやphp-fpmから出るエラーログ
- DBに接続できないなどのエラーが出るログ
- アプリケーションログ
- 開発者が設計するもの
アプリケーションログ
- 要件定義
- いつ、どこで、なにが起きたら？
- なにをどうする？ まで決める
- ポイント
- コンテキストを捨てるな
- 再現、調査のための情報を出す
- アクションにつなげる
- 手順書、バグチケのIDを表示する
- ログと監視は紙一重
- 監視をまなぶのもひとつ
- 典型的なコンテキスト・メタデータ
- ファイルと行番号、スタックトレース
- 共通して必要な情報はハンドラで表示する
- monologで表示
- Monlogの実装に学ぶInterfaceのつかいどころ
- DataDogとかなら自動でやってくれます
- アクションが決まると、ログレベルが決まる
- トリアージのためのログレベル
- debug, info, Notice, warning, error, critical, alert, emergency
- 発報場所は？
- コントローラー層、ドメイン層でやるべき
- どう扱われるか？ が判断できる層でやる
- ライブラリ、リポジトリ層とか奥深くでログ出すのは良くない
- ロガーはmonologがよい
- ロガーは複数生成される前提
- ロガーのなかにハンドラを複数突っ込んで、使えるようにするみたいな話っぽい
- ここはMono logの使い方分かんないときついかも。勉強する。
- ログは多重なストリーム
- source（発報）、filter（情報の整形）、sink（記録、通知など）で構成する
- これは多重にできる
- バッチの場合
- cliならそっちの流儀に沿うのがよいらしい？？？
- ここ分からん
- ログを見る
- 即応する
- 通知せよ
- 時間幅でみる、カウントする
- SaaSの機能つかうとよい
メモ、NA
- ログ出す場所
- Exceptionに変数渡して例外の中でやればいいのかな？ と思ってたけど、たぶんキャッチした場所で$e→varして表示するのが良い
- おぎさんのやつ読む
- テストの本でおれがまとめたログのやつ読み返す
- 知らないことば
- stderr
- 分からんこと
- datadogでどこまでできるのか？
- みんなに伝える
- ログは面白い
- 調べたことを発表する、キックオフする
- 設計しがいがある
- ユニットみんなで設計しよう！ 議論しよう！
- LINEでできたらLTSFでも
- DataDogとかからむからのぶにも知らせる