個々のAzureストレージキューの長さを監視する方法

azureストレージキューの監視：単一のキューの長さを追跡

要するに、Azureストレージキューには単一のキュー長インジケーターがありません。ただし、Azure SDKを使用して

を照会し、各キューの長さを追跡できます。 Opentelemetryを使用して、このデータをカスタムインジケーターとして送信します。例のアイテムを使用して、Azure関数を介してこのプロセスを自動化して、信頼性の高いスケーラブルな監視を実現できます。 approximate_message_count

azureを使用してキューを保存し、各キューの長さを個別に監視する必要がある（または必要な）場合、悪いニュースがあります。 ？

Azureは、構築されたインデックス関数を介してストレージアカウント全体のニュースインジケーターの総数のみを提供します。残念ながら、単一のキューのメッセージの数を追跡する必要がある場合、これにより、これらの構築されたインジケータがあまり役に立ちません。

上の図は、構築された-inインジケーターの例を示しています。いつでも2つのキューがありますが、各キュー間の情報の量を認識することはできません。スクリーニング機能は無効になっており、以下に示すように、キューメッセージの特定のインジケーターはありません。

単一のキューの長さを監視することが重要なのはなぜですか？

単一のキューの長さを監視することが重要な場合があります。理由は次のとおりです。たとえば、複数のキューを管理する場合は、次のことを願っています。

システムの中断を避けるために、有毒なメッセージキューを追跡します。

特定のキューの圧力を監視して、メッセージを効率的に処理することを確認します。

スケーリング決定の管理

キューを観察することによる異なる負荷の成長。
• デバッグまたはスケーリングの場合でも、各キューのメッセージカウントを理解することは、システムの健康を維持するのに役立ちます。
• 良いニュース？ Azureはボックスで使用されるこの機能を提供していませんが、このブログがこのプロセスを完了するように導く簡単なソリューションがあります。
インジケータを取得する方法
• 前述のように、Azureは、構築されたインジケーターとして単一のストレージキュー長を提供しませんでした。過去5年間に人々がこの機能を尋ねてきたことを考えると、Microsoftにとって標準指標として実装することは簡単な作業ではないかもしれません。したがって、解決策を見つけることがあなたの最良の選択かもしれません。
当然、これはそのような質問につながります：

標準インジケーターがこの機能を提供しない場合、それを取得する他の方法はありますか？

？

azureストレージアカウントを注意深く確認します。SDKは、異なる方法で必要な情報にアクセスできるキュー属性

を見つけます。 このデータを使用して、キューの長さをインジケーターとして追跡できる場合、これを知っていれば、それは良いことではないでしょうか？

これはアイデアです。これを行うとしたらどうでしょう？ ？

各キューの長さをクエリし、メトリクス ゲージを作成し、値を定期的に更新できます。

段階的に見てみましょう。

1. キューの長さを取得する

Python SDK を使用すると、キューの個々の長さを簡単に取得できます。以下のコード スニペットを参照してください:

from azure.identity import DefaultAzureCredential
from azure.storage.queue import QueueClient

STORAGE_ACCOUNT_URL = "<storage-account-url>"
QUEUE_NAME = "<queue-name>"
STORAGE_ACCOUNT_KEY = "<key>"

credentials = STORAGE_ACCOUNT_KEY or DefaultAzureCredential()
client = QueueClient(
    STORAGE_ACCOUNT_URL,
    queue_name=QUEUE_NAME,
    credential=credentials,
)

try:
    properties = client.get_queue_properties()
    message_count = properties.approximate_message_count
    print(message_count)
except Exception as e:
    logger.exception(e)

SDK は REST API に基づいて構築されているため、同様の機能が他の SDK でも利用できます。他の言語の REST API および SDK へのリファレンスは次のとおりです:

• REST API - x-ms-estimate-messages-count: int-value
• .NET - おおよそのメッセージ数
• Java - getAboutMessagesCount()

2. ルーブリックを作成し、メトリクスを出力する

次に、キューの長さを追跡するためのゲージ メトリックを作成します。

ゲージ は、特定の時点での値を測定するメトリック タイプであり、キューの長さの変化を追跡するのに最適です。

これを行うために、OpenTelemetry を使用します。これは、メトリクス、トレース、ログの収集における多用途性で人気が高まっているオープンソースの可観測性フレームワークです。 OpenTelemetry を使用してキューの長さをゲージとして出力する例を次に示します:

from opentelemetry.metrics import Meter, get_meter_provider

meter = get_meter_provider().get_meter(METER_NAME)

gauge = meter.create_gauge(
    name=gauge_name, description=gauge_description, unit="messages"
)

new_length = None

⋮ # 获取 approximate_message_count 并将其设置为 new_length 的代码

gauge.set(new_length)

OpenTelemetry のもう 1 つの利点は、Prometheus、Azure Application Insights、Grafana などのさまざまな可観測性ツールと非常によく統合されていることです。

3. 実稼働環境に適応させる

上記のアプローチは実験には最適ですが、運用環境ではより堅牢なソリューションが必要になる場合があります。ここで弾力性と拡張性が重要になります。

実稼働環境では、キューの継続的な監視には、単にメトリクスを取得するだけではありません。システムが信頼性があり、需要に応じて拡張でき、潜在的な障害 (ネットワークの問題や大量のデータなど) に対処できることを確認する必要があります。たとえば、クエリの失敗によって監視プロセスが停止することは望ましくありません。

これを運用環境に適応させる方法に興味がある場合は、サンプル プロジェクト azure-storage-queue-monitor を作成しました。このプロジェクトでは、これまで説明してきたすべてを、タイマー トリガーで実行される Azure Function にラップします。復元性、同時実行性、およびスケーラビリティを処理し、キューを確実に監視できるようにします。

結論

個別のキューの長さを追跡し、カスタム メトリックとして出力する手順が完了したので、環境に合わせてこの機能を設定できます。試してみたら、その経験や改善点を遠慮なく共有してください。問題が発生した場合は、ぜひ意見を聞いて助けてください。

キュー監視を楽しんでください! ?

以上が個々のAzureストレージキューの長さを監視する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。