Azure Application Gatewayバックエンド正常性の確認方法から監視設定纏め

2020-05-03Application Gateway,Azure,Monitor

アプリケーションゲートウェイ(Azure Application Gateway)はWEBアクセスをL7のレイヤーで負荷分散するロードバランサーです。

Azure Application Gateway とは

アプリケーションゲートウェイ(Azure Application Gateway)はバックエンドの状態を監視し正常な場合のみロードバランシングします。
WEBサービス状態の管理としてアプリケーションゲートウェイ(Azure Application Gateway)のバックエンドの状況を把握しておく事が重要になります。
ロードバランシング先の状態はバックエンド正常性としてAzure Portal上で確認する事が出来ます。
バックエンドの正常なホストの数はHealthy Host Countとして、異常なホストの数はUnhealthy Host Countのメトリックとして確認出来ます。 

今回はアプリケーションゲートウェイ(Azure Application Gateway)のバックエンド正常性監視方法について纏めててみました。

アプリケーションゲートウェイ(Azure Application Gateway)の構築手順についてはこちらに纏めています。

スポンサーリンク

バックエンド正常性を確認する方法

今回は以下のアプリケーションゲートウェイ(Azure Application Gateway)を利用しています。

    • リソース名:agw-test-01
    • リソースグループ名:RG-AGW-TEST-01
    • バックエンドプール名:Backend-pool-01
    • バックエンド設定名:Backend-setting-01

Azure Portalで確認

バックエンド正常性のリソースメニューで確認出来ます。

Azure Portalで確認
ホスト(サーバー)単位でバックエンドの正常性を見る事が出来ます。
異常時はエラー内容を表示してくれます。

【正常時】

【異常時】

メトリックで確認

バックエンド正常性に関連するメトリックとして正常なホストの数(Healthy Host Count)と異常なホストの数(Unhealthy Host Count)があります。
それぞれバックエンドプールのサーバー(ホスト)のステータス毎の数を示しています。

バックエンド メトリック(公式サイト)

※画面はバックエンドのサーバー2台のうち1台が異常な状態から2台共に異常になった場合の例です。

メトリックで確認
正常なホストの数(Healthy Host Count)の例です。
途中で正常な状態のサーバーが0になっている事が確認出来ます。
異常なホストの数(Unhealthy Host Count)の例です。
途中で異常なホストが1台から2台に増えた事が確認出来ます。

PowerShellで確認

Get-AzApplicationGatewayBackendHealthコマンドレットを利用します。

Get-AzApplicationGatewayBackendHealth

PowerShellで確認

PS C:> $rg = “アプリケーションゲートウェイのリソースグループ名"
PS C:> $agwname = “アプリケーションゲートウェイ名"
PS C:> Get-AzApplicationGatewayBackendHealth
-Name $agwname -ResourceGroupName $rg

Azure CLIで確認

az network application-gateway show-backend-healthを利用します。

az network application-gateway show-backend-health

Azure CLIで確認

PS C:> $rg = “アプリケーションゲートウェイのリソースグループ名"
PS C:> $agwname = “アプリケーションゲートウェイ名"
PS C:> az network application-gateway show-backend-health -g $rg -n
$agwname

#結果抜粋
“address": “10.0.4.4",
“health": “Healthy",
“healthProbeLog": “Success. Received 200 status code",

“address": “10.0.3.4",
“health": “Healthy",
“healthProbeLog": “Success. Received 200 status code",

Azure Monitorでバックエンド正常性のアラートルールを作成

アラートルール設定

今回はバックエンドサーバー2台の構成としています。
異常なホストの数(Unhealthy Host Count)と正常なホストの数(Healthy Host Count)をそれぞれ監視するアラートルールを作成します。

    • 異常なホストの数(Unhealthy Host Count)を監視
      • アラールール名:AGW Unhealthy Host Count
      • 条件:異常なホストの数が5分平均で0より大きい場合
    • 正常なホストの数(Healthy Host Count)を監視
      • アラールール名:AGW Unhealthy Host Count
      • 条件:正常なホストの数が5分平均で1より小さい場合
アラートルール名 異常なサーバーの数
0台 1台 2台
AGW Unhealthy Host Count ×
AGW Healthy Host Count × ×

異常なホストの数(Unhealthy Host Count)を監視

異常なホストの数を監視する事でバックエンドのサーバーで異常が発生した事を検知出来ます。
今回はサーバー1台以上に異常が発生した場合にアラート検知するようにしています。

アラートルール作成
アプリケーションゲートウェイのリソースメニューで警告を選択します。
作成でアラートルールを選択します。
シグナルの選択でUnhealthy Host Countを選択します。
条件設定です。
アラートロジックを0より大きい場合とします。

ディメンションの分割ではBacendPool HttpSettingsを選択します。
バックエンドプール(バックエンド設定)単位で検知するよう設定します。

評価するタイミングはそれぞれ5分としています。

アクショングループではメール送信のアクショングループを選択します。

※アクショングループは事前に作成したものを利用しています。

詳細でアラートルール名や重要度を設定します。
アラートルール名はAGW Unhealthy Host Countとしています。

確認および作成に進みアラートルールを作成します。

正常なホストの数(Healthy Host Count)を監視

正常なホストの数を監視する事でバックエンドのサーバーが一定数を下回った(全台停止など)が発生した事を検知出来ます。
今回は正常なサーバーが無くなった(平均が1を下回った)場合にアラート検知するようにしています。

アラートルール作成
アプリケーションゲートウェイのリソースメニューで警告を選択します。
作成でアラートルールを選択します。
シグナルの選択でHealthy Host Countを選択します。
条件設定です。
アラートロジックを1より小さい場合とします。

ディメンションの分割ではBacendPool HttpSettingsを選択します。
バックエンドプール(バックエンド設定)単位で検知するよう設定します。

評価するタイミングはそれぞれ5分としています。

アクショングループではメール送信のアクショングループを選択します。

※アクショングループは事前に作成したものを利用しています。

詳細でアラートルール名や重要度を設定します。
アラートルール名はAGW Healthy Host Countとしています。

確認および作成に進みアラートルールを作成します。

作成されたアラートルール

アラートルールが作成されている事が確認出来ます。

アラートルール一覧
2つのアラートルールが確認出来ます。

アラートメールの例

正常なホストの数(Healthy Host Count)のが0台になった場合のアラートメールです。
アラートルール(AGW Healthy Host Count)で検知した場合です。

アラートメール例
AGW Healthy Host Countが5分平均1以下になったのでアラートとなっています。

最後に

今回はアプリケーションゲートウェイ(Azure Application Gateway)のバックエンド正常性確認方法からAzure Monitorを監視設定までを纏めてみました。
バックエンド正常性はAzure PortalやAzure PowerShellやAzure CLIでも確認出来ました。
正常なホストの数(Healthy Host Count)や異常なホストの数(Unhealthy Host Count)のメトリックでも確認出来ました。
このメトリックを使ってバックエンド正常性の変化やサービス停止を検知する事が出来ました

今後も引き続き色々試してみたいと思います。

Azure Front Doorのバックエンド正常性監視についてはこちら。

スポンサーリンク