Azure Log Analytics (Microsoft Sentinel) のログの長期保管の選択肢

# 本記事について

:::note info
2021年の記事ですが、一部2024年1月時点での情報に更新しています。
:::

Azure Log Analytics や Microsoft Sentinel の利用が進むにつれて、より長期にログを保管したいというニーズを伺うことが増えてきました。本記事では、Log Analytics に格納したデータを長期間保持したい時に利用できるオプションを整理します。

# Log Analytics ワークスペースに２年間まで (新登場のアーカイブ機能で最大12年間) 保持

もしログの保持期間が2年以内なのであれば、**そのまま Log Analytics ワークスペースに置いておくのが一番楽なオプション**になります。


[**ワークスペース単位で30-730日で保持期間を設定**](https://docs.microsoft.com/ja-jp/azure/azure-monitor/logs/manage-cost-storage#change-the-data-retention-period)でき、**期間を過ぎたログは自動的に削除**されます。また、[**テーブル単位で細かく制御**](https://docs.microsoft.com/ja-jp/azure/azure-monitor/logs/manage-cost-storage#retention-by-data-type)することも可能です。

また、[**新しいアーカイブ機能で12年間までの保持**](https://docs.microsoft.com/ja-jp/azure/azure-monitor/logs/data-retention-archive) ができるようになってきています。**アーカイブされたログの検索機能（search 機能）やリストア機能には制限**がありますが、要件に合うのであれば一番容易に長期保管ができるオプションになります。[こちら](https://qiita.com/YoshiakiOi/items/580603b6827834fbf32d)に簡単にまとめましたので、合わせてご覧ください。

# 別の Azure サービスにエクスポート

2年 or 12年（アーカイブ機能利用時）よりも長期保管したい、もしくは Log Analytics ワークスペースの保持料金よりも安くデータを持っておきたいというニーズがあるときは**外部エクスポート**を検討します。


時々、**一度エクスポートしたデータを再度 Log Analytics に入れたいという希望を伺いますが、基本的には非推奨**です。[**Log Ingest API**](https://learn.microsoft.com/ja-jp/azure/azure-monitor/logs/logs-ingestion-api-overview) を利用すれば任意のデータを Log Analytics に格納できますが、**① テーブル名や列名が変わってしまう、② Log Analytics のインジェスト料金が再度かかってしまう、** などが理由として挙げられます。


検索用途があるのであれば、後ほど触れていきますが、[**Azure Data Explorer**](https://docs.microsoft.com/ja-jp/azure/data-explorer/data-explorer-overview) や [**Microsoft Fabric**](https://learn.microsoft.com/ja-jp/fabric/)を利用するほうが同じクエリを利用でき、かつ一般的にはより安価になります。

## 1. とりあえず持っておければよい時 - Azure Blob Storage

とりあえずログデータを保持できていれば良いのであれば、[**Azure Blob Storage**](https://learn.microsoft.com/ja-jp/azure/storage/blobs/storage-blobs-overview) に Log Analytics ワークスペースからデータをエクスポートしておくのがおすすめです。 


Blob Storage には[**不変ストレージ機能による削除禁止**](https://docs.microsoft.com/ja-jp/azure/storage/blobs/immutable-storage-overview)や、[**磁気テープを使う Archive Storage への自動ティア変更を行えるライフサイクル管理機能**]()などが備わっており、セキュアかつ安価にログを保管することができます。


Blob Storage へのエクスポートは、下記のような手法が考えられます。

### エクスポート手法①: Log Analytics の連続エクスポート（プレビュー）

Log Analytics にはデータを取り込む際に、[**そのパイプライン上で別のストレージにデータを吐き出すようにする機能**](https://learn.microsoft.com/ja-jp/azure/azure-monitor/logs/logs-data-export?tabs=portal)が備わっています。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/aec43cbb-88cd-dd6c-ccd4-8c48a2f53e05.png)

自分のエクスポートしたいテーブルが[この機能のサポート対象](https://docs.microsoft.com/ja-jp/azure/azure-monitor/logs/logs-data-export?tabs=portal#supported-tables)かの確認が必要ですが、一番簡単に実装することができます。

こちらの機能は取り込み時のエクスポートなのでデータを分散して保持することができるというメリットがありますが、逆に言うと２か所に同時にデータを二重に持ってしまうことにもなります。

### エクスポート手法②: Azure Logic Apps

[**Logic Apps には Log Analytics に対してクエリを投げその結果を取得できるコネクターがある**](https://docs.microsoft.com/ja-jp/azure/azure-monitor/logs/logs-export-logic-app)ため、それを利用することができます。任意のタイミングで実行できるのが強みですが、一方でそれなりに自作が必要です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/3c6e8878-32f2-9ba7-856e-e4e7680f511c.png)

### エクスポート手法③: Log Analytics Rest API 

[**Log Analytics の Rest API**](https://learn.microsoft.com/ja-jp/azure/azure-monitor/logs/api/overview) を利用してデータを取得し、それをストレージにファイルとしてストレージに置くようなアプリケーションを [**Azure Functions**](https://learn.microsoft.com/ja-jp/azure/azure-functions/functions-overview?pivots=programming-language-python) や [**Azure Container Apps**](https://learn.microsoft.com/ja-jp/azure/container-apps/overview) (特に [**Container Apps ジョブ**](https://learn.microsoft.com/ja-jp/azure/container-apps/jobs?tabs=azure-cli)) などで構築することも可能です。①や②に比べると実装コストがあがりますが、より柔軟に設計することができます。

特に、PowerShell は容易に利用できるコマンドレット (**[`Invoke-AzOperationalInsightsQuery`](https://jpazmon-integ.github.io/blog/LogAnalytics/QueryByPowerShell/)**)も用意されており、簡単に使用を開始できます。詳細については下記のマイクロソフトのサポートチームのブログ記事が参考になります。

https://jpazmon-integ.github.io/blog/LogAnalytics/QueryByPowerShell/

また、この **PowerShell と Azure Container Apps のコンテナーアプリジョブを利用してバッチジョブ化する方法**を簡単に以下の記事にまとめていますので、ご興味ある方はご参照ください。

https://qiita.com/YoshiakiOi/items/0f64e76a19f149662891

## 2. いざというときにのみ検索できるようにしておきたい時 - Azure Blob Storage + Azure Data Explorer / Microsoft Fabric

普段は#1と同じでログがどこかに残っていればよい、ただしいざというときには検索ができることが必要ということもあるかと思います。その際には#1と同じく **Blob Storage にエクスポートしつつ、Azure Data Explorer / Microsoft Fabric も使えるようにしておきましょう。**

具体的な例は下記をご参照ください。

https://qiita.com/YoshiakiOi/items/3386a34bf41bcb72678b

![LABlob.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/3387f6aa-2ea7-6c37-06d8-894fed38fcd2.png)

[こちらの記事](https://qiita.com/YoshiakiOi/items/ff36a468a3e57bc9d725)でも解説しましたが、Azure Data Explorer と Log Analytics は同じ **KQL (Kusto Query Language)** を利用しており、全く同じクエリを実行することができます。

Azure Data Explorer はかなり自由度が高い仕組みのため様々な取り込み方法が考えられますが、たとえば [**Event Grid を使って簡単に Blob Storage から取り込み**](https://docs.microsoft.com/ja-jp/azure/data-explorer/ingest-data-event-grid)が可能です。

また検索速度などは落ちますが、[**Azure Data Lake Storage Gen2 上のファイルを外部テーブルとして利用**](https://docs.microsoft.com/ja-jp/azure/data-explorer/data-lake-query-data)することもできます。

## 3. Log Analytics から退避後も常に検索はできるようにしておきたい時 - Azure Data Explorer / Microsoft Fabric

退避後も常時検索がかけられるようにしておく必要があるときは、**最初から Azure Data Explorer または Microsoft Fabric に直接データを入れておくのがおすすめ**です。

![LABlob2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/a69b1a9f-e972-7b47-1ae2-40633b3b879a.png)

取り込み方法としては、**Log Analytics の連続エクスポートで Event Hub を指定して、Event Hub 経由で Data Explorer に取り込ん**だり、**中継先として Blob Storage にいったん置いておいて、連続的に Data Explorer に取り込む**などが考えられます。

こちらも**今後、Microsoft Fabric を利用することが新たな選択肢**になります。

https://qiita.com/YoshiakiOi/items/3386a34bf41bcb72678b

# まとめ

本記事では、Log Analytics からさらにデータを長期に保持したい時に、特に検索の必要性からいくつかのオプションを検討しました。特に何らかの理由で2年/12年以上ログを持っておきたいシーンが出てきた際には、ご参考にしていただけますと幸いです。

＊本稿は、個人の見解に基づいた内容であり、所属する会社の公式見解ではありません。また、いかなる保証を与えるものでもありません。正式な情報は、各製品の販売元にご確認ください。