Azure 存儲隊列監(jiān)控：追蹤單個隊列長度

簡而言之：Azure 存儲隊列缺乏內(nèi)置的單個隊列長度指標。但是，您可以使用 Azure SDK 查詢 approximate_message_count 並追蹤每個隊列的長度。使用 OpenTelemetry 將此數(shù)據(jù)作為自定義指標發(fā)出。一個示例項目可用於通過 Azure 函數(shù)自動化此過程，實現(xiàn)可靠且可擴展的監(jiān)控。

如果您使用 Azure 存儲隊列，並且需要（或者只是想要）單獨監(jiān)控每個隊列的長度，那麼我有一些壞消息。 ?

Azure 只通過其內(nèi)置指標功能提供整個存儲帳戶的總消息數(shù)指標。不幸的是，如果您需要追蹤單個隊列的消息數(shù)，這使得這些內(nèi)置指標不太有用。

上圖顯示了內(nèi)置指標的示例。在任何給定時間都有兩個隊列，但我們無法識別各個隊列中有多少消息。篩選功能被禁用，並且沒有針對隊列消息計數(shù)的特定指標，如下所示。

為什麼監(jiān)控單個隊列長度很重要？

監(jiān)控單個隊列長度可能很重要，原因如下。例如，如果您管理多個隊列，您可能希望：

• 追蹤毒性消息隊列 以避免系統(tǒng)中斷。
• 監(jiān)控特定隊列的壓力 以確保它們高效地處理消息。
• 管理縮放決策 通過觀察隊列在不同負載下的增長情況。

無論您是在調(diào)試還是縮放，了解每個隊列的消息計數(shù)都有助於保持系統(tǒng)的健康。

好消息?

雖然 Azure 沒有提供開箱即用的此功能，但有一個簡單的解決方法，本博文將引導您完成此過程。

如何獲取您的指標

如前所述，Azure 沒有將單個存儲隊列長度作為內(nèi)置指標提供。鑑於人們在過去五年中一直在要求此功能，對於 Microsoft 來說，將其作為標準指標實現(xiàn)可能並非一項簡單的任務。因此，找到一種解決方法可能是您的最佳選擇。

自然地，這導致了這樣一個問題：如果標準指標沒有提供此功能，還有其他方法可以獲取它嗎？ ?

仔細查看 Azure 存儲帳戶 SDK 會發(fā)現(xiàn)隊列屬性 approximate_message_count，它可以讓您訪問所需的信息——只是通過不同的方法。

知道了這一點，如果您能夠使用此數(shù)據(jù)將隊列長度作為指標進行追蹤，豈不是很好？

這是一個想法：如果您這樣做呢？ ?

您可以查詢每個佇列的長度，建立指標量規(guī)並定期更新值。

讓我們逐步分解它。

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-approximate-messages-count: int-value
• .NET - ApproximateMessagesCount
• Java - getApproximateMessagesCount()

2. 建立量規(guī)並發(fā)出指標

接下來，您建立一個量規(guī)指標來追蹤佇列長度。

量規(guī) 是一種測量特定時間點值的指標類型，使其非常適合追蹤不斷變化的佇列長度。

為此，我們將使用 OpenTelemetry，這是一個開源可觀察性框架，因其在收集指標、追蹤和日誌方面的多功能性而越來越受歡迎。 以下是使用 OpenTelemetry 發(fā)出佇列長度作為量規(guī)的範例：

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 的另一個優(yōu)點是它與各種可觀察性工具（如 Prometheus、Azure Application Insights、Grafana 等）的整合非常好。

3. 使其適應生產(chǎn)環(huán)境

雖然上述方法非常適合實驗，但您可能需要一個更強大的解決方案來適應生產(chǎn)環(huán)境。這就是彈性和可擴展性發(fā)揮作用的地方。

在生產(chǎn)環(huán)境中，持續(xù)監(jiān)控佇列不僅僅是提取指標。您需要確保系統(tǒng)可靠、能夠根據(jù)需求進行擴展，並能夠處理潛在的故障（例如網(wǎng)路問題或大量資料）。例如，您不希望失敗的查詢會停止您的監(jiān)控過程。

如果您有興趣了解如何使其適應生產(chǎn)環(huán)境，我已經(jīng)建立了一個範例專案：azure-storage-queue-monitor。此專案將我們討論的所有內(nèi)容包裝到在計時器觸發(fā)器上執(zhí)行的 Azure 函數(shù)中。它處理彈性、並發(fā)性和可擴展性，確保您可以可靠地監(jiān)控佇列。

結論

現(xiàn)在您已經(jīng)掌握了追蹤單一佇列長度並將其作為自訂指標發(fā)出的步驟，您可以為自己的環(huán)境設定此功能。如果您嘗試一下，請隨時分享您的經(jīng)驗或改進——我很樂意聽到您的想法，並在您遇到任何問題時提供幫助！

祝您隊列監(jiān)控愉快！ ?

以上是如何監(jiān)視各個 Azure 儲存佇列的長度的詳細內(nèi)容。更多資訊請關注PHP中文網(wǎng)其他相關文章！