Table of ContentsPreviousNextIndex
 
PDF

Fidelia Technology Logo

    Manage NetVigil

The Manage menu in the NetVigil user interface allows creating and configuring of containers, devices, tests, actions, etc. using the web interface.

14.1 Managing Devices

The Manage Devices page displays all the department's devices and links to perform various administrative functions on the devices. Each row contains the device name and address, type of device, whether monitoring is currently active or suspended, a link for suspending or resuming monitoring, and the physical device location. Additionally, there are links for updating or deleting the device, and for managing the tests for the device.

Manage Devices Page
note Test discovery may take up to 1 minute, depending on the number of test types you chose. Please follow the on-screen instructions as the device is queried.
Create Device Page

The suspend/resume feature allows you to temporarily turn off all the tests for a device and turn them on again. This feature is useful if you are performing maintenance task on a device and do not want to receive alerts while the device is offline. Once a device is suspended, the polling and data collection for all the tests on the device is suspended and thus any associated actions to the tests will not generate notifications. The suspend/resume feature is available at both the device and the individual test level. Furthermore, when a device is suspended (e.g. for maintenance), this time is not included in the total downtime reports since it is considered a planned outage.

WARNING: Deleting a device will remove all information about that device from the database, including all historical records. Deletions are not reversible. Suspending a device may be preferable because there is no loss of data.

  1. Click MANAGE | devices.
  2. On the Manage Devices page, find the device that you want to delete, and then click Update.
  3. On the Update Device page, select Delete This Device (and associated tests).
  4. Click Submit.
  5. If you are sure that you want to delete the device, click Delete on the Delete Device confirmation page.

Auto-Update for Device Capacity Change

NetVigil provides a mechanism for refreshing maximum values or SNMP object identifiers (SNMP OID) when an SNMP test has changed. For example, when memory or disk capacity has changed, tests that return percentage-based values would be incorrect unless the max value (for determining 100%) is refreshed. Additionally, in some cases even replacing a device with similar hardware can cause the SNMP OIDs to change, thus creating a mismatch between the current SNMP OIDs and the ones which NetVigil discovered during initial provisioning.

If one of the previous situations occurs, the user need only repeat the test provisioning process in the web application for a changed device. NetVigil will discover whether any material changes on the device have occurred and highlight those changes on the Configure Tests page, giving the user the option to also change thresholds and/or actions that apply to the test.

14.2 Managing Standard Tests

14.2.1 Before You Provision Tests

Your User Group privileges determine whether or not you can create your own actions. Assigning actions to tests can be done in several ways, but all require that an action has already been created either by you or by your User Group administrator. Options include:

14.2.2 Test Autodiscovery

For some monitors (test types), NetVigil can automatically discover which tests are supported by a given device. For example, if you add a new router to your network, NetVigil can discover which SNMP tests the router supports. You can then select which of the supported tests you want to run. Alternately, if you know exactly which tests you want, you can skip the autodiscovery process and provision those tests manually.

14.2.3 Grouping Tests by Subtype

One test configuration option, Group all SNMP tests with same type and sub-type together, only appears when you choose to auto-discover SNMP tests. The option gives the following advantages:

If the grouping option is not selected, every discovered SNMP test is listed individually, as shown in Figure 14.3. You can set a separate test interval, warning threshold, critical threshold, and action profile for each test.

Discovered SNMP tests, listed individually

If the grouping option is selected, discovered tests with the same subtype are grouped together. Figure 14.4 shows the results of autodiscovery of SNMP tests for the same device as the one shown in Figure 14.3. However, in this image, discovered tests are grouped by subtype. For example, the eth0 Util In and eth0 Util Out tests are grouped under the snmp/bandwidth (Interface Utilization) test subtype.

Discovered SNMP tests, grouped by subtype

You can select/clear the checkbox near a subtype name (item A in Figure 14.4) to provision/not provision all tests within that subtype. To provision some, but not all, tests within a subtype, make sure that the subtype checkbox is selected. Then, from the list of tests within the subtype (item B in Figure 14.4), select only those that you want to provision.

The configuration parameters that you set (Interval, Thresholds, Action Profile) for a subtype are applied to all selected tests within the subtype. You can change the configuration for an individual test after it is provisioned.

This grouping feature is useful when you have many tests of the same subtype for a single device. For example, assume that you have a large switch with 100 ports, each of which supports Util In and Util Out interface utilization tests. If the grouping option is not selected, the list of discovered tests has 200 entries for these tests. If the grouping option is selected, the list of discovered tests is more compact, and instead of configuring and provisioning 200 tests, you can configure and provision a single subtype, snmp/bandwidth (Interface Utilization). The Interval, Thresholds, and Action Profile selected for the subtype are applied to all tests in the group. (You can change the configuration for individual tests after the tests are provisioned.)

NOTE: Internal settings in the TestType.xml file may sometimes override the Group all SNMP tests... option because of which some test subtypes may always be grouped, even if you do not select the grouping option.

If this option is cleared and NetVigil discovers a provisioned test of this subtype for this device (e.g., a Packet Loss test is already configured for this device), the test subtype does not appear in the list of tests that you can choose to provision.

If this option is selected and NetVigil discovers a provisioned test of this subtype for this device, the test subtype is listed and you can provision another test of the same subtype for the device.

If this option is not selected, but some of the configured parameters for the test do not match the re-discovered parameters (such as max, oid, etc.), then the test is displayed so that you have the option to update the values.

This is only available if you have chosen to autodiscover SNMP tests. See "Grouping Tests by Subtype" on page 183 for a detailed explanation of this option.

  1. Click Continue.
  2. If you have chosen to autodiscover tests, please wait for the discovery process to complete. This may take a short time.
  3. In the Create New Tests: Step 3 window, select those tests that you want to provision. (If you've chosen to group SNMP tests by subtype, select subtypes and, optionally, individual tests within subtypes.) For each test, enter the following:
    Field
    Used For
    Test Name
    A unique identifier for this test.
    Interval
    The frequency, in minutes, at which the test will run.
    Thresholds/Units
    If the test result passes the number of units specified by the Warning or Critical threshold, the test goes into Warning or Critical state, respectively.
    Action Profile
    The action (or series of actions) to be taken when the test enters specific states.

If you've chosen to group SNMP tests by subtype, these parameters are applied at the subtype level -- that is, to all selected tests within the subtype.

  1. Click Provision Tests. The newly provisioned test(s) appear in the Manage Tests window.
  2. To update an existing test:
  3. Go to the Manage Tests page for the device being tested (see Figure 14.5).
  4. Click on the Update link for the test you want to modify and you will be taken to the Update Test page.
  5. Make the desired changes.
  6. Click on the Update button to complete the changes.
Manage Tests Page

Note: When you resume a suspended test, the test is rescheduled to run on the monitor. If you visit the Test Summary page for the device that the test is on, you may see an unknown (question mark) icon in the status column. This indicates that the test has been rescheduled, but that its status is not yet known because it hasn't yet run. After the test runs, the unknown icon is replaced with the appropriate status icon.

  1. Click MANAGE | devices.
  2. On the Manage Devices page, find the device whose test(s) you want to suspend or resume, and then click Tests.
  3. On the Manage Tests page, select the test(s) you want to suspend or resume in the Select column.
  4. In the Apply the following updates to the tests selected above: area, select Suspend or Resume, as appropriate, from the Modify Test: list.
  5. Click Submit to suspend or resume the test(s).
  6. To delete a test:
  7. Click MANAGE | devices.
  8. On the Manage Devices page, find the device whose test(s) you want to delete, and then click Tests.
  9. On the Manage Tests page, select the test(s) you want to delete in the Select column.
  10. In the Apply the following updates to the tests selected above: area, select Delete from the Modify Test: list.
  11. Click Submit to delete the test(s).

14.2.4 Configuring Test Schedules

You can configure a time schedule (hour and day of week) for runing a test, and assign this schedule to a test. By default, the test schedule is 24x7 (all the time).

14.3 Managing Advanced Tests

14.3.1 Monitoring Log Files for Patterns

You can configure NetVigil to watch text log files for specific patterns and raise alarms or take other action when a match is found. (Pattern matching is Perl 5 compliant.) This process has three steps, which are detailed in the paragraphs that follow:

  1. Configure the DGE so that it recognizes the log file(s) to be scanned. This step must be performed by the NetVigil administrator as described in Section 3.6, "Monitoring Log Files" on page 3-42.
  2. Create a list of regular expressions (patterns) to watch for
  3. Create a Regular Expression test to take appropriate action when a match is found for a pattern in the list
  4. Configure the DGE so that it recognizes the log file(s) to be scanned:

This requires editing NETVIGIL_HOME/etc/dge.xml on the DGE and must be performed by the NetVigil administrator as described in Section 3.6, "Monitoring Log Files" on page 3-42.

A single Regular Expression test can match multiple patterns. For example, if you wanted to watch for various security violations, you might name the regular expression list Security Violations and enter the following two patterns: 

:\d+\s+(\w+)\s+sshd\[\d+\]:.*:\s+(illegal user .*)    WARNING 
:\d+\s+(\w+)\s+.*%SEC-6-IPACCESSLOGP:\s+(.*)\s+       CRITICAL

When you configured a test to monitor the Security Violations regular expression list, the test would take action when either pattern was matched. If the first pattern was matched, test status would be Warning. If the second pattern was matched, test status would be Critical.

  1. Click MANAGE | Devices.
  2. On the Manage Devices page click Tests (for any device).
  3. On the Manage Tests page, click Create New Advanced Tests.
  4. In the Regular Expression Test area of the Create Advanced Tests page, click Manage Message Regular Expressions.
  5. On the Manage Message Regular Expressions page, click Create a Message Regular Expression.
  6. On the Create Message Regular Expression page, enter a Name and Description for the list of regular expressions you want to watch for.
  7. If you want an alarm to appear in the Alarms/Messages window when a regular expression is matched, select the Display in Message Window? option.
  8. For each regular expression that you want to match, enter the following:
    Message Regular Expression Fields
    Field
    Purpose
    Regexp
    The regular expression (pattern) that you want to match
    Severity
    If this regular expression is matched, what should test status be?
    Reset in
    Once test status is set, for how long should it stay in the new state?
    Case Sensitive
    If this is selected, the pattern match is case-sensitive. For example, Invalid Login is not flagged as a match for the pattern invalid login.
  9. Click Create Regexp. The Manage Message Regular Expressions page displays the newly-added expression list.
  10. Create a Regular Expression test to take appropriate action when a match is found

Now that you have configured the DGE to scan the necessary file and created a list of patterns to scan for, you can create a Regular Expression Test.

  1. Click MANAGE | Devices.
  2. On the Manage Devices page, find the device for which you want to create a test and click Tests.
  3. On the Manage Tests page, click Create New Advanced Tests.
  4. On the Create Advanced Tests page, select the Regular Expression Test option, fill in the test name, and then fill in the following:
    Regular Expression Test Fields
    Field
    Purpose
    Message Regular Expression
    The name of the regular expression to be matched. (For information on creating a regular expression, see "Create a list of regular expressions to watch for:" on page 192.)
    Action
    The action to be taken if a match is found.
    Display Category
    The column on the Status Summary page under which this test's status is displayed.
    Extract Message
    The message to be parsed from the matched pattern. This tells NetVigil which part of the received trap or log entry is the actual message, so that it can be stored in the database (and, optionally, displayed). This field is not case sensitive.
    Extract Device Name
    The device name to be parsed from the matched pattern. This tells NetVigil which provisioned device the message belongs to. If the device name cannot be extracted from the message, or if it cannot be matched with the name of a provisioned device, the received message is silently discarded.
    Device Aliases
    If messages may use multiple names to refer to the same device, list alternate names here.
  5. Click Provision Tests.

14.3.2 Processing SNMP Traps

SNMP traps that are received by NetVigil are treated like log files or text messages and processed by the Input Stream Monitor (ISM). In order to take actions against a trap, you must create a list of regular expressions and then create a test to trigger an action when a regular expression from the list is matched.

NetVigil only accepts and processes SNMP traps from devices it knows about. If a trap is received from a device that is not in the provisioning database, the trap is silently ignored. If you want to monitor SNMP traps from a certain device, and not perform any proactive monitoring, simply add the device in NetVigil without creating any tests (e.g. ping, snmp, etc.).

This process has three steps similar to the processing of log files described above. These steps are:

  1. Configure the DGE so that it accepts incoming traps. This step must be performed by the NetVigil administrator.
  2. Create a list of regular expressions (patterns) to watch for
  3. Create a Regular Expression test to take appropriate action when a match is found for a pattern in the list
  4. Configure the DGE so that it processes incoming traps:

This requires editing NETVIGIL_HOME/etc/dge.xml on the DGE and must be performed by the NetVigil administrator.

Create a list of regular expressions to match the incoming traps, following the procedure described in "Create a list of regular expressions to watch for:" on page 192.

Each varbind of a trap is passed to the ISM in the following general format: 

TRAP: uptime host_name (enterprise_oid) varbind_oidN = 
varbind_valueN

If DNS resolution is disabled, or DNS resolution failed, host_name will be the IP address. A regular expression pattern like TRAP:\s+\d+\s+(\S+)\s+(.*) would match all traps. For example, if you have a Cisco router that you wish to watch for link up/down traps via CISCO-SYSLOG-MIB, you would create the following regular expression list:

Sample ISM Regular expressions for Cisco MIBs
Pattern
Severity
TRAP:\s+\d+\s+(\S+)\s+.*\.4\.1\.9\.9\.41\.1\.2\.3\.1\.5[\.\d]+\s+=\s+\"(Interface.*down)\

WARNING

TRAP:\s+\d+\s+(\S+)\s+.*\.4\.1\.9\.9\.41\.1\.2\.3\.1\.5[\.\d]+\s+=\s+\"(Interface.*up)\

OK

If DNS resolution is disabled, you will need to add the IP address (may be different from IP address of router as configured in NetVigil if "source interface" for SNMP traps is different) in the list of device aliases. When Serial0/0 loses link, a trap is received, and the following message is displayed in the message window with warning severity: 

Interface Serial0/0, changed state to down

Similarly, when the link comes up again, the following message is displayed: 

Interface Serial0/0, changed state to up

Lastly, you need to create a Regular Expression Test to trigger an action when a regular expression match is found. This procedure is similar to the one described above for Log File Monitoring.

As an example, if you wish to receive notification via E-mail when a particular trap is matched, you can assign an action profile with an E-mail notification to the pattern match test. A sample E-mail may look like this:

This message has been generated by NetVigil for the following monitored object:

 

Department Name : Network_Operations

Device Name : router01.fidelia.com

Device Address : 192.168.1.254

 

Log File Monitor has detected a match against following regular expression:

 

TRAP:\s+\d+\s+(\S+)\s+(.*)

 

Matched log file entry:

 

(.1.3.6.1.4.1.9.9.41.2) .1.3.6.1.4.1.9.9.41.1.2.3.1.5.106 = "Interface Serial0/0, changed state to down"

Note that E-mail notification for SNMP trap/pattern match are bound by the parameters of the action profile. If the E-mail action has don't repeat it set for repeat frequency, then only the first match would be E-mailed. For trap specific action profile, the repeat frequency should be every test.

14.3.3 URL Transaction Tests

You can create a URL transaction test in NetVigil which can connect to a web site, fill in a form, click on various hyperlinks, etc. so as to simulate a real user. This is a very powerful feature in NetVigil which allows testing the response time and errors in most web enabled applications.

The system is fairly intuitive with context sensitive help and has a mini-browser that displays the various stages of the URL transaction. You can then save and even export/import this transaction for other sites.

14.3.4 Advanced SNMP Tests

NetVigil automatically detects standard MIBs and their tests. To run a test that is part of a vendor-specific MIB, you can create an Advanced SNMP Test containing the OID of the vendor-specific test.

14.3.5 Advanced Port Tests

Advanced Port Tests allow you to send a text string to a TCP port, then check the response against an expected string (the return string does not have to be a perfect match, only a substring match).

14.3.6 External Tests

An External Test is one that is run outside of NetVigil (by a standalone script, for example). The test result is inserted into NetVigil via the External Data Feed (EDF) and aggregated as though NetVigil had collected it. Although the test itself is not run by NetVigil, by creating an External Test, you determine how test results will be processed after they are received via EDF.

14.4 Suppressing Tests

When you suppress a test, it continues to run at the specified interval and trigger events, notifications, etc., but its status does not affect the overall status of any associated device, Service Container, or Department. When the status of the test changes (e.g., from WARNING to CRITICAL or from CRITICAL to OK), the test is automatically unsuppressed and NetVigil agains takes the test's status into account for determining device, Service Container, and Department status.

In the default sort order of the Device Details and All Tests Summary pages, suppressed tests appear at the bottom of the list with a single arrow to the left of the status icon. (For additional information, see "To see which tests are suppressed:" on page 205.)

IMPORTANT: A suppressed test continues to run, but its status does not affect the overall status of related objects. A suspended test stops running and does not trigger events, notifications, etc. until it is resumed.

For example, assume that a device has two network tests configured. When both tests have status OK, the overall status of the device in the Network column of the Device Summary Page is OK. If one of these tests goes into WARNING state, the overall status of the device in the Network column of the Device Summary Page changes to WARNING. However, if you suppress the test that is in WARNING state, the status of the remaining tests determines device status. In this case, there is only one other test, with status OK, so the overall device Network status is OK.

If the suppressed test returns to status OK, it is no longer suppressed. The next time its status becomes WARNING, overall device status will also become WARNING, unless you suppress the test once again.

The suppressed tests at the bottom of the list on the All Tests Summary and Device Test Summary pages, and are marked by a single arrow to the left of the Status icon.

14.5 Smart Thresholds Using Baselining

Baselining is a process by which NetVigil can automatically set the Warning and Critical thresholds for each test based on the test's historical data. This allows one to set customized thresholds automatically based on each tests's individual behavior.

As an example, the response time for a local device is normally much smaller than the response time for a device in a remote datacenter because of network latency. Rather than setting the response time Warning threshold for all devices to be the same, you can use baselining to calculate the 95th percentile of the response time reported for each device over a three-month period, and then set the Warning threshold to be 10% higher than this 95th percentile value.

The Baseline Data Set

The baseline value is calculated for each test based on its own historical data. You select the devices and tests for which you want to run baselining by specifying a combination of device name, test name and test type.

Each time NetVigil aggregates a test result, it stores three values: The minimum, maximum, and mean values of the tested variable over the course of the aggregation period. For example, if NetVigil is configured to store data for 1 day at 10 minute samples, and a test is set up to run every 10 minutes, in the course of a day it generates 144 test results. Each test result includes the maximum, minimum, and mean values of the tested quantity for the 10 minute period. You can generate a baseline from the maximum, minimum, or mean samples within the specified date range.

Managing Baselines

The table that follows explains the items on the Baseline Management page:

Baseline Management fields
Field
Purpose
Device Name/RegExp
The name of a device whose tests are to be baselined, or a regular expression containing `*' wildcards to match multiple device names.
TestName/RegExp
The name of an individual test to be baselined, or a regular expression containing `*' wildcards to match multiple test names.
Test Type/Subtype
The Monitor and Subtype of the test(s) to be baselined. e.g. port/http, snmp/chassis_temp
Start Date, End Date
The start and end date of the test results to be used in calculating the baseline. Note: Each selected test must have test results available for the full date range.
Taking values of
The value from each test result (maximum, minimium, or mean) that is used to calculate the baseline. See "The Baseline Data Set" on page 205 for more information.
And using the
The method (average or 95th percentile) used to calculate the baseline from the maximum, minimum, or mean test results. average is the mean of the test results (sum of test results / number of test results).
Warning Threshold
A percentage above or below the calculated baseline. Select above if the test result gets worse as it gets higher. Select below if the test result gets worse as it gets lower. When the test result crosses this threshold, test status is set to Warning.
Critical Threshold
A percentage above or below the calculated baseline. Select above if the test result gets worse as it gets higher. Select below if the test result gets worse as it gets lower. When the test result crosses this threshold, test status is set to Critical.

Note If you access the Test Baseline Management page from either the Manage Tests page or the Update Test page, some of the Baseline Management information is filled in.

14.6 Managing Service Containers

Service containers allow you to group tests and devices to create logical, business-oriented views of your network in addition to your hardware-oriented views. An Administrator can create a service container that includes tests and/or devices from multiple Departments (e.g., any Departments associated with a User-Class that the Administrator controls).

You can generate reports on service containers, get uptime, and get real-time status if any of the underlying components fail or cross any threshold.

NOTE Service Container is a generic term, and can refer to either a Test Container (Virtual Device) or a Device Container (see below).

NOTE Updating or deleting a Service Container has no impact on devices or tests. If you delete a Test Container, for example, the tests included in the Test Container still exist in NetVigil.

There are two types of service containers:

Test Containers (or Virtual Devices) contain tests only. A real NetVigil device has a collection of tests associated with it. A Virtual Device is a collection of tests that are logically related, but not associated with the same physical device. For example, you can create a Virtual Device that includes ping tests for all devices on your network. This allows you to see at a glance which devices are unreachable without looking at test results for individual devices.

Device Containers can include both real devices and Virtual Devices (described above). They can also include other Device Containers, creating a nested hierarchy. For example, you can create a Device Container called Payroll that comprises the web server, router, and backend database used by the Payroll division. This allows you to quickly spot and troubleshoot problems that affect the Payroll group's ability to provide service.

Figure 14.6 illustrates a Device Container that encompasses real devices, a Service Container, and a nested Device Container.

Example: Device Containers and Virtual Devices

Device Tags

In addition to standard device properties (device name, model, etc.) NetVigil provides five customizable tags, which you can define to meet your needs. You can use these tags to create rules for populating Device Containers, as described in "Rule-Based Device Containers" on page 210.

IMPORTANT: By default, tags are labeled on the Create Device page as Custom Attribute 1, Custom Attribute 2, etc. If you use tags to create rule-based containers, we strongly recommend that you (or your NetVigil Administrator) replace the defaults with meaningful labels (e.g., State, City, etc.) as described in Section 3.4.14, "Customizing Device Tag Labels" on page 3-34. Otherwise, users may confuse the different tags, which can cause devices to be incorrectly added to or omitted from Device Containers.

Rule-Based Device Containers

When you create a Device Container, you can populate it in one of the following ways:

Rules work through Perl 5 regular expression matching and have the following form: 

device_property is like regular_expression

Where device_property can be device name, device type, device model, vendor name, or a tag (see "Device Tags" on page 209 for additional information).

When a rule-based container is created, existing devices whose properties match the rule(s) are automatically added to the container. When a new device is added to NetVigil, its properties are checked and it is assigned to all rule-based containers whose rules it matches.

Example: Tags and rule-based containers

A NetVigil administrator wants to create Device Containers for devices in specific locations. She also wants to create Device Containers for devices belonging to specific corporate groups. She defines tags as follows:

Then, the administrator creates the following containers:

Container Name
Rules
NJ_branch_01_device_cont 
State is like: NJ
City is like: Princeton
Branch Office is like: Pr*
NJ_branch_02_device_cont 
State is like: NJ
City is like: Trenton
Branch Office is like: Tr*
Payroll_device_cont 
Corporate Dept. is like: PAYROLL
Manuf_device_cont 
Corporate Dept. is like: 
MANUFACTURING

When a user creates a device, they fill in the state, city, branch office, and corporate department properties. NetVigil then assigns the newly-created device to all of the containers whose rules it matches.

If you choose this option, you can manually add real devices, Virtual Devices, and nested Device Containers. Continue with Step 6.

If you choose this option, NetVigil automatically assigns all real devices that match the rules to this Device Container. Continue with Step 7.

  1. To manually populate the container, select real devices, Virtual Devices, and/or Device Containers in the Available column and click the right arrow to transfer them to the Currently Used column. (The names of Virtual Devices and Device Containers are preceded by a # sign.) Continue with Step 8.
  2. To create rules, enter a regular expression for pattern matching in one or more of the Property is like: fields. For example, if all devices belonging to the Finance group have device names starting with "Fin_", you can create a rule to match all devices where Device Name is like: Fin_*.
  3. When you have either selected all of the devices and containers that you want to include, or created a rule for including real devices, click Create Container to create the Device Container.
Creating Service Containers

Once the container is created, it is displayed in the Manage > Containers web page:

Sample Containers

14.7 Managing Action Profiles

NetVigil supports actions in the form of alphanumeric paging, E-mail, Compact E-Mail, SNMP Trap or executing an external script. Typically, actions are some form of notification that a test result has crossed a defined threshold into OK, WARNING, CRITICAL or UNKNOWN status. An Action Profile is a list of up to five actions, allowing the user to define multiple notification recipients and specific notification rules for each recipient.

There are many types of built in notification and action mechanisms in NetVigil:

This is the simplest notification- it sends an email to the specified email address using the mail gateways specified by the NetVigil administrator.

To send a pager using a directly attached modem, select Alphanumeric Pager from the Notify Using list. Then, specify a Message Recipient in the format PIN@PC, where PIN is the recipient's Personal Identification Number (usually the pager number) and PC is a `paging central' location defined by your NetVigil Administrator for the DGE that will generate the notification. See "To create an action profile:" on page 218 for detailed instructions.

For example, assume that an Administrator has set up a `paging central' location called nextel that is used when NetVigil sends pages to Nextel customers. A typical pager message recipient might be 7325551212@nextel.

(This feature might require purchasing a license from Fidelia). You can directly open a trouble ticket in RT or Remedy, and have a URL to this ticket displayed in the Status page.

You can send an SNMP trap to another SNMP trap handler if desired.

NetVigil's plugin architecture allows you to create any number of additional "plugins" that will be displayed in the drop down list. See Chapter 21, "Plugin Actions"for more details.

Figure 14.9 below illustrates how a test result can trigger multiple actions.

Example of Test Results Triggering Actions

Action Profiles can be created by either end-users or an Administrator to notify up to five separate recipients when a test status changes, or when a test status has been in a particular state for a predetermined number of test cycles. In the above example, the action has been configured with three separate sub-actions in a typical escalation scenario. When the Ping RTT test on the NT Server reaches a WARNING status, the NOC Administrator receives an E-mail notification of the problem. If the test crosses the upper threshold to CRITICAL status, the NOC Manager is notified. Once the test has remained in CRITICAL status for three (3) test cycles, the senior management is notified.

Note Action Profiles must first be defined before they are available to be assigned to one or more tests.
Note When you receive an E-mail notification that a test result for one of your devices has crossed into WARNING or CRITICAL status, that E-mail has only been sent to you or to the distribution list of which you are a member. The thresholds your administrator uses to trigger notifications may be different from your personal thresholds. Please do not create actions to alert the administrator or IT staff.

14.8 Managing Account Preferences

These changes will become part of your user profile and will serve as defaults each time you log in to NetVigil.

Fidelia Technology, Inc.
Contact Us
Table of ContentsPreviousNextIndex