はじめに
AzureにはAzureMonitorや診断設定、ApplicationInsight等様々なログ収集のサービスがあります。どれを使っていけばよいのか、またどう設計してけばよいのか難しいですよね。
今回は、監視対象ごとにベストプラクティスを私の独自観点で整理していきたいと思います。なお、DefenderForEndpointやDefenderForCloud、ゲスト構成によるセキュリティに主眼を置いて監視構成については触れておりません。
目次
Azureリソースの監視
Azureの責任共有モデル(下図)によると、PaaSやSaaS等のマネージドサービスの監視としてネットワーク以上の領域をユーザーで管理する必要があります。
診断設定
Azureリソースにおいては、各リソースが診断設定で出力するログを管理する必要があります。診断設定では、主に以下のログを収集できます。
- リソースログ：Azureリソースの個別ログ、メトリックんなど
- Activityログ：Azureリソースへの操作を記録したログ
- EntraIDログ：EntraIDへのサインインのログや監査ログなど
また、送信先として以下サービスを選択することができます。
- EventHub
- StorageAccount
- LogAnalyticsWorkspace
各Azureリソースの「診断設定」ペインから設定ができ、設定画面はこんな感じです。（以下、LogicAppsの例）
診断設定の選択について
実際のインフラ開発の現場において、多くの種類がある診断設定を取捨選択することは非常に困難です。Activityログや監査ログ等の最小限の設定にとどめておき、リソースログの選択は各マネージドサービスの運用チームに委ねることで、運用の中でブラッシュアップしていくことが良いと考えます。
ネットワークの監視
クラウド内で構成したネットワークの監視はユーザーの責任範囲となっています。
主に、診断設定とNetWorkWathcerを使用していくことになります。
こちらについては以下記事がとてもよくまとまっております。
QIITA | Azure ネットワーク 通信ログのまとめ
フローログ監視、Traffic分析のベストプラクティスについて
少しセキュリティ監視ともかぶってしまいますが、ここでNetWorkWatcherによる監視について考えを整理しておきます。
まず、NetworkWatcherにフローログの監視やTraffic分析という機能があり、主に以下２点での分析が可能です。
- NSGフローログ
- Vnetフローログ
ただし、投稿主はVnetフローログだけでネットワークの監視は十分と考えています。主な理由は以下です。
- VNetフローログとNSGフローログをどちらも有効にすると、ログがダブってしまい保存コストに無駄が発生する
- 仮想ネットワーク暗号化された通信も監視ができる
- VnetフローログはNICレベルでもトラフィックをキャプチャできるので、より詳細な情報が得られる
フローログの保存先は、基本的にAzureStorageAccountですが、セキュリティ分析の観点からSentinelでの横断的な分析に使用したい場合は診断設定を使用して、LogAnalyticsWorkspaceへ保存する必要があります。
ただし、実際のワークロードにおいては膨大なログを取得できるので、料金には十分に注意して保管するようにしてください。できるだけ、NetworkWatcherでの監視に抑えておきStorageAccountのライフサイクル設定をしておくことをお勧めします。
仮想マシンやAzureArc対応サーバの監視
Azureの責任共有モデル(下図)によると、仮想マシン(IaaS)やAzureArc(ハイブリッド環境)を構成する際にはゲストOSのログもユーザーで管理する必要があります。
AzureMonitorAgent
IaaS環境においては、AzureMonitorAgentで監視を行いたい必要最低限のログは網羅できます。AMAを使用して取得できるログは主に以下3種類です。
- パフォーマンスカウンタ：CPUやメモリなどのパフォーマンス情報
- OSのイベントログ：LinuxのSysログやWindowsのイベントログ
- カスタムテキストログ：.textや.log等のログを収集可能
カスタムテキストログを使用することで、アプリケーションが出力したログを収集することも可能ですし、AzureMonitorPipelineを作成することで収集したカスタムテキストログの簡単な変換処理も可能です。
送信先は基本的にLogAnalyticsWorkspaceになります。StorageAccountやEventHubへの送信についてはデータエクスポート機能を使用することになります。
詳細については以下の記事をご参照下さい。
QIITA | LogAnalyticsWorkspaceのデータエクスポート設定について
アプリケーションの監視
上記で紹介した診断設定やAMAでアプリケーションの監視を補える場合はいいですが、もっと詳しくログをとりたい時があると思います。そういう時はApplicationInsightの出番です。
ApplicationInsight
ApplicationInsightはAppServiceに対してはもちろん、SDKを設置することで仮想マシン上にデプロイされたアプリケーションの監視も可能です。一部の機能を紹介します。
-
アプリケーションマップ：各コンポーネントの依存関係を確認して、ボトルネックになっているコンポーネントを抽出可能です。
-
LiveMetricView：AMAによるパフォーマンス監視は1分間隔ですが、1秒間隔でのより高解像度なパフォーマンス監視が可能です。
他にも、ユーザーごとのクエリ数を統計したり、エラー発生数の統計を行ったり、AMAでは取得できないメトリックを取得したりと様々な機能があります。機能の詳細については以下をご確認ください。
MS Learn | Application Insights の概要
MS Learn | Application Insights 標準メトリック
Application Insightの利用価値について(投稿主の意見)
こちらは私の主観ですが、ApplicationInsightはAppServiceやFunctions等のPaaS利用したアプリ開発の現場において最も真価を発揮すると考えています。（もちろん見にくい部分もまだまだありますが。）
一方で既にシステムが稼働している運用チームの現場においては、あまりにも細かすぎるログではないでしょうか。あなたの現場がApplicationInsightで監視をしなければならないような状況であれば、本当に必要かを考える場を設けた方が良いです。もし、予期されるエラーありApplicationInsightが必要と判断されるのであれば、まずはアプリチームに相談して根本的な予防行って、監視しなくて良い環境を用意する方が良いでしょう。
終わりに
今度はセキュリティ編のログ収集についてフォーカスしてみたいと思います。
少しでも参考になったら「いいね」してくれると嬉しいです。