对于任何事物而言，监督都是提高自身的有效手段，BI也是如此。从我个人的经验而言，BI的监督可以分为两类(欢迎拍砖讨论)：运行时监督(Runtime Monitoring)与数据仓库健康状况的监督(DW Healthy Monitoring)：
1. 运行时监督
所谓运行时监督是指监督数据从数据源到流到数据仓库的过程，通俗来讲就是监督ETL的执行过程。我相信绝大多数的BI系统都具有该功能，区别只在于实现监控的方式以及监控信息的详细程度
2. 数据仓库健康状况监督
所谓数据仓库的健康状况监督，其实就是监控数据仓库的系统的各项指标：表记录数、存储的大小、碎片大小、索引使用率、面向数据仓库的查询的执行效率等信息，对于这一项监控，就跟人接触到的BI项目而言，很少有系统实现该功能
运行时监督
本文章只讨论运行时监控，后面会再另起一篇讨论关于数据仓库健康监控的文章。由于本人使用的ETL工具是基于微软SSIS的，所以所讨论的监控实现方式也只限于微软的SSIS。
广义上说，一般有三种方式可以实现ETL运行时的监控：
① 基于SSIS事件处理器的实现方式
② 基于SSIS日志提供程序的实现方式
③ 基于SSISDB的实现方式(只有在SQL Server 2012之后才有)
基于事件处理器
正如下图所展示的，一个SSIS包有4个选项卡：控制流、数据流、事件处理器以及包浏览器：
我们知道控制流上放置的所有task以及包本身都是所谓的executable，而事件处理器是特定于某个executable的。并且executable之间是可以组成层级关系的，比如一个Execute SQL Task被包含在For Loop容器中，那么它们之间就会组成如下的层级关系：
对于具有层级关系的executable，事件处理器具有一个非常重要的特性：事件发生的时候会从自身一直往上层抛并触发响应的处理器。基于这个特性我们可以只在Package上加上事件处理器，则所有包内的task的事件都可以被捕获。
下面是几个经常被用到的事件：
|
事件 |
描述 |
|
OnError |
在响应的executable执行出现错误的时候触发 |
|
OnPreExecute |
当一个executable开始执行之前触发 |
|
OnPostExecute |
在一个executable执行完之后接着触发 |
|
OnPreValidate |
在PreExecute之后触发 |
|
OnPostValidate |
在PreValidate之后、真正执行之前触发 |
|
OnInformation |
该事件暴露的信息跟我们在BIDS中执行ETL时候在执行选项中看到的信息一样 |
当设计自定义的日志时，我们可以简单的利用OnError在任务出错是记录信息，利用OnPreExecute在任务刚开始是获取信息(如开始时间等)，利用OnPostExecute获取任务要结束时的信息(如结束时间等)，然后利用RowCount任务获取所处理的行数信息就可以构造如下一个简单的日志表：
基于日志提供程序
相对而言，使用SSIS自带的日志提供程序是一种比较简单的实现运行时监控的方式。在SSIS包上右击，在弹出的菜单中选择Logging就会出现以下的界面：
1. 在Containers界面允许我们选择想要监控其运行的executabe
2. 在Providers and Logs界面允许我们选择内置的日志提供程序，一般我们选择”SSIS log Provider for SQL Server”
如果我们选择了该提供程序，那么SSIS会自动将日志写入一个名为sysssislog的表中，而且该表必须已经存在，SSIS不会自动创建该表。幸运的是在msdb系统数据库的系统表中有该表，我们可以按照该表的结构在另外的数据库上创建该表，或者直接使用该数据库。
3. 在Details界面允许我们选择要监控的事件
然后下面就是一个实际的效果图：
