Submit a ticketCall us

whitepaperYour VM Perplexities Called, and They Need You to Read This.

Virtualization can give you enormous flexibility with future workloads and can be a key enabler for other areas, like cloud computing and disaster recovery. So, how can you get a handle on the performance challenges in your virtual environment and manage deployments without erasing the potential upside? Learn the four key areas you need to be focusing on to help deliver a healthy and well-performing data center.

Get your free white paper.

Home > Success Center > ipMonitor > ipMonitor - Knowledgebase Articles > Use Content Generator in IP Monitor

Use Content Generator in IP Monitor

Updated  August 11, 2016


You can populate the alerts with data from events or other monitored resources.

A content generator is used to format data into messages for information alerts. The event log and the SNMP Trap and File Watching monitors support the use of regular expressions to capture variable data.

This data includes: 

  • An event log description
  • Variable-binding data from an SNMP trap
  • A line from a log file

Captured data is passed to a content generator and parsed into a message. Additional information relating to the monitor (such as the Event timestamp or the source IP address of a received SNMP Trap) can also be included in the message.

After the message is structured correctly, it can be passed to any number of alerts that are configured to act on the specific monitor that triggered the alert.

The following alert types fully support Information Alert messages:

  • Simple Email
  • Customized Email
  • Net Broadcast
  • Event Log
  • Text Log
  • SNMP Trap

The SNMP Trap, Event log and File Watching monitors support supplemental tokens that can be referenced in a content generator to provide additional information in the alert message. These tokens can be divided into two categories:

  • Numeric tokens 
  • Numeric tokens

Numeric Tokens

Numeric tokens allow you to retrieve specific text matches (or captures) located by a regular expression search.

The syntax for numeric tokens is:

%capture[#]% (ie. %capture[1]% or %capture[2]%.

For example, consider a file watched by the File Watching Monitor, which contains the following entry:

1/30/2006 7:45:08 AM ERROR: The application failed to start. REASON: Required resource myapp.dll could not be located.

Within the File Watching Monitor, the following Regular Expression has been entered:

ERROR\: (.*?) REASON\: (.*?)

In this example:

  • The %capture[1]% token would resolve to: "The application failed to start."
  • The %capture[2]% token would resolve to: "Required resource myapp.dll could not be located.".

Assuming an Information alert was correctly configured, this information would be included in the body of the alert.

Property Tokens

Property tokens allow you to access additional parameters describing an event log entry, a file entry, or an SNMP Trap. The syntax for Property Tokens is %capture[property_name]%.

For example:

%capture[timewritten]%     (Event Log Monitor specific)

%capture[bindings]%        (SNMP Trap Monitor specific)

%capture[offset]%        (File Watching Monitor specific)

The following tables contain the Property Tokens available to the Event Log, File Watching and SNMP Trap Monitors:


All IP Monitor versions


To add or edit a content generator, click the Content Generators option located in the Alerts section.

A content generator contains three elements:

  1. Name: Identifies the content generator.
  2. Value: Defines the layout of the "captured" data. This will be the format of the alert message.
  3. Coalesce Separator: Specifies the string used to terminate each captured data "element". By default, this is: 
    \r\n (CRLF)


When capturing data from an event log description, the captured string may already terminate with a CRLF. If an Information Alert appears to contain an extra CRLF, this may be the source of the formatting problem.


%capture[#]%Variable Type
The variable type used to parse information captured by Regular Expressions. For example:

New Account Name: %capture[1]%

Variables are enumerated in the same order they are defined in the RegEx. In the example shown above, "New Account Name" is the first variable defined in the RegEx and "Caller Domain" is the last.

When more than one RegEx Search Scenario is configured for a Monitor, variables are enumerated starting in the first Regular Expression and counting through the last Regular Expression. For example:

First regular expression: %capture[1]%, %capture[2]%, %capture[3]%
Second regular expression: %capture[4]%, %capture[5]%, and so on

%capture[token_name]% Variable Type
The variable type used to parse supplemental Content Generator Tokens. For example:

Event Timestamp: %capture[timewritten]%




Last modified