【Azure】ApplicationGatewayバックエンドプールで異常が発生した際にどのバックエンドに異常が発生したのかわかるようにする
1.はじめに
タイトルが長いっ!!!
ApplicationGateweayは負荷分散装置ですが、バックエンドプールに異常が発生した場合、メトリックを監視しておくことでアラートを出すことができます。
ただし、アラートではどのバックエンドプールに異常があったかはわかるのですが、具体的にどのバックエンドに異常があったのかはわかりません。
そのため、調査をしようとすると、バックエンドのログを調べないとわからず、調査に時間がかかります。VMにログインするのだるい
はい、というわけで、ApplicationGatewayで異常が発生した場合、メトリック監視でアラートを出し、合わせてバックエンド正常性をログとして記録します。
2.一言で書くと
- ApplicationGatewayはメトリックで不通になったバックエンド情報をもっていないので不便。どのバックエンドプールに異常があったのかはわかるが、具体的にはわからない
- メトリック[UnHealthy host count]が増加したタイミングで、Automationでバックエンド正常性を取得、ストレージアカウントに格納。
3.Application Gatewayの正常性監視
ApplicationGateweayでは、Potal上やコマンドでバックエンドの正常性を確認することができます。
サーバー(バックエンドプール):バックエンドに登録したあるサーバなど。
ポート(HTTP設定):利用しているポート。
状態:バックエンドの状態を示す。
詳細:そのバックエンドの状態の詳細。エラー時は何故エラーになっているか表示される。
しかしながら、これはメトリックとしては保存できず、その場その場でのみのデータです。
メトリックとしては、「どのバックエンドプールに異常があったか」のみ記録されます。
バックエンドプールは同じ分散を行うバックエンドをグループ化したものなので、具体的にどのバックエンドなのかまではわかりません。
深夜にApplicationGateweayのバックエンドで異常が発生する ⇒ アラートが発報される ⇒ すぐに解決する ⇒ 次の日どのVMに異常があったかわからない ⇒ あたりをつけて調査
っていうことになってしまいます。
そこで、アラートをトリガーとしてAutomationを動かし、バックエンド正常性の項目を出力しストレージアカウントにログとして保存します。
これでログを見れば、具体的にどのバックエンドなのかわかるようになります。
4.構成
今回の構成はこんな感じ。
①ApplicationGatewayのバックエンドが異常状態になると、
②ApplicationGatewayのメトリック監視で、[UnHealty host count]が増加したタイミングにアラートを出します。③アラートに合わせて、メールを送付します。
③アラートをトリガーにしてAzureAutomationを実行し、④ApplicationGatewayの正常性監視結果を取得します。
⑤その後、ストレージアカウントに書き込んだログファイルを格納します。
5.Azure Automationの設定
すでにApplication GateweayとApp Serviceとストレージアカウントはすでに構築されているものとして、まずAutomationの設定を行います。
「Automation アカウント」を開き、適当にAutomationアカウントを作成します。
「モジュール」を開き、モジュールのバージョンを更新します。
また、合わせて「Az.Accounts」「Az.Network」「Az.Storage」をインポートします。
(更新のやり方とAZモジュールのインポート方法はこちら⇒[https://qiita.com/motomiya_hikaru/items/ecc080c61c8b185af2de] に。)
Runbookの作成を選択し、PowerShellのRunbookを適当に作成。
編集画面が開くので、次のPowerShellコマンドを入れます。
アカウント認証部分は、
https://qiita.com/sakamichihassin/items/736f07c53f86f76b1263 の記事に記載されていた内容を使わせてもらいました。ありがとうございます。
# Automationアカウントの接続名(既定名の場合)
$connectionName = "AzureRunAsConnection"
# AzureRMContextでセッションが残っているとAzコマンドが使えないため念の為セッション継続を無効にしておく
Disable-AzContextAutosave –Scope Process
$conn = Get-AutomationConnection -Name $connectionName
Connect-AzAccount -ServicePrincipal -Tenant $conn.TenantID `
-ApplicationId $conn.ApplicationID -CertificateThumbprint $conn.CertificateThumbprint
$AzureContext = Select-AzSubscription -SubscriptionId $conn.SubscriptionID
#Applicationgatewayのバックエンドヘルスの監視結果を取得。
$agwhealth = Get-AzApplicationGatewayBackendHealth `
-Name "Applicationgateway" `
-ResourceGroupName "Applicationgateway"
#日付・ファイル名設定
$todaydate = Get-Date -Format yy-MM-dd-HH-mm-ss
$filename = "ApplicationgatewayHealth-$todaydate.log"
$LogItem = New-Item -ItemType File -Name $filename
$agwhealth | Out-File -FilePath $filename -Append
#ストレージアカウントのアクセスキーを取得
$storagekey = (Get-AzStorageAccountkey `
-ResourceGroupName "Applicationgateway" `
-Name "agwhealth").Value[0]
#コンテキストの作成
$storageContext = New-AzStorageContext `
-StorageAccountName "agwhealth" `
-StorageAccountKey $storagekey
#ストレージアカウント(のApplicationgatewayという名のコンテナ)に格納
Set-AzStorageBlobContent `
-File $filename `
-Container "applicationgateway" `
-BlobType "Block" `
-Context $storageContext `
-Verbose
できたら公開します。
6.アラートの設定
次にアラートを設定していきます。
「モニター」 ⇒ 「アラート」を開き、「新しいアラートルール」を選択。
スコープをApplicationgatewayにし、「UnHealthy host count」が1以上の場合にアラートを出すように設定します。
アクションとして、自分にメールを出すのと、先ほど作成した「ApplicationgatewayHealthcheck」のRunbookを実行するように指定します。
アラートルールなどを設定し、作成します。
これで設定完了です!
7.動作確認
では早速動作確認。
Applicationgatewayのバックエンドで、強制的にエラーを出してみます。
今回は、正常性プローブのポート設定を、「80」から「81」に変更しました。
バックエンド正常性を確認すると…
はい、ちゃんと「異常」になってますね。
すると、アラートが飛びます。
同時にAutomationが走り…ストレージアカウントを見てみると、ちゃんとログファイルが保存されていました!
ダウンロードして中身を見てみると、ちゃんとバックエンド情報が記録されていました!
BackendAddressPools : {Microsoft.Azure.Commands.Network.Models.PSApplicationGatewayBackendHealthPool}
BackendAddressPoolsText : [
{
"BackendAddressPool": {
"Id": "/subscriptions/ /resourceGroups/Applicationgat
eway/providers/Microsoft.Network/applicationGateways/Applicationgateway/backendAddressPools/po
ol"
},
"BackendHttpSettingsCollection": [
{
"BackendHttpSettings": {
"TrustedRootCertificates": [],
"Id": "/subscriptions/ /resourceGroups/Applicatio
ngateway/providers/Microsoft.Network/applicationGateways/Applicationgateway/backendHttpSetting
sCollection/http"
},
"Servers": [
{
"Address": "agw-test.azurewebsites.net",
"Health": "Unhealthy"
}
]
}
]
}
]
"Address": "agw-test.azurewebsites.net",
"Health": "Unhealthy"
と記載されているので、「"agw-test.azurewebsites.net"が"Unhealthy"なんだなー」ということがわかります。
9.おわりに
今回はApplicationgatewayの正常性チェックが少し足りないので、自分で足してみた、という感じでした。
めんどくさがらずにSendGirdを設定すればAutomationでMailを送ることもできます!
AzureAutomationを触り始めたときはこんなの実装できないんじゃないか?と思ったものですが、3日ぐらい考えたらいけました。
Azureは頑張れば結構なんでもできますね。
参考
Azモジュールを使ったAzure Automation Runbookの記述方法
https://qiita.com/sakamichihassin/items/736f07c53f86f76b1263
Runbook からメールを送信する
https://docs.microsoft.com/ja-jp/azure/automation/automation-send-email
Azure Automation Runbook をトリガーするアラートを使用する
https://docs.microsoft.com/ja-jp/azure/automation/automation-create-alert-triggered-runbook
Application Gateway のバックエンドの正常性および診断ログ
https://docs.microsoft.com/ja-jp/azure/application-gateway/application-gateway-diagnostics
Author And Source
この問題について(【Azure】ApplicationGatewayバックエンドプールで異常が発生した際にどのバックエンドに異常が発生したのかわかるようにする), 我々は、より多くの情報をここで見つけました https://qiita.com/hikaru_motomiya/items/2de4df96242ce542a37a著者帰属:元の著者の情報は、元のURLに含まれています。著作権は原作者に属する。
Content is automatically searched and collected through network algorithms . If there is a violation . Please contact us . We will adjust (correct author information ,or delete content ) as soon as possible .