Web アプリ プロジェクトの初期段階で、ログ ソリューションとして Nlog を使用することに決めました。コード内でロガー クラスを呼び出すだけで、何をどこにログするかを実行時に決定するというアイデアが気に入っています。次に、このアプリを Windows Azure の Web ロールでホストして、すべての機能を活用することにしました。今、Nlog は私が思い描いていたようには機能しないことに気付きました。変更によって発生する問題は次のとおりです。
- フォルダーは読み取り専用であるため、標準のログ フォルダー内のテキスト ファイルにログを記録することはできません。プロビジョニングされ、リサイクル時に消えます。
- これらの構成ファイルは読み取り専用であるため、実行時に出力の構成方法を決定できるという Nlog の最も強力な機能を利用できません。
ログを記録する場所の問題に対するいくつかの解決策を見つけました。Azure Diagnostics テーブルまたはロールのテーブル ストレージにログを記録するようにターゲットを構成します。これは私たちがしなければならない方法かもしれませんが、単一のテーブル (ロールの診断またはカスタム テーブル) にしかログを記録できないように見えるため、非常に制限があるように思えます。誰もがより良い解決策を知っていますか? AzureSQL データベースへのログ記録はコストがかかりすぎます。
また、構成ファイルを編集できない場合に、一時的にデータベースや SMS、電子メールなどにログを記録したい場合、Nlog を構成するにはどうすればよいでしょうか。ServiceConfiguration.cscfg ファイルに情報を保存でき、実行時にアクセスして編集できることは知っていますが、知る限り、それは Nlog 構成のオプションではありません。すべてのインスタンスに対してデプロイされた web.cfg または Nlog 構成ファイルを編集する方法はありますか?
これらの制限があるため、Nlog を使用するのをやめて、より互換性のある別のログ方法を使用するのが最善でしょうか?