こんにちは、上村です。普段は主に Azure のクラウドインフラ構築を担当しています。
この記事で取り上げるのは、昨年一般提供となった
Azure Monitor ログのインジェスト時の変換機能
です。
Azure を利用していれば、リソースのログを取得して Log Analytics ワークスペースに送っておく、という設定は何かと触る機会があるかと思います。
その時に変換という機能を利用すれば、ちょっとした設定で取得するログを最適な形に整えてあげることが可能になります。
以下、実際の操作画面を交えつつ解説していきます。
Azure Monitor ログのインジェスト時の変換は、 2022年11月30日に一般提供となった機能 です。
ざっくりと纏めると、ログがデータソースから Log Analytics ワークスペースに送信されるまでの間に色々な処理を施すことができるという機能です。
具体的には、例えば収集するログテーブルのうち不要なフィールドを変換で削除すれば、ログ保管コストが削減できます。
また、機密情報の保管等に厳しい制限がある場合などは、ログに含まれる機密情報を変換によって難読化したりといった操作も可能なようです。
変換の機能を利用するためには、データ収集ルール（以下 DCR ）が必須になります。
DCR について、
Microsoft のドキュメント
では以下のように記載されています。
分かりづらい記載ですが、要するにログデータを集める時に必要な諸々の設定を行うところなんだなと思っていただければ大きな間違いはないかと思います。
変換では、この DCR を利用します。
ただ、この DCR の扱いがログのデータソースの種類によって少し異なるので、以下よく使う場面を中心に簡単に解説していきます。
変換を使用しない通常のログ収集の場合であっても、Azure VM から Azure Monitor を用いてログを取得するには DCR を使用する必要があります。
そのため、このログに対して変換を行う場合は、この DCR をそのまま利用します。
一方で Azure リソースの診断設定からログを収集する場合、通常は DCR は使いません。
通常の Azure リソースログ収集設定は、基本的に各リソースの [診断設定] タブから診断設定を作成し、取得するログを選択して、送信先の Log Analytics ワークスペースやストレージアカウントを指定するだけで OK です。
そのため変換を用いるためには、変換用にわざわざ DCR を作成する必要があります。これを「ワークスペース変換 DCR」と呼びます。
ワークスペース変換 DCR は、ログの送信先になる Log Analytics ワークスペースに対して作成されます。
ログ保管先の Log Analytics ワークスペースが同じであれば、複数の Azure リソースで 1 つのワークスペース変換 DCR を共通して使う形になります。
以上でざっくりとした変換とワークスペース変換 DCR の仕組みの説明は終わりです。次の章から実際にリソースを触ってみた様子をご紹介します。
尚、Microsoft の公式のドキュメントには、ご紹介した 2 つのケースのほかにも API を使用してカスタムアプリケーションのデータを収集・変換する場合についても書かれていますので、必要に応じてご確認ください。
では実際に動作を確認してみた様子を、画面キャプチャとともにご紹介します。
今回は Azure リソースの診断設定から取得設定を行っているログに対して変換を設定してみます。
まず、ログ取得対象のリソースの [診断設定] タブにて、ログを取得して Log Analytics ワークスペースに送信する設定を行います。
また、変換の設定前後の違いを確認するために、取得設定したログを何回か出力させておきます（ここは本筋と大きく関わるところではないため詳細は割愛します。今回は例として App Service からログを出力させています）。
Log Analytics ワークスペースの [ログ] タブからログを確認します。正常に出力されていますね。
今回は試しにこの「UserAgent」列を Log Analytics ワークスペースに出力されないようにしようと思います。
それでは本筋の変換の設定に入っていきます。
ログの送信先の Log Analytics ワークスペースの [テーブル] タブを開きます。
ずらりとログテーブルが並んでいますので、今回取得設定を行ったログの名前を見つけます。
右端の […] をクリックして [変換の作成] を選択します。
変換作成画面の [基本] タブが表示されます。
まだワークスペース変換 DCR が作成されていないので、[データ収集ルール] の欄が空欄になっています。
[新しいデータ収集ルールの作成] を選択すると、ワークスペース変換 DCR の作成画面が表示されるので、[サブスクリプション]、[リソースグループ]、[名前] をそれぞれ入力して [完了] を選択します。
[次へ] を選択します。
[スキーマと変換]タブが表示されます。ここには、変換を施された後に Log Analytics ワークスペースに出力されるログのプレビューが表示されています。
[変換エディター] を選択します。
[ログ] という画面が表示され、クエリを打てるようになっています。ここがこの機能の肝です。
既定では、変換先テーブルと同じ内容を持つ「source」という仮想テーブルを返すクエリだけが記入されています。この後に続いて、KQL で変換の内容を記入していきます。
公式のドキュメントでは少し複雑な KQL が例として挙げられていますが、特定の列を削除するくらいであれば非常に簡単なクエリで済みます（ここでは例として「UserAgent」列のみ削除するごく単純なクエリを記入しています）。
クエリの記入が完了すれば、[実行] を選択します。
下部のプレビュー画面で意図した変更がなされていることを確認して（ここでは「UserAgent」列がなくなっていることを確認して） 、[適用] を選択します。
[次へ] を選択します。
[確認] タブで設定内容を確認し、[作成] を選択します。
これで設定は完了です。正常に設定されているか確認してみましょう。
App Service にアクセスしてログを出力させてみます。
Log Analytics ワークスペースの [ログ] タブからログを確認します。
変換を設定した後に出力されたログでは、「UserAgent」列が空白になっていますね。
正常に変換が設定できたことを確認できました！
ここでは簡単な例として特定の列の削除のみ行いましたが、KQL 次第ではログデータに様々な処理を施すことが可能です。
また、変換を編集する場合は、設定時と同様に Log Analytics ワークスペースの [テーブル] タブから対象のログテーブルを開き、[スキーマと変換] タブの [変換エディター] で KQL の修正を行えます。
まだ対応していないログテーブルもあるようです。取得したいログが変換に対応しているかどうかは以下のページからご確認ください。
Azure Monitor ログでの変換をサポートするテーブル
料金に関して、変換自体に対して直接課金されることはありませんが、以下の点に注意する必要があります。
後者については少し分かりづらいのですが、例として 100 GB のログが出力されて変換によって 70 GB 削除した場合を考えてみます。つまり Log Analytics ワークスペースには 30 GB が出力されている状況です。
この時、まず Log Analytics ワークスペースに取り込んだ 30 GB に対しては、通常のログ保管と同じように、ログインジェスト料金とデータ保持料金がかかります。
そして、「50 % を超えて削除した」20 GB に対しては、「ログデータ処理」という料金がかかるという仕組みになっています。
そのため、ログの容量を変換によって半分以上削除した場合、想像していたほどには料金が削減できないといったことが起こる可能性もありますので、ご注意ください。
以上のように、少し KQL が書ける人であれば出力されるログに簡単に変更を加えることができます。
この機能を活用するユースケースとしては、公式のドキュメントにも記載があるように、以下のような場合が想定されます。
ログテーブルごとに KQL を書かなければいけないのは少し面倒ですが、上記のようなユースケースを考えるとかなり便利な機能なのではないかと思いますので、機会があればぜひ試してみてください。
