|
|
對于 StreamInsight 系統(tǒng)，由于對事件的處理查詢都是異步進行的，輸入輸出很難進行時序上的對應(yīng)監(jiān)測，所以普通的基于代碼的 Debug 和 Watch 顯得不那么有意義。于是微軟隨 StreamInsight 系統(tǒng)提供了一個好用的圖形化調(diào)試工具 StreamInsight Event Flow Debugger。
這一工具的主要特點在于：
- 圖形化界面，足夠直觀。有點類似 SQL Server 的查詢計劃界面，將一個復(fù)雜的查詢拆分成多個基本查詢，并以列表形式展現(xiàn)每個查詢中事件的狀態(tài)與取值。
- 支持跟蹤、回溯，可以查看一個事件的初始狀態(tài)以及演變過程。
- 支持即時調(diào)試，也支持日志調(diào)試。日志調(diào)試能更好的研究一個完整的查詢的過程。
另，關(guān)于事件流調(diào)試和常見的控制流調(diào)試的區(qū)別，參見 MSDN : http://techNET.microsoft.com/zh-cn/library/ff518532.ASPx
啟用調(diào)試
調(diào)試分為實時跟蹤和日志跟蹤兩種模式。其中實時跟蹤需要運行 StreamInsight 的客戶端通過 Server.Connect 方式連接到 StreamInsight 服務(wù)器（需要運行賬戶屬于 StreamInsight 用戶組的成員），同時將 Debugger 也連接到服務(wù)器上。具體連接方式參見 MSDN http://techNET.microsoft.com/zh-cn/library/ff518532.ASPx。使用這種方式的好處是可以實時跟蹤最新的數(shù)據(jù)，對于長時間連續(xù)性的應(yīng)用來說比較方便，并且能同時監(jiān)控服務(wù)器上的資源情況。而缺點是一方面需要調(diào)試器和程序都連到 StreamInsight 服務(wù)器上，另一方面由于每次調(diào)試的都是“開始記錄”到“停止”這一段時間的數(shù)據(jù)，不一定能跟蹤到事件的完整流程。
另一種方式就是日志式的跟蹤：
- trace.cmd start <文件名>.etl 創(chuàng)建一個跟蹤文件。
- 執(zhí)行 StreamInsight 程序進行查詢，直到運行足夠長時間。
- trace.cmd stop <文件名>.etl 結(jié)束跟蹤。
將生成的跟蹤文件加載到調(diào)試器中，同樣展開了和實時跟蹤類似的圖像界面。這里會看到對象資源管理器中的對象并不包含服務(wù)器相關(guān)的對象。相對于實時跟蹤，使用日志式跟蹤的好處是不需要連接到服務(wù)器，而且比較方便跟蹤事件的完整流程，同時因為可以加載多個日志文件，也方便進行對比。
跟蹤事件
這里還是以官方提供的 StreamInsight 的 樣例 TrafficJoinQuery 為例。
這是未展開的流程圖，可以清晰的看到整個查詢的步驟。其中由于有兩個 Input （sensorInput，locationInput），所以有兩個起點，并在 Join 處連接在一起，最終到達輸出端 OutputAdapter。
展開其中的一項，會看到所有的事件內(nèi)容，包括事件的類型（Insert，CTI），以及事件的起止時間還有事件負載的各個字段，除此之外，還有事件的排隊時間、延遲等信息。注意這里的排隊事件是程序執(zhí)行時的即時時間，和事件的起止時間沒有直接的關(guān)系：
選中其中的任意一條時間，可以進行兩個方向的跟蹤：尋根（Root Cause Analysis），演化（Event Propagation Analysis）。前者是對中間階段的事件，找出其之前的事件源，而后者則是對較前階段的事件，跟蹤其之后的所有演變。此外，重播按鈕（Start Replay）可以像過程調(diào)試中的單步模式一樣從頭開始一步一步的演變事件流的變化，也可以直接前進后退到下一個斷點。
另外，在每個模塊中都有一個過濾區(qū)域，可以通過一些表達式對展現(xiàn)的事件進行過濾。比如 EndTime > "2009-6-25 08:10" && EventKind == "Cti" 表示過濾所有結(jié)束時間在 2009-6-25 8:10 之后的 CTI 事件。這里注意要對非 Int 類型的值添加雙引號。
利用調(diào)試器調(diào)試事件流
利用調(diào)試器調(diào)試事件流，其實和控制流調(diào)試有些類似，都是先跟蹤定位到與預(yù)期不符的數(shù)據(jù)處，然后根據(jù)上下文排查原因。但事件流的調(diào)試比控制流調(diào)試麻煩的一點是，由于調(diào)試工具和編譯的程序是分離的，所以即使找到了異常的事件數(shù)據(jù)，也需要花費一些功夫，進行多遍的推演才能找到導(dǎo)致這些異常的原因。這其中，經(jīng)驗是最重要的。
而其實筆者本人也暫時沒有總結(jié)出比較靠譜的經(jīng)驗，只能簡單提供以下的一些小Tips，希望能讓大家少走些彎路。
- CTI 很重要，所有在最后一個 CTI 的 StartTime 之后結(jié)束的事件都不會進入到最后的計算結(jié)果中，也就是被丟棄了。
- 聚合分組會修改事件的開始時間，將一組內(nèi)以及一個時間窗口內(nèi)的事件的起止時間進行對齊。 而且每組的每個窗口后會跟一個 CTI 。這里的 CTI 其實和最早的插入事件時的 CTI 已經(jīng)沒有關(guān)聯(lián)了。
- 以后如果再有體會會加到這里~
這樣，關(guān)于 StreamInsight 的一些入門知識就介紹到這里。可以看到很多是概念上的介紹和操作上的指導(dǎo)，真正關(guān)系到事件流的、算法的設(shè)計的部分很少很少。還是那句話，需要多嘗試，多實際運用，才能找到感覺。
NET技術(shù)：StreamInsight 淺入淺出（六）—— Debugger，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
