Logging Providers and Logging Options

You're probably already starting to get a good picture of the architecture that underlies logging in Integration Services. As you can see from the preceding text, log providers are associated with the package and logging options are somehow associated with containers. This section quickly describes how log providers and logging options work together to help you better understand logging overall.

As described earlier, log providers are components that take log entries as input and send them to a destination. With any pluggable component architecture, there are contracts or agreements between the component and the architecture it plugs into. In the case of Integration Services logging, the agreement is that the runtime will manage the exclusion or inclusion of log entries, channeling the log entries to the right log provider, configuring and storing log entry and column filtering. The log providers agree to actually put the log entries somewhere. Log providers know nothing about filtering and the runtime knows nothing about how to write out a log event to a file or anywhere else for that matter. Log providers and the runtime are partners in the agreement, each relying on the other to do its part.

Log Providers

The runtime supports having multiple log providers in one package. In fact, it's possible to have more than one instance of the same log provider associated with the same package. Because components can also be associated with more than one log provider, it's also possible to support logging to multiple destinations simultaneously, even from the same component. The package has a collection of log providers. This is why in the Configure Logging dialog box, the option to create and delete log providers is only visible when you select the package node.

Logging Options

The runtime portion of the agreement is to filter, channel, and store the logging settings and does it through what are called logging options. A logging option is an object. On each container, including the Package, Sequence, Loops, and Taskhost, there is a collection of logging options objects that contain the settings you create in the Configure Logging dialog box. This is why in the Configure Logging dialog box, there is an option to create filters on all containers.

Note

The logging options have the ability to filter log entries exclusively or inclusively. However, the Configure Logging dialog box hides that detail from you.

There is also a property on containers called LoggingMode. This property has three states: Enabled, Disabled, and UseParentSetting.

• Enabled Enable all logging from the container. This is the default.

• Disabled Disable all logging from the container, but retain logging options.

• UseParentSetting Use the LoggingMode and logging options from the parent. This setting is helpful when you have established a filter at the package or other parent container level that you want to use throughout the package. You can create your filters once and then set the rest of the container LoggingMode properties to UseParentSetting. Then, you only need configure logging in one place, even if you need to modify it later.

Caution

The UseParentSetting is helpful as noted, but can cause unexpected behavior. Depending on the method you use to filter log events, it is possible that certain log events that a child task exposes will be unexpectedly filtered because the log event isn't supported by the parent. For example, the Script Task supports the ScriptTaskLogEntry log event. But, the package doesn't. The ScriptTaskLogEntry event will be filtered out if the Script Task's LoggingMode is set to UseParentSetting and the parent is using Inclusive filtering. The Configure Logging dialog box uses inclusive filtering, meaning only those log events that have been selected will be allowed to be logged. Because the child log event is not visible at the parent, it cannot be included and will, therefore, be unavailable.