ログは「記録」ではなく「武器」である。VB.NETにおける構造化ログ基盤の極意
多くのVB.NET開発者が、いまだに`System.Diagnostics.Trace`でコンソールやファイルに文字列を垂れ流している。あるいは、自作の`WriteLog`関数をモジュールに書き、テキストファイルへ追記するだけの「死んだログ」を運用している。
断言しよう。その設計では、本番環境で発生する「再現性のないバグ」を解決することは不可能だ。
本稿では、レガシーなログ出力から脱却し、NLogを用いた構造化ログ基盤を構築するための思考法と実装コードを伝授する。
—
1. なぜ「自作ログ関数」が地獄への入り口なのか
多くの開発者が自作のログ関数を作る理由は「手軽だから」だ。しかし、以下の問題に直面したことはないか？
- 排他制御の欠如: 複数スレッドから同時書き込みが発生した際、ファイルロックで例外が発生し、肝心のエラーログが残らない。
- 検索性の欠如: ログがただのテキストの羅列であり、後から特定のユーザーやエラーIDで絞り込むのに膨大な時間がかかる。
- パフォーマンス低下: 同期的にファイルI/Oを行うことで、アプリケーションの応答速度を殺している。
NLogは、これらの問題を「設定」だけで解決できるプロフェッショナルな道具だ。
—
2. NLogによる構造化ログの設計
構造化ログとは、ログを「文字列」ではなく「データ（JSON等）」として扱うことだ。これにより、ELKスタックやAzure Monitorなどのツールで瞬時に分析が可能になる。
NuGetでの導入
プロジェクトのパッケージマネージャーコンソールで以下を実行せよ。
Install-Package NLog
構造化ログの設定 (`NLog.config`)
アプリの直下に`NLog.config`を配置する。ここで重要なのは「レイアウト」の定義だ。
—
3. 実践：保守性の高いログ出力クラスの実装
ビジネスロジックの層で、いちいち`NLog`のインスタンスを生成してはいけない。シングルトンパターンを適用したロガーラッパーを介するのが、大規模開発の鉄則だ。
Imports NLog
Public NotInheritable Class LoggerProvider
‘ スレッドセーフなシングルトン
Private Shared ReadOnly _logger As Logger = LogManager.GetCurrentClassLogger()
Private Sub New()
End Sub
‘ 構造化ログを意識したインターフェース
Public Shared Sub LogError(message As String, ex As Exception, ParamArray properties As Object())
‘ 構造化データとしてプロパティを付与する
_logger.Error(ex, $”[Context: {String.Join(“,”, properties)}] {message}”)
End Sub
Public Shared Sub LogInfo(message As String)
_logger.Info(message)
End Sub
End Class
呼び出し側のコード
Try
‘ 重大な業務処理
Dim result = ExecuteBusinessLogic()
Catch ex As Exception
‘ ユーザーID等のコンテキスト情報を埋め込んで記録する
LoggerProvider.LogError(“業務処理で予期せぬ例外発生”, ex, “UserID: 12345”, “Module: OrderSystem”)
Throw ‘ ログを吐いた後は例外を再スローし、呼出元へ制御を返すのが鉄則
End Try
—
4. 伝説的エンジニアからの「極限の知見」
最後に、現場で生き残るための3つの鉄則を授ける。
1. ログは「非同期」で書け:
ファイルI/Oは本質的に遅い。NLogの `AsyncTargetWrapper` を使用し、メイン処理のボトルネックにならないよう設計せよ。
2. 例外は「握りつぶすな、再スローせよ」:
`Catch` ブロックでログを出力した後、何もしない（あるいは `Return` する）のは悪手だ。呼び出し元のスタックトレースが途切れ、バグの根本原因が永久に見えなくなる。
3. 機密情報を絶対に出力するな:
パスワードや個人情報がログファイルに紛れ込むと、それはセキュリティインシデントだ。構造化ログであれば、特定のフィールドをフィルタリングする設定も容易である。
結論
ログは、プログラムが「死の間際」に書き残す遺言だ。その遺言が読みづらければ、開発者は原因を特定できず、ただ途方に暮れることになる。
「動けばいい」コードから「解析できる」コードへ。今日からNLogを導入し、あなたのアプリケーションを、真に運用可能な「プロダクション品質」へと引き上げてほしい。
質問があればいつでも受け付ける。ただし、安易なコード改善を求める前に、まず今のコードがなぜその設計なのか、論理的に語れるよう準備しておくことだ。
