Azure 上でのシステム・アプリケーション監視の全体マップ

# 本記事について

Azure 上で、システムやアプリケーションを稼働させる際に、どのような監視ポイントがあり、どういったサービスや機能で監視を始められるのかを、簡単にまとめてみます。

# システム・アプリケーションの監視について

本記事では、以下の３要素、メトリック・ログ・トレースについて、Azure における監視を考えます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/5d9e858a-9a42-41d4-e55f-26f91a1e0a07.png)

# Azure 上でのシステム・アプリケーションの構成について

詳細は公式ドキュメントのアーキテクチャセンター等に譲りますが、主に以下のようなパターンに対しての監視を考察します。

**Azure 上のよくあるシステム構成① - IaaS 上の社内システム**

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/bee752a4-b29f-8960-5afa-54e8700fef94.png)

**Azure 上のよくあるシステム構成② - PaaS 上の外部向けサービス**

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/00f36d0c-13fd-12eb-e931-7db989d4363f.png)

**Azure 上のよくあるシステム構成③ - コンテナー上のマイクロサービス**

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/4ad4a024-0689-a4e2-a9f4-0af8c5e8361e.png)

# 上記システム構成での、サービスごとの監視範囲のまとめ

クラウドサービスの場合、オンプレミスと異なりある程度の範囲がクラウドプロバイダーの管理対象となり、ユーザーが必ずしも直接監視しなくてもよくなります。ただし、サービスごとにその管理範囲は大きく異なり、どのレベルまでユーザー自身で監視する必要があるかは事前に把握しておく必要があります。

本記事では、上記のようなシステム構成を監視するにあたり、以下のような区分けで考えてみます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/90b60e74-078c-72e7-b98d-898ea2b04148.png)

白い部分が管理としてユーザー管理、青い部分がマイクロソフトの管理範囲となります。しかし青い部分のログもシステム監視には必要な点に注意が必要です。それを踏まえて、ここから各項目について監視の詳細を見ていきます。

## Azure のプラットフォーム基盤 (Resource Manager)

Azure では、リソース作成の命令を受け付け、処理を行うのは、Resource Manager という基盤になります。この部分はマイクロソフトによって提供されるものの、どういった操作がなされているかの監査はユーザー側で必要になります。また、サービスやリソースの正常性なども、この Resource Manager の管理範囲に含まれます。

## ネットワーク系サービス

Azure でシステムを構成する際に、大半は仮想ネットワーク (VNET) を利用して構成します。またオンプレミスとの接続やインターネットからのアクセス管理に様々なマネージドサービスを使用していくことになります。

基盤としての管理は Azure が行いますが、その死活の確認やアクセスログ・メトリックの監視はユーザー側で必要になります。

## IaaS (仮想マシン)

IaaS は OS 以上の範囲がユーザーの管理範囲になります。そのため、OS レイヤーでのパフォーマンス監視・ログ監視が必要になります。またそのうえで動かすミドルウェアやアプリケーションの監視も必要です。

## アプリケーションの実行用 PaaS (App Service, Azure Functions など)

App Service や Functions などでは、ミドルウェアやランタイムまではマイクロソフトの管理範囲になります。そのため、監視対象としてはその上で実行されるアプリケーションがメインになります。ただ、外部からのアクセスログやインフラのメトリックなどもユーザー側で監視が必要です。

## アプリケーションの実行用 CaaS (Azure Kubernetes Service, Azure Container Apps など)

CaaS は監視としては IaaS と PaaS の中間に位置します。ただし、特に Azure Kubernetes Service では、ノード、ポッド、オーケストレーター、アプリケーションなど多くの監視の必要な要素が出てきます。

## データベース・ストレージ (SQL Database, Blob Storage, Cosmos DB など)

Azure SQL Database や Azure Blob Storage において、ユーザーがメインで監視しないといけないのは、データへのアクセスになります。アクセスそのものの監査やデータベースへのクエリのパフォーマンスなどが監視項目になります。

## API 系サービス (Azure OpenAI, Cognitive Services, Communication Services など)

Azure のマネージドサービスには、API などの形で簡単に使えるサービスが多く取り揃えられています。それらのサービスは、それぞれ出力できるログが決まっており、ユーザー側で何を監視することが必要かを精査したうえで、必要に応じてログ・メトリックを取得します。

# 各監視対象に対するログ・メトリック・トレース取得の実装

ここから各対象に対して、どういった機能を利用して監視を実装できるかを見ていきます。基本的には Azure Monitor というサービスの中に含まれる仕組みを利用します。全体のサマリは下記になります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/cbd329af-105c-ba7a-439e-867a3fb7dab5.png)

## Azure プラットフォーム基盤 (Resource Manager)

Azure プラットフォーム基盤 (Resource Manager) は、[アクティビティログ](https://learn.microsoft.com/ja-jp/azure/azure-monitor/essentials/activity-log-insights)を保存することで監視します。アクティビティログは既定で90日間基盤側に保持されていますが、通常それ以上の保持期間を必要とする場合が多いです。その際には、[Azure Monitor ログ (Log Analytics ワークスペース) へ保管](https://learn.microsoft.com/ja-jp/azure/azure-monitor/essentials/activity-log?tabs=powershell#send-to-log-analytics-workspace)するようにします。

また、アクティビティログと同時に、Microsoft Entra ID の[サインインログ](https://learn.microsoft.com/ja-jp/entra/identity/monitoring-health/concept-sign-ins)と[監査ログ](https://learn.microsoft.com/ja-jp/entra/identity/monitoring-health/concept-audit-logs)も保持しておくことが推奨です。Azure Portal へのログインやユーザー管理の記録は Entra ID 側にログが保持されます。セキュリティ管理の観点では両方が必要になることが大半です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/94b871b9-8271-bc44-c115-3bafa2ab1371.png)

## IaaS (仮想マシン)

IaaS の監視を簡単にまとめると下記になります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/ad94df69-80ee-04ec-ebbd-849bbf55b8ae.png)

IaaS については、OS や ミドルウェアについては、Azure Monitor Agent を使って監視します。このエージェントは各種のパフォーマンスカウンターやイベントログ・Syslog, テキストログ (カスタムログ) の収集に利用できます。

特に、Azure Monitor の VM Insights を有効化することで、パフォーマンス監視に必要なデータを一通り取得することができます。

https://learn.microsoft.com/ja-jp/azure/azure-monitor/vm/vminsights-overview

一方、アプリケーションレイヤーについては Application Insights を利用します。大変のケースでは、SDK を使ってインストルメンテーションすることになるかと思います。Application Insights については下記もご参照ください。

https://qiita.com/YoshiakiOi/items/c4de9b1ffc01ecf292f9

## アプリケーションの実行用 PaaS (App Service, Azure Functions など)

PaaS でアプリを稼働する場合、リソースログと Application Insights を使い分けてログ・メトリック・トレースの取得することになります。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/83bb9855-26df-3b17-107d-728c059652a4.png)

特に、Python アプリにおける使い分けについては、下記にてご紹介しています。

https://qiita.com/YoshiakiOi/items/04110cd2ec2816533d87

特にアプリケーションから出力されるログについてはリソースログと Application Insights で一部重複する可能性があるので、どちらの仕組みで何の取得を有効化するか検討が必要です。

一方、分散トレーシングをしたい場合は、Application Insights の利用が必要になります。App Service や Functions では .NET や Java では自動インストルメンテーションもあるので、容易に開始できます。また、Python の場合は OpenTelemetry を使って、コードで監視の有効化を行う必要はあるものの、同じくトレーシングが可能です。

## Azure Kubernetes Service

Azure Kubernetes Service の場合、App Service や Functions と比較し、インフラに近い範囲の監視がより必要になります。詳細は本記事では割愛しますが、Azure Monitor の [Container Insights](https://learn.microsoft.com/ja-jp/azure/azure-monitor/containers/container-insights-overview) を利用することで多くのパフォーマンスとコンテナーログのデータを取得できます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/78ffa646-7204-34e1-1e8a-2898ffd49f30.png)




## ネットワーク系サービス + データベース・ストレージ (SQL Database, Blob Storage, Cosmos DB など) + API 系サービス (Azure OpenAI, Cognitive Services, Communication Services など)

上記のようなマネージドサービスは、リソースログ (診断ログ) とメトリックを使って監視します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/276225/32237987-cc68-8a3b-238c-8113d6c7372b.png)

ログ・メトリックともに、各サービスで記録できるものが異なります。そのため、各システムで求められているログがそれらに含まれているかを事前に確認をする必要があります。

たとえば、Azure OpenAI Service の場合、リソースログには呼び出されたプロンプトは含まれません。そういったログが必要な場合、例えばフロントに API Management をはさみ、API Management 側で診断設定を有効化するなどの対応が必要です。

また、Azure 仮想ネットワークについては、VNET Flow Logs を利用することで、トラフィックを詳細に記録することもできます。(こちらはセキュリティとして全通信のログが必要な場合や、パフォーマンス監視、トラブルシューティングなどの用途が想定されます。)

https://learn.microsoft.com/ja-jp/azure/network-watcher/vnet-flow-logs-overview







# 最後に

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