../../_images/sitetitle3.png

Tag Groups

Introduction to Tag Groups

Tag groups were created to simplify managing tags and to allow for hierarchical tags. A list of tags are grouped under a single tag. Take a look at the configuration below as an example:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
        <section name="nulog" type="NuLog.Configuration.ConfigurationSectionHandler, NuLog" />
    </configSections>
    <nulog>
        <!-- ... -->
        <tagGroups>
            <group
                baseTag="base_tag"
                aliases="one_tag,two_tag,red_tag,blue_tag" />
        </tagGroups>
        <!-- ... -->
    </nulog>
</configuration>

What this means:

  • baseTag - The base tag that the alias tags equate to. If this tag is listed in a rule’s include or exclude attributes, all of the tags listed as aliases would then qualify/satisfy the include or exclude requirement.
  • aliases - The list of tags, comma delimited, which are considered the same as the named base tag.

An Impractical Example: Fruit

Perhaps you wanted to simply be able to say fruit in a rule to say that you wanted to send all log events containing fruit to be dispatched to a list of targets. You could create a tag group for the base tag fruit, and list under it apple, pear, tomato, and on.

Now, I know you aren’t likely to be using fruit as tags, but this could be used to group all user actions together, for example: useractions could have the aliases login, signout and resetpassword. This becomes useful once you have more advanced tag routing, where you have multiple rules that would leverage the useractions base tag.

A Practical Example: Traditional Log Levels

Tag groups can be used to emulate the traditional behavior of log levels. This is done by equating all of the lower levels, to a given level:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
        <section name="nulog" type="NuLog.Configuration.ConfigurationSectionHandler, NuLog" />
    </configSections>
    <nulog>
        <!-- ... -->
        <tagGroups>
            <group baseTag="trace" aliases="fatal,error,warn,info,debug" />
            <group baseTag="debug" aliases="fatal,error,warn,info" />
            <group baseTag="info"  aliases="fatal,error,warn" />
            <group baseTag="warn"  aliases="fatal,error" />
            <group baseTag="error" aliases="fatal" />
        </tagGroups>
        <!-- ... -->
    </nulog>
</configuration>

With these tag groups in place, we can then set a “level” to our rules:

1
2
3
         <rule
             include="warn"
             targets="email" />

If we look at our warn tag group, it tells us that any log events with any of warn, error or fatal, will cause the rule to match, and be sent to the target named email.