チュートリアル:Azure Monitor を使用した App Service アプリのトラブルシューティング
このチュートリアルでは、Azure Monitor を使用して App Service アプリのトラブルシューティングを行う方法について説明します。 このサンプル アプリには、メモリを使い果たして HTTP 500 エラーを引き起こすことを意図したコードが含まれているため、Azure Monitor を使用して問題を診断して修正できます。 完了すると、Azure Monitor と統合された App Service on Linux でサンプル アプリが動作するようになります。
Azure Monitor は、クラウドおよびオンプレミス環境からテレメトリを収集、分析し、それに対応する包括的なソリューションを提供することで、アプリケーションやサービスの可用性とパフォーマンスを最大限に高めます。
このチュートリアルでは、以下の内容を学習します。
- Azure Monitor を使用して Web アプリを構成する
- Log Analytics にコンソールのログを送信する
- ログ クエリを使用して Web アプリのエラーを特定し、トラブルシューティングを行う
このチュートリアルの手順は、macOS、Linux、Windows で実行できます。
Azure サブスクリプションをお持ちでない場合は、開始する前に Azure 無料アカウントを作成してください。
前提条件
このチュートリアルを完了するには、次のものが必要です。
Azure Cloud Shell で Bash 環境を使用します。 詳細については、「Azure Cloud Shell の Bash のクイックスタート」を参照してください。
CLI リファレンス コマンドをローカルで実行する場合、Azure CLI をインストールします。 Windows または macOS で実行している場合は、Docker コンテナーで Azure CLI を実行することを検討してください。 詳細については、「Docker コンテナーで Azure CLI を実行する方法」を参照してください。
ローカル インストールを使用する場合は、az login コマンドを使用して Azure CLI にサインインします。 認証プロセスを完了するには、ターミナルに表示される手順に従います。 その他のサインイン オプションについては、Azure CLI でのサインインに関するページを参照してください。
初回使用時にインストールを求められたら、Azure CLI 拡張機能をインストールします。 拡張機能の詳細については、Azure CLI で拡張機能を使用する方法に関するページを参照してください。
az version を実行し、インストールされているバージョンおよび依存ライブラリを検索します。 最新バージョンにアップグレードするには、az upgrade を実行します。
Azure リソースを作成する
最初に、複数のコマンドをローカルで実行して、このチュートリアルで使用するサンプル アプリを設定します。 このコマンドを実行すると、Azure リソースが作成され、デプロイ ユーザーが作成され、サンプル アプリが Azure にデプロイされます。 デプロイ ユーザーの作成の一環として指定したパスワードの入力が求められます。
az group create --name myResourceGroup --location "South Central US"
az webapp deployment user set --user-name <username> --password <password>
az appservice plan create --name myAppServicePlan --resource-group myResourceGroup --sku B1 --is-linux
az webapp create --resource-group myResourceGroup --plan myAppServicePlan --name <app-name> --runtime "PHP|8.1" --deployment-local-git
az webapp config appsettings set --name <app-name> --resource-group myResourceGroup --settings DEPLOYMENT_BRANCH='main'
git clone https://github.com/Azure-Samples/App-Service-Troubleshoot-Azure-Monitor
cd App-Service-Troubleshoot-Azure-Monitor
git branch -m main
git remote add azure <url-from-app-webapp-create>
git push azure main
Azure Monitor を構成する
Log Analytics ワークスペースを作成する
サンプル アプリを Azure App Service にデプロイしたら、問題の発生時にアプリのトラブルシューティングを行うよう監視機能を構成します。 Azure Monitor は、ログ データを Log Analytics ワークスペースに格納します。 ワークスペースは、データと構成情報が含まれるコンテナーです。
この手順では、Log Analytics ワークスペースを作成して、お使いのアプリで Azure Monitor を構成します。
az monitor log-analytics workspace create --resource-group myResourceGroup --workspace-name myMonitorWorkspace
診断設定の作成
診断設定を使用すると、特定の Azure サービスのメトリックを Azure Monitor ログに収集し、ログ クエリを使用して、他の監視データと組み合わせて分析することができます。 このチュートリアルでは、Web サーバーと標準出力またはエラー ログを有効にします。 ログの種類と説明の完全な一覧については、「サポートされるログの種類」を参照してください。
次のコマンドを実行して、AppServiceConsoleLogs (標準出力またはエラー) と AppServiceHTTPLogs (Web サーバー ログ) の診断設定を作成します。 <app-name > と <workspace-name> を実際の値に置き換えます。
Note
最初の 2 つのコマンド resourceID と workspaceID は、az monitor diagnostic-settings create コマンドで使われる変数です。 このコマンドの詳細については、「Azure CLI を使用して診断設定を作成する」を参照してください。
resourceID=$(az webapp show -g myResourceGroup -n <app-name> --query id --output tsv)
workspaceID=$(az monitor log-analytics workspace show -g myResourceGroup --workspace-name <workspace-name> --query id --output tsv)
az monitor diagnostic-settings create --resource $resourceID \
--workspace $workspaceID \
-n myMonitorLogs \
--logs '[{"category": "AppServiceConsoleLogs", "enabled": true},
{"category": "AppServiceHTTPLogs", "enabled": true}]'
アプリのトラブルシューティングを行う
http://<app-name>.azurewebsites.net を参照します。
サンプルアプリ ImageConverter は、含まれる画像を JPG から PNG に変換します。 このチュートリアルのコードには、バグが意図的に配置されています。 十分な数の画像を選択すると、アプリでは、画像の変換中に HTTP 500 エラーが発生します。 開発段階ではこのシナリオが考慮されなかったことを想像してください。 Azure Monitor を使用してこのエラーのトラブルシューティングを行います。
アプリの動作確認
画像を変換するには、[Tools] をクリックし、[Convert to PNG] を選択します。
![[ツール] をクリックして [PNG に変換] を選択する](media/tutorial-azure-monitor/sample-monitor-app-tools-menu.png)
最初の 2 つの画像を選択し、[convert] をクリックします。 これは正常に変換されます。
アプリを中断する
2 つの画像を正常に変換してアプリを検証できたので、最初の 5 つの画像を変換してみます。
この操作は失敗し、開発段階でテストされなかった HTTP 500 エラーが発生します。
ログ クエリを使用して Azure Monitor ログを表示する
Log Analytics ワークスペースで使用できるログを確認してみましょう。
この Log Analytics ワークスペースのリンクをクリックして、Azure portal で自分のワークスペースにアクセスします。
Azure Portal で、Log Analytics ワークスペースを選びます。
ログ クエリ
ログ クエリは、Azure Monitor ログ内に収集されたデータの価値を最大限に適用するのに役立ちます。 ログ クエリを使用して、AppServiceHTTPLogs と AppServiceConsoleLogs の両方でログを特定します。 ログ クエリの詳細については、ログ クエリの概要に関するページを参照してください。
ログ クエリを使用して AppServiceHTTPLogs を確認する
アプリにアクセスしたところで、AppServiceHTTPLogs にある、HTTP 要求に関連付けられたデータを確認しましょう。
- 左側のナビゲーションで [
Logs] をクリックします。
![Log Analytics ワークスペースの [ログ]](media/tutorial-azure-monitor/log-analytics-workspace-logs.png)
appserviceを検索し、AppServiceHTTPLogsをダブルクリックします。
![Log Analytics ワークスペースの [テーブル]](media/tutorial-azure-monitor/log-analytics-workspace-app-service-tables.png)
- [
Run] をクリックします。
AppServiceHTTPLogs クエリでは、過去 24 時間の要求がすべて返されます。 ScStatus 列には、HTTP 状態が格納されます。 HTTP 500 エラーを診断するには、次のように、ScStatus を 500 に制限してクエリを実行します。
AppServiceHTTPLogs
| where ScStatus == 500
ログ クエリを使用して AppServiceConsoleLogs を確認する
HTTP 500 を確認できたので、アプリの標準出力とエラーを見てみましょう。 これらのログは、"AppServiceConsoleLogs" にあります。
(1) + をクリックして新しいクエリを作成します。
(2) AppServiceConsoleLogs テーブルをダブルクリックし、[Run] をクリックします。
5 つの画像を変換するとサーバー エラーが発生するため、以下に示すように、ResultDescription にフィルターをかけてエラーを抽出することでアプリもエラーを書き込んでいるかどうかを確認できます。
AppServiceConsoleLogs |
where ResultDescription contains "error"
ResultDescription 列に、次のエラーが表示されます。
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted
(tried to allocate 16384 bytes) in /home/site/wwwroot/process.php on line 20,
referer: http://<app-name>.azurewebsites.net/
AppServiceHTTPLogs と AppServiceConsoleLogs を結合する
HTTP 500 と標準エラーの両方を特定したので、これらのメッセージの間に相関関係があるかどうかを確認する必要があります。 次に、タイム スタンプ TimeGenerated に基づいてテーブルを結合します。
Note
次の処理を行うクエリは用意されています。
- HTTPLogs をフィルター処理して 500 エラーを抽出する
- コンソールのログを照会する
TimeGeneratedに基づいてテーブルを結合する
次のクエリを実行します。
let myHttp = AppServiceHTTPLogs | where ScStatus == 500 | project TimeGen=substring(TimeGenerated, 0, 19), CsUriStem, ScStatus;
let myConsole = AppServiceConsoleLogs | project TimeGen=substring(TimeGenerated, 0, 19), ResultDescription;
myHttp | join myConsole on TimeGen | project TimeGen, CsUriStem, ScStatus, ResultDescription;
ResultDescription 列に、Web サーバー エラーと同時に次のエラーが表示されます。
PHP Fatal error: Allowed memory size of 134217728 bytes exhausted
(tried to allocate 16384 bytes) in /home/site/wwwroot/process.php on line 20,
referer: http://<app-name>.azurewebsites.net/
このメッセージは、process.php の 20 行目でメモリが使い果たされたことを示します。 これで、HTTP 500 エラーの発生中にアプリケーションでエラーが発生したことが確認されました。 問題を特定するコードを見てみましょう。
エラーを特定する
ローカル ディレクトリで、process.php を開き、20 行目を確認します。
imagepng($imgArray[$x], $filename);
最初の引数 $imgArray[$x] は、変換を必要とするすべての JPG (インメモリ) を保持する変数です。 ただし、imagepng に必要なのは、すべての画像ではなく、変換される画像のみです。 画像の事前読み込みは必要ありません。メモリ不足の原因となり、HTTP 500 を引き起こす可能性があります。 必要に応じて画像を読み込むようコードを更新して、問題が解決されるかどうかを確認してみましょう。 次に、コードを改良してメモリの問題に対処します。
アプリを修正する
コードをローカルで更新して再デプロイする
メモリ不足に対処するために、process.php に対して次の変更を行います。
<?php
//Retrieve query parameters
$maxImages = $_GET['images'];
$imgNames = explode(",",$_GET['imgNames']);
//Load JPEGs into an array (in memory)
for ($x=0; $x<$maxImages; $x++){
$filename = './images/converted_' . substr($imgNames[$x],0,-4) . '.png';
imagepng(imagecreatefromjpeg("./images/" . $imgNames[$x]), $filename);
}
Git で変更をコミットしてから、コード変更を Azure にプッシュします。
git commit -am "Load images on-demand in process.php"
git push azure main
Azure アプリを参照する
http://<app-name>.azurewebsites.net を参照します。
画像を変換しても、HTTP 500 エラーが発生しなくなります。
リソースをクリーンアップする
前の手順では、リソース グループ内に Azure リソースを作成しました。 これらのリソースが将来必要になると想定していない場合、Cloud Shell で次のコマンドを実行して、リソース グループを削除します。
az group delete --name myResourceGroup
このコマンドの実行には、少し時間がかかる場合があります。
次のコマンドを使用して、診断設定を削除します。
az monitor diagnostic-settings delete --resource $resourceID -n myMonitorLogs
ここで学習した内容は次のとおりです。
- Azure Monitor を使用して Web アプリを構成しました
- ログを Log Analytics に送信しました
- ログ クエリを使用して Web アプリのエラーを特定し、トラブルシューティングを行いました