基礎的なことが網羅されてた。プラクティス集の全項目に対しては完全肯定であり、自分の考えを追記していると明記しておく。自前でログを書くなライブラリを使えprintfは最悪ローテーション機能とかのことも書いてあった。確かに、printfっぽいやつ使うにしてもラッパは必要。意味のあるログメッセージを書こうそうは言ってもという感じがあるこれを実現するには、改善するための情報(おそらく状況の改善)を入れたり、操作の目的を入れる確かにエラーメッセージには、状況とその対処が含まれてることが望ましい重要なこととして他のメッセージとつながっているように出力しないことが挙げられているログレベルの違いで同時に出ない、非同期処理だと順番が乱れる可能性があるので、見にくくなるなるほど。incorrect」とするとコンテクストが分かる確かにという感じ。多すぎず、少なすぎずそれはそうという感じログを出力しすぎて問題が発生することもあるし、少ないと障害特定に結びつかないかもしれない機械によるアシストがあっても、最終的に読むのは人間である。ログは障害調査目的だけではない3つの例が紹介されている監査目的:例えばログイン記録のようなもの。ActiveDirectoryみたいなやつを運用してたりすると、あれねという感じがするプロファイル目的:性能を確認する目的がある。ログは時間も記録する。この時間を使って性能を見ることもできるだろう統計目的:ログを見ることでシステム全体の動作状況が把握できる。センシティブ情報を含めないパスワードがクレジット番号など、ヤバい個人情報はロギングしないデバッグログなどにも含めてはいけないこの辺はどこまでOKか難しいよね。IPアドレスは大丈夫か?とかヤバそうだけどどっかに書いとかないといけない場合は、暗号化してDBに入れようGDPRへのリンクもあった。いえばそれもあったな補足ロギングの記事を書こうとしていた最中に記事を発見してしまったので、上にかかれていなくて、元々書こうとしていた事項も補足しておく。C++にゼロコストのログ削除方法が書いてあったような気がするけど、10年以上前の記憶なので定かじゃないな...クライアント環境で起こった障害ログをどう送るかクラッシュレポートを送ってもらう術がある。iOSだといろんなライブラリを使ったことがあるが、実際のアプリではどれくらい使われているんだろうかwinアプリとかだと障害ログを送ってもらう仕組みも含めたりする(クラッシュレポートか、やりすぎな感じもするけど)必要かどうか。送るまでやらなくても障害情報をまとめる機能があってもいいだろう。F]月別アーカイブスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。