【要約】【C#】ロギング設計の落とし穴（ILoggerの使い方、構造化ログ）【実務向け】 [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発者が標準的なILoggerを「とりあえず」で利用することで、運用フェーズにおいて以下の技術的課題に直面する。
- ・検索性の著しい低下：文字列補間（$"..."）を使用すると、ログが単一の文字列として扱われ、特定のIDでの集計が困難になる。
- ・監視精度の低下：ログレベルの使い分けが不適切だと、重要なエラーが大量のInformationログに埋もれてしまう。
- ・パフォーマンスの劣化：高頻度パスでログを出力すると、無効なログレベルであっても引数の評価やシリアライズのコストが発生する。
- ・セキュリティリスク：パスワードや個人情報がそのままログに記録され、機密情報の漏えいを招く恐れがある。
- ・デバッグ情報の消失：例外再スロー時に "throw ex;" を使用することで、本来の発生箇所を示すスタックトレースが失われる。
// Approach
本記事では、ログを検索・集計可能な「データ」として扱うための具体的な設計手法を提示している。
- ・構造化ログの採用：メッセージテンプレートとパラメータを分離し、ログ基盤でのフィルタリングを可能にする。
- ・ログレベルの厳格な運用：Warning、Error、Criticalを状況に応じて使い分け、アラート検知を容易にする。
- ・ソース生成ロガーの活用：[LoggerMessage]属性を用い、高頻度パスにおけるログ出力コストを最小化する。
- ・機密情報の保護：ログ対象からの除外や、マスキング処理の徹底を推奨している。
- ・例外処理の適正化：例外オブジェクトをログに渡し、再スロー時は "throw;" を用いてスタックトレースを保持する。
// Result
これらの設計指針を導入することで、開発者は運用監視の精度とシステムの安定性を向上させることができる。
- ・運用効率の向上：Application InsightsやElasticsearch等の基盤で、特定のOrderId等を用いた高度なクエリが可能になる。
- ・リソース消費の抑制：LoggerMessageの利用により、高負荷環境下でのボクシングやシリアライズのオーバーヘッドを削減できる。
- ・障害復旧の迅速化：正確なスタックトレースと適切なログレベルにより、MTTR（平均復旧時間）の短縮が期待できる。
Senior Engineer Insight
> 大規模システムにおいて、ログは単なる記録ではなく「観測データ」である。文字列補間による構造化ログの放棄は、運用コストを指数関数的に増大させる。特に低レイテンシが求められる高頻度パスでは、LoggerMessageによる最適化は必須要件だ。また、throw ex;のような初歩的なミスが、障害復旧を遅らせる致命的な要因となる。設計段階でこれらの規律をプロジェクトの標準として組み込むことが、技術責任者の責務である。