Azure Front Doorのバックエンド正常性について確認してみた

 

Azure Front Doorのバックエンド状態(正常に応答しているかどうか)の確認をしてみました。

また、Azure  Monitorの機能を利用してバックエンドの状態が異常な場合に検知するようにしてみました。Azure Monitorを使ってますのでメール送信等を行う事も標準機能で出来ます。

1.Azure Front Doorのメトリックで正常性プローブの応答率がわかる

マイクロソフト様のサイトを確認するとAzure Front Doorのメトリックで、バックエンドへの正常性プローブの応答率がわかるそうです。

https://docs.microsoft.com/ja-jp/azure/frontdoor/front-door-diagnostics

※マイクロソフト様のサイトでは、バックエンドの正常性の割合と記載されています。

実際にAzure Portal上で確認してみました。

メニューのメトリックを選択すると、下記画面が表示されます。ここでBackend Health Percentageを選択するとバックエンドプール全体での応答率(正常な割合)が表示されます。

応答率になるので、バックエンドプールに所属するバックエンドがすべて正常な場合は100%になります。

※バックエンド落としてないにも関わらず、なぜか100%になってなかったりするので、この編は調査が必要かも。という感じです。

バックエンドホスト単位で確認するには、フィルターの追加を使います。

フィルターの追加を選択すると、BackendとBackend Poolが表示されますので、Backendを選択します。そうすると、値の部分に設定しているバックエンドホスト名が表示されます。確認したいバックエンドのホスト名を選択します。

選択するとバックエンドホスト単位での応答率が確認できました。

ここの数値が低い場合は、バックエンドホストがAzure Front Doorの正常性プローブに応答を返せてないという状態になります。

2.Azure Front Doorのバックエンドの応答がない場合にAzure Monitorで検知する

Azure MonitorでAzure Front Doorのメトリック監視が実現出来ました。

まず、Azure Front Doorのメニューで、警告を選択します。表示された画面で新しいアラートルールを選択します。

そうすると、下記画面が表示されますので、条件を選択します。(Azure Monitorの設定か言った場合はリソースの所で、今回設定するFront Doorを選択します。)

   以下の画面が表示されますので、Backend Health Percentageを選択します。

そうするとシグナルロジックの構成画面が表示されます。ここで実際の設定を行います。

    • バックエンドホスト、バックエンドプールすべて監視する
    • しきい値は95%より小さい場合はアラートを発生させる
    • 15分単位での確認とする(15分単位の平均値で表あk)

上記のような設定の場合は、下記のような画面になります。

バックエンドホスト単位、バックエンドプール全体の状態どれを監視するかを選択します。

個別に設定可否を判断する場合は、ディメンションで対象を選択します。すべてを選択する場合は、選択にチェックを入れるとすべての項目が選択されます。

※注意点ですが、選択にチェックを入れるとAzure Front Door側でバックエンドやバックエンドホストを追加すると自動的に監視項目にも追加になります。

何%以下(より小さい)というしきい値を設定すると、バックエンドホスト側へのアクセスに問題がある場合、Azure Monitorで検知ができます。

上記設定が終わったら、完了をクリックします。

アクショングループや、名前等を付けて保存すれば、Azure Monitorでの監視設定が完了になります。

3.Azure Monitorで実際に送信されたメール

実際にアラートメールを送信すると、以下のような内容が記載されたメールが送信されます。

Metric name BackendHealthPercentage
Metric namespace frontdoors/フロントドア名
Dimensions

ResourceId = /subscriptions/サブスクリプションID/resourcegroups/リソースグループ名/providers/Microsoft.Network/frontdoors/フロントドア名

ApplicationEndpoint = バックエンドホスト名(1)

ApplicationEndpointPool = バックエンドホスト名(2)

Time Aggregation Average
Period Over the last 15 mins
Operator LessThan
Threshold 95
Criterion Type StaticThresholdCriterion

 

 

 

Azure Monitorを使ってAzure Application Gateway正常性プローブのステータス変化を検知する

 

Azure Application Gatewayのバックエンド正常性の状態変化を検知する検証を行ってみました。

今回は、Azure  Monitorの機能を利用して検知するようにしてみました。Azure Monitorを使ってますのでメール送信等を行う事も標準機能で可能です。

1.Application Gatewayのメトリックで正常性プローブの状況がわかる

Application Gatewayのメトリックでは、正常なホストの数、異常なホストの数を検知する事ができます。これはV1、V2どちらでも可能です。
このホストの数は、正常性プローブによって正常もしくは異常と判断されたバックエンドの数になります。マイクロソフト様のサイトに記載があります。

https://docs.microsoft.com/ja-jp/azure/application-gateway/application-gateway-metrics#backend-metrics

マイクロソフト様のサイトを読むと、以下のような事が言えます。

    • 正常なホストの数が0の場合は、すべてのバックエンドプールに問題が発生しており、サイトが表示されない状態
    • 異常なホストの数が1以上の場合は、1つ以上のバックエンドプールで異常が発生している状態(特定のバックエンドにあるホストが停止している状態

したがって、この状態を監視することにより、Application Gateway経由のバックエンド正常性がわかるのではないかと考えてみました。

2.すべての正常性プローブがNGになった場合に検知する

Azure MonitorでApplication Gatewayのメトリックを監視することができます。

まず、モニター>アラート>新しいアラートルールを選択します。

そうすると、下記画面が表示されますので、リソースの選択でアプリケーションゲートウェイを選択します。

    選択が終わったら、完了を押します。

ルールの作成画面に戻りますので、次に条件の項目で追加を選択してください。

そうすると、下記のようにシグナルロジックの構成が表示されます。

ここに項目が表示されるのですが、今回対象とする項目は下記2つになります。

    • Unhealthy Host Count が異常なホストの数になります
    • Healthy Host Count が正常なホストの数になります

すべて正常性プローブがNGになった場合の検出は正常なホストの数で設定をします。

Healthy Host Countを選択をすると下記のような画面が表示されます。バックエンドのサーバが1つ(ルールもHTTP用1つ)で検証していますので、以下のように1となります。

これが、0になると、正常なバックエンドがなくなる為、すべてのアクセスが停止する状態になります。ですので以下のような設定とします。

    • しきい値:Static
    • 演算子:より小さい
    • 集計の種類:平均
    • しきい値(演算子の方):1

1より小さいとなりますので、バックエンド正常性がNGだった場合(一時的な状態を含む)が検出される事になります。

評価基準は適時選択してください。最後に完了ボタンを選択します。

ルールの作成画面に戻りますので、アクショングループの選択、アラートの詳細を適時記入し、アラートルールの作成をクリックします。

これで、Azure MonitorでApplication Gatewayのバックエンド正常性がすべてNGになった場合に、アラートを発生させることができます。

3.1つでも正常性プローブに異常があった場合に検知する

1つ以上の正常性プローブがNGになった場合の検出は異常なホスト数で行います。

シグナルロジックの構成で、Unhealthy Host Countを選択します。

そうすると、下記画面が表示されます。

すべてのバックエンド正常性がOKなので、0になります。

これが0より大きい場合は、バックエンド正常性に問題が発生している事を示します。ですので、下記のように設定にします。

    • しきい値:Static
    • 演算子:より大きい
    • 集計の種類:平均
    • しきい値(演算子):0

評価基準は適時選択し完了ボタンを選択します。

ルールの作成画面に戻りますので、同様に、アクショングループの選択、アラートの詳細を適時記入し、アラートルールの作成をクリックします。

これで、Azure MonitorでApplication Gatewayのバックエンド正常性で1つでもNGになっている場合に、アラートを発生させることができます。

 

Azure Virtual Machine Bシリーズの残CPUクレジットを確認してみた

 

Azure Virtual Machineのシリーズの1つに、Bシリーズがあります。

Bシリーズは普段使わないCPUの使用量を貯めておいて、負荷が高くなった時にその貯めたCPU使用量を使うシリーズです。Dシリーズよりも大体2分の1位の使用料金で使える為、普段からCPUをガンガンに使わないVirtual Machineに向いています。

詳細は下記マイクロソフト様のサイトに記載があります。

https://azure.microsoft.com/ja-jp/pricing/details/virtual-machines/series/

https://docs.microsoft.com/ja-jp/azure/virtual-machines/sizes-b-series-burstable

Bシリーズを使っている時に、このクレジット残量がどの位残っているのか気になったので、このクレジット量を把握する為の方法を確認してみました。

1 .BシリーズのCPUクレジット残をAzure Portal上で確認する

Azure Portal上で簡単に確認ができます。

Virtual Machineのメニューで監視の区分にあるメトリックという項目を選択します。

このメトリックを選択すると、下記のように項目を選ぶとグラフが表示されます。この項目でCPU Credits Remainingを選択すると過去のクレジット残の履歴確認ができます。

.BシリーズのCPUクレジット残をPower Shellを使って確認する

Power Shellでも値が確認できます。今回は直近の値を確認しています。

サブスクリプションIDやリソースグループ名は環境に合わせて設定します。また、Power Shell実行時に、取得したいVirtual Machine名を指定します。

Get-Dateで取得した日付フォーマットそのままだとエラーになるので、フォーマットを変更しています。StartTime等を変更することにより、過去の値も取得可能です。

#CPU Credits Remaining

param (
    [String] [Parameter(Mandatory=$true)]  $VMname
    )

$subscriptionID =“サブスクリプションID”
$RGName = “リソースグループ名”

$startTime = (Get-Date).AddMinutes(-3) | Get-Date  -Format ‘yyyy-MM-dd THH:mm’
$endTime = Get-Date -Format “yyyy-MM-dd THH:mm”
 
# 注意-ResourceIdの行は折り返していますが、実際には1行です。GitHubの方を参考にして下さい
# https://github.com/Tama-negi/Li-akb-branch-office/tree/PowerShell_Azure/Azure_PowerShell

(Get-AzMetric `
    -ResourceId “/subscriptions/$subscriptionID/resourceGroups/$RGName/providers/Microsoft.Compute/virtualMachines/$VMname” `
    -TimeGrain 00:01:00 `
    -AggregationType “Average” `
    -StartTime $startTime `
    -EndTime $endTime `
    -MetricName “CPU Credits Remaining” `
    -DetailedOutput).Data `
| Select-Object TimeStamp,Average
 

実行すると以下のように結果が得られます。

TimeStamp Average

——— ——-

2020/04/16 10:20:00 316.12
2020/04/16 10:21:00 316.12
2020/04/16 10:22:00 316.12
 

※MetricNameの値を、CPU Credits Consumedに変更することにより、1分間にどれだけクレジットがたまっているかの確認が可能です。

.Azure Monitorにも設定があります

Azure Monitorの設定のメトリックにも、CPU Credits Remainingの項目があります。閾値を設定する事で、残量が少なくなったら、アラートを上げる事も可能です。 

ARMテンプレートを使ってAzure Monitorのアクショングループをデプロイしてみた

 

Azure MonitorのアクショングループをARMテンプレートを利用してデプロイしてみました。今回はメール送信のアクショングループを作成してみました。下記サイトのARMテンプレートを参考に作成しています。

https://docs.microsoft.com/ja-jp/azure/azure-monitor/platform/action-groups-create-resource-manager-template

ARMテンプレート内のvariables 関数で変数を指定するようにしてます。

今回作成した内容はGithubにも公開しています。

.アクショングループで設定する内容

Azure Monitorのアラートを選択します。アクションの管理が表示されるので選択し、表示されるアクショングループの追加をクリックします。そうすると、以下の画面が表示されます。

今回、指定する値は、以下の通りになります。

  • アクショングループ名
  • 短い名前
  • サブスクリプション(デプロイ時に指定します)
  • リソースグループ(デプロイ時に指定します)
  • 操作名
  • アクションの種類(今回は電子メールを想定しま。)
  • 電子メールアドレス(アクションの種類で電子メールを選択すると入力できます)

.アクショングループのARMテンプレートを作成する

電子メールを送信するアクショングループのテンプレートは下記のようになります。テンプレート内のemailReceiversが電子メールに関するアクションを定義する項目になります。

{
 ”$schema”: “https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#”,
 ”contentVersion”: “1.0.0.0”,
 ”variables”: {
   “actionGroupName”: “アクショングループ名”,
   “actionGroupShortName”: “短い名前”,
   “OperationName”: “操作名”,
   “emailAddress”: “送信先の電子メールアドレス”
    },

  },
  ”resources”: [
  {
   ”type”: “Microsoft.Insights/actionGroups”,
   ”apiVersion”: “2018-03-01”,
   ”name”: “[variables(‘actionGroupName’)]”,
   ”location”: “Global”,
   ”properties”: {
    ”groupShortName”: “[variables(‘actionGroupShortName’)]”,
    ”enabled”: true,
    ”emailReceivers”: [
     {
     ”name”: “[variables(‘OperationName’)]”,
     ”emailAddress”: “[variables(‘emailAddress’)]”
     }
    ]
   }
  }
 ],
 ”outputs”:{
  ”actionGroupId”:{
  ”type”:”string”,
  ”value”:”[resourceId(‘Microsoft.Insights/actionGroups’,variables(‘actionGroupName’))]”
  }
 }
}

.Power ShellでARMテンプレートをデプロイする

最後に、作成したARMテンプレートをPower Shellでデプロイします。デプロイ方法は下記を参考にしています。Power Shell実行時に、Action Groupを作成するリソースグループ名を指定します。

https://docs.microsoft.com/ja-jp/azure/azure-resource-manager/templates/deploy-powershell#deploy-local-template

#テンプレートをデプロイするPowerShell
$resourceGroupName = Read-Host -Prompt “Enter the Resource Group name”
$TemplateFilePath = “テンプレートファイルのパス(ex;”C:\tmp\ActionGroup_templete.json”)”

New-AzResourceGroupDeployment -ResourceGroupName $resourceGroupName `
-TemplateFile $TemplateFilePath
 

最後に以下のPower Shellで実際にAction Groupができているか確認します。

$resourceGroupName = “リソースグループ名”
$actionGroupName = “アクショングループ名”

Get-AzActionGroup -ResourceGroupName $resourceGroupName -Name $actionGroupName

 

Azure Monitorのアラート設定に集約という項目が追加されてました

 

Azure Monitorのアラート設定で、LogAnalyticsワークスペース-Custom log searchにを指定した際に集約という項目が追加されてました。

https://docs.microsoft.com/ja-jp/azure/azure-monitor/platform/alerts-unified-log#metric-measurement-alert-rules

詳細は上記サイトに記載の通りですが、これを具体的に言うと、LogAnalyticsワークスペース単位でアラート設定を行う場合に正しく集計されないケースがあるという事になります。

1つの例として、以下のような継続して閾値を超えた場合の設定を行うには、Custom log searchを利用し、かつクエリとして仮想マシン単位で指定が必要でした。

監視対象:仮想マシン
監視内容;メモリ監視
閾値;% Used Memoryが80%以上
間隔;5分間
継続回数;3回

集約という項目を使う事により、仮想マシン単位ではなく、LogAnalyticsのワークスペース単位での設定可能になりました。

※Metricを利用してのリソース監視では仮想マシン単位での監視が可能ですが、連続して3回発生した場合等、継続を条件としたような設定ができません。その為、Custom log searchでの設定が必要になります。

1 .Azure Monitorに設定するクエリ(Custom log searchを使う場合)

下記のLogAnalyticsクエリで、ワークスペースに接続された仮想マシンの% Used Memoryを仮想マシン単位で取得可能です。 しかし、このクエリをAzure Monitorのクエリとして設定しても、ワークスペースに接続された仮想マシンの平均値で認識されるため、正しくアラート検知されませんでした。(平均値として認識されるのはAzure Monitorの仕様だそうです。)

#LogAnalyticsクエリ(メモリ使用率取得)
Perf
| where ( ObjectName == ‘Memory’ )
| where ( CounterName == ‘% Used Memory’ )
| summarize AggregatedValue=avg(CounterValue) by bin(TimeGenerated, 5m), Computer

Azure Monitorに設定するクエリとしては、下記のように、仮想マシンを明示的に指定する必要がありました。

#LogAnalyticsクエリ(メモリ使用率取得)
Perf
| where ( Computer == ‘VM名‘ )`
| where ( ObjectName == ‘Memory’ )
| where ( CounterName == ‘% Used Memory’ )

| summarize AggregatedValue=avg(CounterValue) by bin(TimeGenerated, 5m)

※リソースを収集するためには、事前にLogAnalytics側の設定で、パフォーマンスカウンターの取得設定が必要です。

.集約を利用する。

集約を使う事により、以下のクエリをAzure Monitorでも正しくクエリを認識させる事ができます。

#LogAnalyticsクエリ(メモリ使用率取得)
Perf
| where ( ObjectName == ‘Memory’ )
| where ( CounterName == ‘% Used Memory’ )
| summarize AggregatedValue=avg(CounterValue) by bin(TimeGenerated, 5m), Computer

集約に表示されるのはクエリ内でbyで設定された項目になります。実際の設定は下記画面の通りになります。
今回の場合、集約という項目にComputerが表示されますので、これを選択します。

Computerを指定することにより、以下のクエリでもLogAnalyticsワークスペースに接続された仮想マシンのリソースをAzure Monitor上でも期待した動作をしてくれます。

.集約を使う事のメリット。

ワークスペース単位での指定になるため、仮想マシンがワークスペースに接続された段階でAzure Monitorの設定変更する事なく、監視が開始できます。
また1つのアラートルールで済むため、コスト削減のメリットもあります。
非常に、細かい部分での機能になりますが、メリットは十分にあるかと思います。

Azure Monitorを使ってLog Analytics(OMSエージェント)の死活監視を行う(Metricを使う)

 

前回の続きになります。

Log AnalyticsでVirtual Machineのログ取得を行う場合、OMSエージェント自体が動作していないと、ログ取得が行えません。

Azure Monitorを使ってOMSエージェントからLog Analyticsへ送信されているHeartBeatを監視することで、OMSエージェントが正常に動作しているかの監視を行えます。

Azure MonitorのCustom log searchを使う方法と、Metricを使う方法がありますが、今回はMetricを使う方法で実施します。(前回はCustom log searchで実施しました。)

1.監視設定方法

実際に関しを行うには、Azure Monitorの機能を利用して実施します。

1. 以下にアクセスし、[+ 新しいアラート ルール] をクリックします。
[Azure ポータル] – [Log Analytics ワークスペース] – [<対象のワークスペース>]
– [警告]

2. “リソース” が Log Analytics ワークスペースとなっていることを確認します。

3. “条件” にて以下を設定します。
シグナル名 : Heartbeat
シグナルの種類 : Metric
サービスの監視 : プラットフォーム

4. “シグナル ロジックの構成” にて、以下を選択します。
ディメンション名 Computer の “選択” にチェックを入れます。

*  対象のLog Analytics ワークスペースに接続されているすべての仮想マシンが対象となります。

5. “アラート ロジック” にて以下を設定します。
しきい値 : Static
演算子 : 次の値より小さい
集計の種類 : 合計
しきい値 : 1

6. “評価基準” にて以下を設定します。
集約粒度 (期間) : 15 分
評価の頻度 : 5 分

7. アクションにて電子メールの送信を行うアクションを追加します。

8. アラート ルール名を入力し、作成します。

2.実際のアラートメール

OMSエージェントを停止し、15分経過すると以下のメールが来ます。

どのVMのOMSエージェントが停止したかは、Dimensionsに記載されます。

Suject:Azure: Activated Severity: 3  ”アラート名”

 

Dimensions ResourceId = /subscriptions/XXXXXXXXXXXXX/resourceGroups/RG名/providers/Microsoft.OperationalInsights/workspaces/ワークスペース名-01Computer = ”VM名”

3.MetricとCustom log searchで設定した場合の違い

主な違いは以下のような感じになります。Log AnalyticsのHeartBeat監視の場合は、Metricを使った方が良さそうな感じです。

・メール送信タイミングが異なる

 Custom log searchを使用した場合は、回復するまでメールが送信され続けます。

 Metricを使用した場合は、発生時と回復時にのみメールが送信されます。

・コストは、Metricで設定した場合の方が安い。

・Metricで設定する場合は、仮想マシンを一括して設定可能。VM追加時も自動で監視追加できる。

 

Azure Monitorを使ってLog Analytics(OMSエージェント)の死活監視を行う(Custom log search)

 

Azure Virtual Machineのログ取得をLog Analyticsで行う場合の転送状況監視をAzure Monitorを使って実施してみました。

Virtual MachineからLog Analyticsへのログ転送は、Virtual MachineにインストールされたOMSエージェントで実施されます。その為、OMSエージェントが停止していた場合は、Virtual Machineが動作していてもログ転送が行われません。

OMSエージェントは死活監視のために、1分おきにLog AnalyticsへHeartBeatを送信します。

Log AnalyticsでHeartBeatが取得出来ているかを監視することで、Log AnalyticsとVirtual Machine間がアクセス状況の監視を行えます。

Azure MonitorのCustom log searchを使う方法と、メトリックを使う方法がありますが、今回はCustom log searchを使う方法で実施します。

1.HeartBeatの時刻取得

Log Analytics上で以下のクエリを実行すると、最後にHeartBeatアクセスがあった時刻を取得することが可能です。

Heartbeat | where Computer==“VM名” | summarize max(TimeGenerated) 

実際に取得される値

2019-08-21T11:23:06.600

2.監視設定方法

実際に関しを行うには、Azure Monitorの機能を利用して実施します。

1. 以下にアクセスし、[+ 新しいアラート ルール] をクリックします。
[Azure ポータル] – [Log Analytics ワークスペース] – [<対象のワークスペース>]
– [警告]

2. “リソース” が Log Analytics ワークスペースとなっていることを確認します。

3. “条件” にて以下を設定します。
シグナル名 : Custom log search
シグナルの種類 : Log
サービスの監視 :Log Analytics

4.”検索クエリ”に以下の内容を設定します。

Heartbeat | where Computer==“VM名” | summarize max(TimeGenerated) by Computer | where LastCall < ago(5m)

5. “アラート ロジック” にて以下を設定します。
しきい値 : Static
演算子 : 次の値より大きい
集計の種類 : 結果の数
しきい値 : 0

6. “評価基準” にて以下を設定します。
集約粒度 (期間) : 15 分
評価の頻度 : 5 分

7. アクションにて電子メールの送信を行うアクションを追加します。

8. アラート ルール名を入力し、作成します。

3.実際のアラートメール

OMSエージェントを停止し、15分経過すると以下のメールが来ます。

Suject:We are notifying you because there are 1 counts of ”アラート名”

※Custom log searchを使うと、回復するまでメールが送信され続けます。