Azure 存儲隊列監控：追踪單個隊列長度
簡而言之：Azure 存儲隊列缺乏內置的單個隊列長度指標。但是，您可以使用 Azure SDK 查詢 approximate_message_count 並追踪每個隊列的長度。使用 OpenTelemetry 將此數據作為自定義指標發出。一個示例項目可用於通過 Azure 函數自動化此過程，實現可靠且可擴展的監控。
如果您使用 Azure 存儲隊列，並且需要（或者只是想要）單獨監控每個隊列的長度，那麼我有一些壞消息。 ?
Azure 只通過其內置指標功能提供整個存儲帳戶的總消息數指標。不幸的是，如果您需要追踪單個隊列的消息數，這使得這些內置指標不太有用。
上圖顯示了內置指標的示例。在任何給定時間都有兩個隊列，但我們無法識別各個隊列中有多少消息。篩選功能被禁用，並且沒有針對隊列消息計數的特定指標，如下所示。
為什麼監控單個隊列長度很重要？
監控單個隊列長度可能很重要，原因如下。例如，如果您管理多個隊列，您可能希望：
無論您是在調試還是縮放，了解每個隊列的消息計數都有助於保持系統的健康。
好消息?
雖然 Azure 沒有提供開箱即用的此功能，但有一個簡單的解決方法，本博文將引導您完成此過程。
如前所述，Azure 沒有將單個存儲隊列長度作為內置指標提供。鑑於人們在過去五年中一直在要求此功能，對於 Microsoft 來說，將其作為標準指標實現可能並非一項簡單的任務。因此，找到一種解決方法可能是您的最佳選擇。
自然地，這導致了這樣一個問題：如果標準指標沒有提供此功能，還有其他方法可以獲取它嗎？ ?
仔細查看 Azure 存儲帳戶 SDK 會發現隊列屬性 approximate_message_count，它可以讓您訪問所需的信息——只是通過不同的方法。
知道了這一點，如果您能夠使用此數據將隊列長度作為指標進行追踪，豈不是很好？
這是一個想法：如果您這樣做呢？ ?
您可以查詢每個佇列的長度，建立指標量規並定期更新值。
讓我們逐步分解它。
使用 Python SDK，您可以輕鬆檢索佇列的單一長度。請參考下面的程式碼片段：
<code class="language-python">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)</code>由於 SDK 建立在 REST API 之上，因此其他 SDK 中也提供了類似的功能。以下是其他語言中 REST API 和 SDK 的參考：
接下來，您建立一個量規指標來追蹤佇列長度。
量規 是一種測量特定時間點值的指標類型，使其非常適合追蹤不斷變化的佇列長度。
為此，我們將使用 OpenTelemetry，這是一個開源可觀察性框架，因其在收集指標、追蹤和日誌方面的多功能性而越來越受歡迎。 以下是使用 OpenTelemetry 發出佇列長度作為量規的範例：
<code class="language-python">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)</code>OpenTelemetry 的另一個優點是它與各種可觀察性工具（如 Prometheus、Azure Application Insights、Grafana 等）的整合非常好。
雖然上述方法非常適合實驗，但您可能需要一個更強大的解決方案來適應生產環境。這就是彈性和可擴展性發揮作用的地方。
在生產環境中，持續監控佇列不僅僅是提取指標。您需要確保系統可靠、能夠根據需求進行擴展，並能夠處理潛在的故障（例如網路問題或大量資料）。例如，您不希望失敗的查詢會停止您的監控過程。
如果您有興趣了解如何使其適應生產環境，我已經建立了一個範例專案：azure-storage-queue-monitor。此專案將我們討論的所有內容包裝到在計時器觸發器上執行的 Azure 函數中。它處理彈性、並發性和可擴展性，確保您可以可靠地監控佇列。
現在您已經掌握了追蹤單一佇列長度並將其作為自訂指標發出的步驟，您可以為自己的環境設定此功能。如果您嘗試一下，請隨時分享您的經驗或改進——我很樂意聽到您的想法，並在您遇到任何問題時提供幫助！
祝您隊列監控愉快！ ?
以上是如何監視各個 Azure 儲存佇列的長度的詳細內容。更多資訊請關注PHP中文網其他相關文章！
