我們需要監控隊列接收的健康,每5分鐘的最後reciever信息。我們是否有任何API來獲取有關在服務總線隊列上執行的最後接收/查看操作的信息?有一個'AccessAt'屬性,但它表示上次操作完成的時間(發佈/接收/查看),這對我沒有用處。任何想法(除了在每個接收器上設置監控之外)?如何找到Azure的服務總線隊列管理API
回答
這更比一個統計服務審計功能。當前不可用。 您的端點可能會將該信息作爲消息發送。請記住,然後它不是完全相同的服務器時間(1)發送所有這些消息並且個別消息在發送時可能會失敗(2)。
我打算使用審計消息發送到每個隊列每5分鐘作爲一種機制,看看是否至少有一個接收器是積極的檢索消息。但這並不是傻瓜證明,因爲它在接收端需要一些CPU時間(我試圖避免),同時這個消息也會失敗,從而打破了消息鏈。如果所有接收機都忙於超過5分鐘(這與AccessAt方法的情況相同),也可能不完全是5分鐘的時間間隔。我不知道你的意思是否一樣? – Abhilash
「我打算使用每5分鐘發送一次到每個隊列的審計消息作爲一種機制來查看是否至少有一個接收者正在主動檢索消息」 - 而不是這樣做,或許會更好地監視隊列深度。看看http://www.servicebus360.com/ –
是的,後來我決定結合'AccessedAt','incoming'和'outgoing'計數(度量)來確定是否有人主動訪問隊列。這種方法的一個缺點是,如果客戶花費更長的時間來處理當前消息,那麼它會報告錯誤的價值。我想知道是否可以使用'requests.total'來查看是否有任何接收客戶端的活動。任何想法? – Abhilash
- 1. 管理多個Azure的服務總線隊列同時
- 2. Azure的服務總線死信隊列
- 3. 如何積極處理Azure服務總線隊列消息
- 4. 未找到Azure服務總線隊列端點錯誤
- 5. Azure服務總線隊列計數
- 6. Azure服務總線隊列ScheduledEnqueueTimeUtc延遲
- 7. Azure服務總線DeadLetter隊列
- 8. Azure服務總線隊列OnMessageOptions
- 9. 使用Azure功能處理Azure服務總線隊列消息
- 10. 在Azure服務總線隊列中使用混合API
- 11. 如何將Azure服務總線隊列中的消息觸發到Azure Data Lake?
- 12. Azure服務總線託管REST服務
- 13. 順序處理算法/模式 - Azure服務總線隊列
- 14. Azure服務總線隊列消息處理
- 15. 未收到來自Azure服務總線隊列的郵件
- 16. 如何調用azure服務總線隊列queueService.peekMessages()?
- 17. Azure WebJob服務總線重新排隊隊列出現錯誤
- 18. 將消息從SQL添加到Azure服務總線隊列
- 19. Azure服務總線到WCF
- 20. 服務總線隊列主機服務的異常處理
- 21. 在azure服務總線隊列中處理消息處理的選項
- 22. 如何使用服務總線REST API在C#中發送/接收xml數據到服務總線隊列?
- 23. Azure的服務總線 - 快速隊列和主題的解釋
- 24. Azure服務總線隊列上的重複檢測窗口
- 25. 從Azure服務總線接收消息時的NPE隊列
- 26. 什麼是Azure服務總線中的隊列生存期?
- 27. 單個Azure服務總線隊列的多個客戶端
- 28. 的Windows Azure服務總線隊列:節流和黃玉
- 29. Azure的服務總線 - 隊列連接錯誤
- 30. 具有Azure服務總線創建隊列的MassTransit 3
看看這個答案:http://stackoverflow.com/a/38501539/4167200 – Thomas