代码改变世界

【原】StreamInsight 浅入浅出（六）—— Debugger

2010-12-20 11:11  拖鞋不脱  阅读(1842)  评论(1)  编辑  收藏  举报

对于 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 的一些入门知识就介绍到这里。可以看到很多是概念上的介绍和操作上的指导，真正关系到事件流的、算法的设计的部分很少很少。还是那句话，需要多尝试，多实际运用，才能找到感觉。