Azure仮想マシンの死活監視をHeartBeatでやる時の考慮点
Azure仮想マシンの死活監視をやる場合、大きく
・自分でHeartBeat機構を実装する
・Azure Monitor Agentを使ってLogAnalytics+Azure Monitorで実現する
の2パターンがあります。
この記事では、LogAnalytics+Azure Monitorの構成で実装する場合の注意点を記載します。
Azureの機構のみで死活監視を実現する
基本的には、ここに書いてある仕組みで実現できます。
仕組みとしては簡単で、Azure Monitor Agentを利用すると、1分ごとにHeartBeatがLogAnalytics Workspaceに送信されますので、このHeartBeatログをLogAnalyticsに取集します。Azure Monitorで定期的にLogAnalyticsのクエリを発行し、ある期間(例えば5分)の間にHeartBeatが何回受信されているかをカウントします。もし、HeartBeatの受信回数が、一定回数を下回った場合は、VMが稼働していないと判断して、アラートを発火します。
AzureVM死活監視の注意点
ただ、この仕組みには、自分で注意点があります。
それは、LogAnalyticsにログが転送されて、クエリで検索できるようになるまで、一定程度の時間がかかるというものです。
これは、公式ドキュメントの下記の記事にも記載されています。
抜粋：
待機時間は、データが監視対象のシステムで作成される時間と Azure Monitor で分析に使用できるようになる時間を指します。 ログ データを取り込むための一般的な待ち時間は 20 秒から 3 分です。 ただし、特定のデータに対する具体的な待機時間は、次に説明するさまざまな要因によって異なります。
要するに、「1分に一回HeartBeatは受信するけど、実際にアラートに使えるようになるまで、3分くらいかかりますよ。」ということです。
実は、この遅延によく嵌ります。なぜかというと、例えば、5分間隔で、この5分以内にHeartBeatを受信した数が3個以下(2個届いていない)ならアラートを発火するとします。この場合、各HeartBeatが検索できるようになるまで、3分遅延すると、確実にアラートが発火します。
例えば、以下の表を見るとわかりやすいのですが、HeartBeatを受信して検索可能になるまで、3分かかるとします。
この時、ある日の10:05に実施されるAzure Monitorのクエリ処理では、10:00 - 10:05で何個HeartBeatが受信されたかを確認します。この時、実際に毎分受信しているのですが、グレーアウトした部分は検索できないので、3つ受信となり、アラートが発火されます。
待機時間に対する対処方法
公式サイトにもあるように、さまざまな理由があることから、待機時間を完璧に予測してアラートルールやクエリを作成することは不可能です。
(少なくとも、公式に出ている情報からは実現できません)
そのため、例えば、3分は待機時間があることを想定して、評価時間の枠を5分間隔ではなく10分や15分間隔といった幅にし、待機時間を想定した閾値を設定する必要があります。
待機時間が原因でのアラートかどうかの確認方法
実は、こちらは確認可能です。
具体的には、こちらで紹介されている。ingestion_time()関数を利用して、LogAnalyticsでクエリーを発行するだけです。
上記を参考に例えば、以下のクエリをLogAnalyticsで発行するとわかります。
Heartbeat
| where Resource contains "<仮想マシンのリソース名>"
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated
| extend QueryOKTime = TimeGenerated + E2EIngestionLatency
| project TimeGenerated, E2EIngestionLatency, QueryOKTime
結果としては、例えば以下のような結果が取得できます。
ここで、E3EIngestionLatencyがLogAnalyticsワークスペースにデータを受信してから、検索が可能になるまでにかかった時間、QueryOKTimeが実際にLogAnalyticsのクエリーで検索可能になった時間となります。
例の結果を見ても、検索可能になるまでに少し待機時間があることがわかります。
今回は以上となります。
HeartBeatのアラートが出てもアラートの原因が自分で調査ができると、原因判明までの時間が短縮できて少し安心できます！