【原】StreamInsight 淺入淺出(六)—— Debugger


對於 StreamInsight 系統,由於對事件的處理查詢都是異步進行的,輸入輸出很難進行時序上的對應監測,所以普通的基於代碼的 Debug 和 Watch 顯得不那么有意義。於是微軟隨 StreamInsight 系統提供了一個好用的圖形化調試工具 StreamInsight Event Flow Debugger。

image

這一工具的主要特點在於:

  1. 圖形化界面,足夠直觀。有點類似 SQL Server 的查詢計划界面,將一個復雜的查詢拆分成多個基本查詢,並以列表形式展現每個查詢中事件的狀態與取值。
  2. 支持跟蹤、回溯,可以查看一個事件的初始狀態以及演變過程。
  3. 支持即時調試,也支持日志調試。日志調試能更好的研究一個完整的查詢的過程。

另,關於事件流調試和常見的控制流調試的區別,參見 MSDN : http://technet.microsoft.com/zh-cn/library/ff518532.aspx

啟用調試

調試分為實時跟蹤和日志跟蹤兩種模式。其中實時跟蹤需要運行 StreamInsight 的客戶端通過 Server.Connect 方式連接到 StreamInsight 服務器(需要運行賬戶屬於 StreamInsight 用戶組的成員),同時將 Debugger 也連接到服務器上。具體連接方式參見 MSDN http://technet.microsoft.com/zh-cn/library/ff518532.aspx。使用這種方式的好處是可以實時跟蹤最新的數據,對於長時間連續性的應用來說比較方便,並且能同時監控服務器上的資源情況。而缺點是一方面需要調試器和程序都連到 StreamInsight 服務器上,另一方面由於每次調試的都是“開始記錄”到“停止”這一段時間的數據,不一定能跟蹤到事件的完整流程。

另一種方式就是日志式的跟蹤:

  1. trace.cmd start <文件名>.etl 創建一個跟蹤文件。
  2. 執行 StreamInsight 程序進行查詢,直到運行足夠長時間。
  3. trace.cmd stop <文件名>.etl 結束跟蹤。

Ff518532.f10b2317-ebad-418d-96d7-61fc2045a939(zh-cn,SQL.105)

將生成的跟蹤文件加載到調試器中,同樣展開了和實時跟蹤類似的圖像界面。這里會看到對象資源管理器中的對象並不包含服務器相關的對象。相對於實時跟蹤,使用日志式跟蹤的好處是不需要連接到服務器,而且比較方便跟蹤事件的完整流程,同時因為可以加載多個日志文件,也方便進行對比。

跟蹤事件

這里還是以官方提供的 StreamInsight 的 樣例 TrafficJoinQuery 為例。

image

這是未展開的流程圖,可以清晰的看到整個查詢的步驟。其中由於有兩個 Input (sensorInput,locationInput),所以有兩個起點,並在 Join 處連接在一起,最終到達輸出端 OutputAdapter。

展開其中的一項,會看到所有的事件內容,包括事件的類型(Insert,CTI),以及事件的起止時間還有事件負載的各個字段,除此之外,還有事件的排隊時間、延遲等信息。注意這里的排隊事件是程序執行時的即時時間,和事件的起止時間沒有直接的關系:

image

選中其中的任意一條時間,可以進行兩個方向的跟蹤:尋根(Root Cause Analysis),演化(Event Propagation Analysis)。前者是對中間階段的事件,找出其之前的事件源,而后者則是對較前階段的事件,跟蹤其之后的所有演變。此外,重播按鈕(Start Replay)可以像過程調試中的單步模式一樣從頭開始一步一步的演變事件流的變化,也可以直接前進后退到下一個斷點。

imageimage

另外,在每個模塊中都有一個過濾區域,可以通過一些表達式對展現的事件進行過濾。比如 EndTime > "2009-6-25 08:10" && EventKind == "Cti" 表示過濾所有結束時間在 2009-6-25 8:10 之后的 CTI 事件。這里注意要對非 Int 類型的值添加雙引號

利用調試器調試事件流

利用調試器調試事件流,其實和控制流調試有些類似,都是先跟蹤定位到與預期不符的數據處,然后根據上下文排查原因。但事件流的調試比控制流調試麻煩的一點是,由於調試工具和編譯的程序是分離的,所以即使找到了異常的事件數據,也需要花費一些功夫,進行多遍的推演才能找到導致這些異常的原因。這其中,經驗是最重要的。

而其實筆者本人也暫時沒有總結出比較靠譜的經驗,只能簡單提供以下的一些小Tips,希望能讓大家少走些彎路。

  1. CTI 很重要,所有在最后一個 CTI 的 StartTime 之后結束的事件都不會進入到最后的計算結果中,也就是被丟棄了。
  2. 聚合分組會修改事件的開始時間,將一組內以及一個時間窗口內的事件的起止時間進行對齊。 而且每組的每個窗口后會跟一個 CTI 。這里的 CTI 其實和最早的插入事件時的 CTI 已經沒有關聯了。
  3. 以后如果再有體會會加到這里~

 

這樣,關於 StreamInsight 的一些入門知識就介紹到這里。可以看到很多是概念上的介紹和操作上的指導,真正關系到事件流的、算法的設計的部分很少很少。還是那句話,需要多嘗試,多實際運用,才能找到感覺。


注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2020 ITdaan.com