kazuk は null に触れてしまった

C# / .NET 系技術ネタ縛りでお送りしております

System.Web.Management と Azure


ちっとハマッタお話
 
web.config で system.web/helthMonitoring 以下をいじるときで Azure WebRole を使っているときは構成がらみが結構センシティブなんで要注意。
All Events を Trace に振るとかすると、 Development Fabric でWebRoleがぜんぜん起動しなくなったりするから超危険。
 
この辺、Azure はなにやらむちゃくちゃカスタムしている模様なんですが、どういうカスタムしてるか全然情報がなくてこまりまくりんぐ。
 
んで、「唐突に何をって」思う人に向けて話しの展開
 
 
でも言及されてるんだけど、「仮想マシンがクラッシュするとログデータが吹き飛ぶ」(事がある)んですよ。
んで、うちはお金に絡むログデータもあったりしたり、吹き飛ぶことを容認できないケースバイケース要素が非常に多いわけでございます。
なので、絶対吹き飛ばないようにする為に標準の AzureのDiagnosticsMonitorでのログ取りだけでは不十分だったりするわけです。
 
日本におけるAzureの神の一人である酒井さんの本では Queue の使用方法の解説でログを流すサンプルアプリケーションを書いてらっしゃるわけですが、この例はあくまで Queueを使う事を目的としたサンプルなんで「ログを書くことがメイン」なアプリなわけでありますが、Queueはログの出し先としては非常に有用であります。
 
まぁ、詳しくは system.web/helthMonitoring の config リファレンスなんかを見てもらうとしても、 System.Web.Management 配下は「イベントの重要度によるフィルタリングが設定でできる」、「本当に重要なものは即座に処理できる」、「必要であればイベントをどっかへ投げる方法が用意できる or else 用意されている」といいことづくめでございます。
 
要するにログをとりたくなるかも!!って要素は WebEvent 吐いとけ、これ推奨。
んで、重要なログを本当に重要に扱うには WebEventProvider を実装するといいですよ。
んで、何が重要とかはお客やシステムの使われ方によって違うんで、config で構成できる system.web/helthMonitoring は非常に良いわけでございます。
 
仕事で ASP.NET 開発やるならマジ知っとけな名前空間は System.Web.Management 配下って事で AzureQueueWebEventProvider を書いてみたりした今日この頃でありまする。
 
前回の記事も含めてむにゃむにゃProvider しか書いてない今日この頃なんであったりしまする。
 
広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中

%d人のブロガーが「いいね」をつけました。