Tap In scripts
Users can perform two types of service checks: external and internal. External checks are executed on the Tap In Management Server and test services that are available over the Internet. Since external checks don’t depend on internal infrastructure, they are useful for testing services as your customers or end users would see them. The external checks are configured using a Web interface on the Tap In Management Server.
Internal checks are performed on the local system. They interact directly with the OS to gather information, and then format and send the resulting events to the Tap In Management Server. Internal checks are executed from the Tap In agent. Typically distributed as open source, agents are scripts that execute individual checks, interpret the results, create a Tap In event, and then sends the event to the Tap In Management Server in the cloud. The checks to execute and their parameters, such as alerting thresholds, are defined in a configuration file.
Whether external or internal, the following checks are available:
Simple scripts
These scripts adhere to the Nagios plugin specification and are the easiest to create. All that is required is that the script set the exit code to severity (OK, warning, critical or unknown) and print the event message text to standard out. For internal scripts, the agent will wrap these results into a Tap In event, and then send it to the Tap In Management Server. For external scripts, the Tap In Management Server will interpret the results and create the event. Operators also may use scripts from the open source Nagios plugin project, or create a custom external script using Perl, Ruby, or another language as long as it adheres to the Nagios plugin specification.
Tap In supports the addition of performance information in the event stream if the scripts adhere to the Nagios plugin performance specification. Graphical reports are automatically generated on the Tap In Web reports server if performance data is specified.
Mediator scripts
Mediator scripts are similar to simple scripts in how they are invoked, except that they format and send events to the Tap In Management Server. The Tap In event message fields are described here. The additional fields allow additional systems management data to be associated with the status event. These fields enhance Tap In reports. Here is an example: if you are monitoring multiple disk volumes with a single check and want to generate separate events for the status of each volume, a single script would issue the command to query all volumes, and then determine each disks status. An event would then be sent for each volume. The type-name fields of the event specify the volume name. The Tap In Management Server processes the event and displays the specific disks on the QuickView console, and/or the Tap In Web viewer.
Consumer-Mediators
Consumer-mediators are scripts that interact tightly with the Tap In Management Server. They can receive management events from the server and also generate events. These scripts are used to manage complex applications, perform automated actions, or to integrate other management tools.
One example is an analysis script that looks at the status of multiple events (from various devices and technologies) that are received by the Tap In Management Server, and then generates a new event. Or, suppose you want to generate a high priority event if 75 percent of the Web servers are in critical condition and 50 percent of the database servers are down and the number of users is greater than 1000. A script can log in and examine the events for this condition, then generate a new event when it occurs, or take a recovery action. It can even “close” or delete open events that it deems obsolete.
The Tap In Perl package includes methods required to log in and read Tap In Management Server events. The user ID and the events that this ID is allowed to see must first be defined in the Tap In Management Server to support this script.
A configuration file on the Linux system defines the plugin scripts, execution parameters and alert thresholds for an agent. This file is designed so that common servers can use the same configuration file and system specific parameters do not need to be defined.
