AzureでKUSANAGIのアクセスログやエラーログを解析したい

AzureにはAzure Monitorと言うツールが有り、その要素の中にLogAnalyticsと言うツールが有るのですが、意外とこれが使いこなすのが難しい。KQLというクエリ言語を使わないとログの抽出ができないし、ダッシュボードの作成も基本的には手作りというのは、なかなか他社監視製品だとない文化であり、とっつきにくいなぁという感じがしています。

今回学んだのはカスタムフィールドという機能でして、所謂フィールドを細分化する機能です。
例えば今回カスタムログ機能を使用して、Linux VMから抽出したログはこんな風になっています。

実はログの中で重要なメッセージは全部RawDataというフィールドに一括で蓄えられています。でも実際統計を取りたかったりする場合、その中のフィールドを細分化しないと色々辛いんですね。

parseというコマンドで対処する方法も

こういう時、まずはKQLだけでなんとかできんかな？と考えてやるとしたら以下の方法があります。

KUSANAGI_ACCESS_LOG_CL
| parse RawData with * Request_Time " " Sent_f_cache " " Remote_Addr " - " Remote_User " \[" Generate_Time "\] " "\"" Method " " Path " " Version "\" " Response_Code " " Body_Bytes " \"" Referer "\" \"" UserAgent "\" \"" X_Forward_For
| project Generate_Time, X_Forward_For, Path, Method, Referer, UserAgent, Response_Code,

すると、後半に実行したprojectコマンドによりparseされた名前に基づくフィールドを展開することが可能になります。ただこれ弱点があって、

ダッシュボードが作れることは作れるのですが、例えばテーブル表示された「すべて表示」と言うリンクをクリックすると結果が出てきません。原因は、統計取ってるフィールドがあくまで「ビュー」に過ぎず、正式なテーブルのカラムではないからです。

そこで、登場するのがカスタムフィールド

ということで、カスタムフィールドの扱いについて記載したいと思います。
まず必要になるのは、元のテーブルを表示させ、レコードを1つ展開します。

上図にある赤枠箇所をクリックしていくと、フィールド抽出画面が表示されるようになります。

すると、画面左側でログレコードの1つが上図のように展開されますので、「何を拾うのか」をドラッグして指定します。

フィールドの末尾には_CFと言う文字列が付与されます。なお、ハイフンは使えません。アンダースコアを使用してください。加えて、フィールドの種類でそれが文字列（テキスト）なのか、数字なのか・・などの指定を行って「展開」をクリックします。すると、下図のようにサンプリングを行い、文字列が正常に検出できたかどうかが確認できます。

一発でうまく行けばいいのですが、世の中そんなに甘くなくて、正常に検出できなかったり、異なるフィールドを指定してしまったりと言うことが起きるので、検出パターン飲み直しをさせる必要があります。その場合は、下図のように想定どおりにかなかった箇所の右側にあるアイコンをクリックして正しいパターンを指定します。

なお、検出できなかった行は灰色表示されます。下図の例のようにアイコンをクリックして「この強調表示を変更する」を選択します。なお、実際にその対象フィールドに見合う値が存在しない場合は「これらのような結果を無視します。」を選択する、もしくはなにもしないのいずれかの手段を取る必要があると思われます（というのも、ここの具体的な動作は確認しきれなかった・・）

そうして一通り検出ができそうであることが確認できたら「抽出条件の保存」と言うボタンをクリックします。するとこの抽出条件が保存され、以降取り込んだログはこの抽出条件を用いてRawDataを分解してくれるようになります。

作成したカスタムフィールドの確認

作成したカスタムフィールド情報は「詳細設定」⇒「Data」⇒「カスタムフィールド」で確認ができます。ところでこれ、カスタムフィールドは修正できないんだろうか？と言うところがじつはよくわかっていなくて、このあたりは継続して調べようかなと。再作成だとちょっと辛いな・・・

反映には少し時間がかかります

実は設定したらそれ以降はカスタムフィールドが反映されると言ったわけですが、数十分程度タイムラグが有るように感じられました。また、過去のログにさかのぼって反映してくれるわけではなさそうで、その辺りのログを同じような感覚で解析したい場合は、先述したようなparseコマンドをKQLに突っ込んで、フィールドをバラすのが取れる方策ということになるのかなと思います。

上図のタイトル行を見ていただくと分かるのですが、カスタムフィールドが他の要素と同じように表示されるようになります。カスタムフィールドを使った場合、その列形式はテーブル構成情報にマージされるので、普通にKQLに混ぜ込んで使えるようになります。

警告発報や統計確認で非常に役に立つ

本ちゃんはこれから・・・と言う感じではあるんですが、列をばらして何が嬉しいかって、統計グラフがもう少し緻密に作れること、後、条件式の組み方が楽になることじゃないでしょうか。数値なのか文字列なのかの区別もつけられるので。

LogAnalyticsはたとえばJP1やHinemos、SystemWalkerのような国産ツールに慣れた人にはちょっときついのかもしれないです。が、独特の癖に慣れたらだいぶ使いやすくなるし、カスタマイズ機能に対するポテンシャルは国内製品より圧倒的に高いので、ちょっと取り組んでみると、リプレイス対応する際の要件定義・基本設計でだいぶ高度なものも検討できるかなと思うので、ぜひ評価版さわれる機会があれば触ってみたほうがいいかなーと思いました。