あるあるな Queue の監視ですが、自前でやらなきゃいけないなら Serverless でぺちって任せるのは楽ちんですよ、というのはよくあるパターンです。 実際にQueue Storage のモニタリングをしてみましょう。
TL;DR
Azure Storage Queue や Service Bus などのキューサービスは、疎結合な構成を組んだ時に中心を担うため、そのキュー長が想定よりたまっていないか、推移はどうなっているかなどが気になります。
この監視を、Azure Functions の Timer Trigger で行ってみましょう。
Disclaimer
Datadog や 複数のモニタリングサービスは、Azure のAPIをたたいて自分でクラウドリソースのメトリクスを見に行ってくれます。もしそれらで済むならこの記事は不要です、すぐに閉じましょう。この記事は、自分でリソースの状態をポーリングするときの対応例です。
Consumption Planを前提に毎30秒監視しています。(2 * 60 * 24 * 30 = 86400run) 無料枠内ですが、料金がどうなっても私は責任は取りかねます。(免責事項)
なぜ AzureFunctions なのか
モニタリングはアプリケーションの内部リソースと、クラウドなどの外部リソースで分けて考えられます。
アプリがスケールしたときに個別のアプリのメトリクスが見たければ、アプリケーションで監視するのが妥当な場合が多いのは同意を得られるかと思います。一方で、アプリケーションの外にあるリソースは、アプリケーションからモニタリングする必然性はありません。おのずと次のような欲求が高まってきます。
- アプリケーション自身のリソースをモニタリングに消費したくない
- モニタリング自身がスケールして重複した値が取れてほしくない
- アプリケーション自身が、どのようなリソースに依存んして動いているのか関心がない
自前でメトリクスを見たいときは、どこかで実行する必要があります。しかしアプリケーションでは実行したくありません。監視対象を定義しておいて、メトリクスを取得するだけのシンプルな監視の場合、Serverless でアプリケーションとは別個の存在として実行させるのが便利です。
Azure Storage Queue なら、Azure Functions の Consumption Plan + Timer Trigger が定時ポーリング監視になり、定性モニタリングとして負荷なく実行できるでしょう。
監視対象
Azure でキューといえば、Azure Storage Queue と Service Bus がありますが、さくっと Storage Queue で確認してみましょう。ここでは myqueue というキューを用意して監視することにします。
- myqueue : Storage Queue API で通常投げつけるQueueです。主にこの子が気になる
- myqueue-poison : WebJobs で失敗した時に自動的に作成されるQueueで
-posisonが末尾につきます。手動でなんとかすることになります
なお、Storage Queue は Dead Letter Queue (DLQ) に対応していないのでまぁほげもげ。
実行環境
- Function Runtime: v2
- Language: C# (.NET Core 2.1)
- Trigger: Timer Trigger (毎30秒)
- Metrics: Queue Length
- Monitoring: Application Insights
Azure Functions
Azure Functions は、v2 においても裏で Application Insights を使っています。
とはいえ、明示的にMicrosoft.ApplicationInsights パッケージを取り込まないと、アプリからApplication Insights をたたけないので入れておきます。
dotnet add package Microsoft.ApplicationInsights
メトリクスを送信するため、Azure Functions の Application Configで Application Insights の Instrumentation Key を設定します。もし Azure Functions の Application Insights にメトリクスを飛ばすのでいいなら APPINSIGHTS_INSTRUMENTATIONKEY でいいでしょう。
Queueに接続するため、QueueがあるStorage Account のConnection Strings を設定しておきます。ここでは、queue_storage_connection_string としました。
では実際に実行してみましょう。コードはこのような感じになります。
これで毎10秒ごとにQueue の長さをモニタリングして、Application Insights に投げられます。ローカルで実行した場合、コンソールにQueueの長さがでるでしょう。
Application Insights の確認
今回はAzure FunctionsのApplication Insights 連携に乗っかているので見てみます。
ちょうどQueue を投げてなかったので0 が継続して取れているのがわかります。
あとは Azure Monitor という名のApplication Insights の閾値による Action で Webhook なりを投げるといいでしょう。Body の調整できない子ですが。
Tips
Cloud Table とか絡んでくると、いまだにMicrosoft.WindowsAzure.Storage パッケージが安定なので、Azureの NuGet パッケージつらい。
Ref
やろうとしたら、だいたいすでにやってるKloudさんつよい。v1 ですが、だいたいやっていることは一緒です。
Monitoring Azure Storage Queues with Application Insights and Azure Monitor - Kloud Blog
