Chapter 1. Introduction to RSP

Table of Contents
Introduction to RSP Features
Real-Time Monitoring
Post-Time Analysis
Incident Tracking
Hardware Management
Feature Integration
Advanced Features
How RSP Works
Installation of RSP
What's Included in this Manual

RSP is a fully functional, integrated network management system. It provides a single architecture to monitor, manage, and organize your computer network. In this chapter we will introduce RSP and discuss its main features and philosophies.

Introduction to RSP Features

There are four main facets that make up the core of RSP's network management capabilities: real-time monitoring, post-time analysis, incident tracking, and hardware management. These features are fully integrated into a single web application called RSP Web. Let's look at each one in more detail.

Real-Time Monitoring

RSP provides extensive network monitoring capabilities. On each machine in your network, RSP has a list of modules, which are small plugin programs. Each is responsible for a single system statistic. The following modules are provided out-of-the-box:

  • CPUStat - CPU usage

  • DiskFree - Disk usage

  • DiskStat - Hard Disk Statistics (such as transfers/sec, queue length, average time to serve, etc)

  • PingCheck/HostCheck - Remote host availability

  • MemStat - Memory usage

  • DBStat - MySQL & PostgreSQL database statistics and monitoring

  • IntegCheck - Web page integrity ("hacker checks")

  • NetStat - Network statistics and bandwidth utilization

  • PortCheck - Remote port checking (to ensure services are responding to user requests)

  • TopCount/TopCPU/TopMem - Top CPU & memory usage

  • ProcCount/ProcInfo - Individual process monitoring (memory & CPU usage)

  • UserCount - Users logged in

  • Uptime - System Uptime

Each of these modules can have preset threshold warnings. A threshold is considered cross when a predefined condition becomes true. For example, for DiskFree this might be when a particular drive becomes 95% full. Thresholds can also cover multiple modules, so you could define a threshold that would be crossed if either the memory or CPU usage went above 90%.

When a threshold becomes crossed, you can have RSP send an email, issue a system command, or both. This can be set on a global or per-threshold basis to allow for maximum configurability. Low-priority thresholds may not require any warnings, whereas problem situations can be immediately stopped by sending a text message to a cell phone.

In addition to the modules described above, you can write your own modules using RSP's provided Module API. Modules may be written in C/C++, Java or Perl, and only a few function calls are needed to send any piece of data into RSP. For example, a company may have a temperature sensor in its server room. A module could be written that simply collects the data and gives it to an RSP node. RSP would then provide monitoring, analysis, and threshold checks for that data, as part of its architecture.

Post-Time Analysis

Along with an interface to view up-to-the-minute statistics, RSP provides methods to store and view historical data. When a particular module is viewed through the RSP Web interface, history graphs are automatically created so that the current data can be compared to recent data. In addition, more sophisticated graphs can be created using Reports wizard, that can cover any period of time or any available data.

Storage of history data can be done in a MySQL database. However, RSP provides its own database program called the History Listener that can also be used. The History Listener is a small, low overhead program that has been fine-tuned specifically for RSP module data. Retrieval using this program is very fast (using intelligent logic metrics for searching through data), and efficient (using data compression). Further, the seamless integration between this archival/retrieval program and the related post-time analysis tools allows for a greatly simplified experience.

Incident Tracking

Another important RSP feature is the ability for IT teams to collaboratively view, discuss and solve network problems as they arise. As an issue comes up on a machine, a ticket can be created to describe this problem. A ticket has a date, event, description and severity associated with it. A ticket can then be assigned to a particular user, and then closed and archived after it is fixed. Users can also make comments on tickets.

There are a number of benefits to using this kind of system in a network environment. First, using tickets allows for a common place to view, organize and prioritize problems. This prevents confusion among the IT staff. Next, the ability to assign tickets provides a simple way to get the problems solved by the right people. Allowing users to make comments on tickets lets the conversations associated with fixing problems exist in a common environment where everyone can access it. Since by default tickets are stored after being closed, users can benefit from experience the next time a similar issue arises.

Users can create tickets when incidents occur; however tickets can also be created automatically when thresholds become crossed. Since crossed thresholds usually correspond to network problems, this minimizes having to manually create tickets one by one when something happens.

In a large, busy network, there are bound to be a lot of issues coming up, both big and small. That's why RSP can send out emails when ticket changes happen, and lets users invidually configure how they should be warned when something happens. For example, a user might want to receive an email every time a new ticket is created or any kind of state change happens (like a new comment or a severity change). Or, a user might want to only recieve emails when a ticket becomes assigned to them. The ticket configuration lets each user decide how much they need to know.

Hardware Management

Another tool in RSP is the ability to view and search the hardware for each machine in the network. RSP nodes can automatically check the computer on which they're running and retreive information including kernel version, processor, memory, hard drives, network controllers, and PCI cards. These checks are done by default (although they can be turned off) meaning no additional configuration is required.

Each machine sends its hardware inventory to RSP Web along with the monitoring data. You can either view this information on a per-machine basis, or use RSP Web's searching mechanism. The hardware search page allows for sophisticated searching based on specific criteria. For example, if you needed to do an memory upgrade on your Windows machines, you could specify that you want to see memory results for machines with the OS "windows". Data can be searched, viewed and sorted as desired, so that hardware information doesn't have to become excessive or unwieldy.

Feature Integration

Although each of the aforementioned features could be its own tool (and for many IT teams it is), having all of them exist in the same network management tool provides a number of benefits. The first is one of ease and simplicity. When you click to see a host's information in RSP Web, you'll see its current system statistics, open tickets, and hardware information all on the same page. When you view a particular ticket, you can just click a link to see what's happening right now on that machine. This ease also continues to setup, since it means only one host agent needs to be configured to provide all of the management features described above. Integrating these management capabilities also allows for features that wouldn't otherwise be possible. For example, automatic ticket creation when thresholds are crossed.

Advanced Features

There are also a number of advanced RSP capabilities which deserve mention. The first is the RSP Lib API. This API includes a number of functions that can be useful to developers. The API handles the backend code of connecting to an RSPD node and collecting current module statistics. There are also functions to connect to History Listener and MySQL servers to gather RSP history information. This means someone could create their own RSP monitor if desired, such as one that shows information in a custom application or web page. It could also be used to create scripts that gather data, such as one to generate usage reports. The RSP Lib API has C/C++, Java and Perl verions.

RSP Web also has a few additional features that can be useful. The first is remote configuration. Each RSPD node running on the network's machines has its own configuration file associated with it. This file can be edited and the RSPD restarted, but you can also configure RSPDs through RSP Web. RSP Web can connect to the RSPD and retreive the current configuation state for a node, and then display it in an interface that allows for individual settings to be changed. Once saved, RSP Web will connect back to the node and tell it to reload its settings. Better yet, groups of machines can be reconfigured all at once. This means if you want to change the location of a History Listener, for example, you could change the IP address on 30 machines with just a few mouse clicks.

RSP Web also lets you view log files RSPD nodes to see recent RSP activity. This combined with the remote configuration ability mentioned above means you should only rarely have to connect to individual machines when administering RSP. Another useful RSP Web feature is the Whiteboard, a block of text or HTML that can be changed by admins and is viewable by all users. This could be used for escalation procedures or login directions.

RSP also has a number of security features. First, SSL is used by default in all network communication. In addition, you can define which machines can and can't connect to each RSP node though block/allow settings. For example, you could block all incomming connections that aren't from your internal network block. Security also exists for RSP Web users. People can only view RSP information if they login as an RSP Web user. Admins can change a number of permissions on a per-user basis. These settings include the ability to create users, create/delete tickets, make comments on tickets, change the state of tickets, reconfigure servers, or edit the whiteboard.

How RSP Works

The setup of RSP is relatively simple. In order to collect system information on a machine, an agent called RSPD (RSP Daemon) needs to be run on it. The RSPD is a low overhead program that takes care of communicating with modules (which actually gather the monitoring statistics), determining hardware information, and checking thresholds. If history data will be saved, the RSPD will take care of contacting the History Listener or MySQL database and periodically sending data to it. There are a number of ways to configure RSPD, including which modules to check, defined thresholds, and how (or if) to save history data. There are also logging and security settings that can be set. For more information on RSPD please see Chapter 2, and for descriptions and settings on RSPD modules see Chapter 4.

The History Listener is a small database program developed specifically to handle RSP module data. A History Listener can be run on any machine on your network as long as the RSPD nodes can get network access to it. More information on configuring a History Listener is in Chapter 3.

RSP Web is the tool that is used to view all of the management information provided by RSPD nodes. It's also used to manage incidents (through the Ticket Manager), as well as search hardware information. The RSP Web is a web application, meaning users can connect to it through their browsers without installing anything on their machines. Although RSP Web works through the browser, it doesn't require any existing web server like Apache or IIS. It has a single configuration file that allows you to change things like which port it should run on, and which machines it should connect to. You can think of it as any other daemon that you would run, that happens to communicate over HTTP with browsers. Full details on RSP Web and all its features exist in Chapter 5.

Installation of RSP

Installation of RSP is quite simple regardless of what system you are using. For machines running UNIX, download or copy from the installation CD the Solaris package, unzip it, and install using `pkg-add'. So the installation process would look something like this:

# gunzip rsp-1.1.0.gz
# pkg-add -d rsp-1.1.0
		

After installation in Solaris, the various RSP programs will be appropriately located. Configuration scripts for RSPD, the History Listener, and RSP Web will be in /etc/rsp, and these programs may be started and stopped by executing init.d scripts in /etc/init.d. RSP Web will be in /usr/local/rspweb. In addition, all versions of the RSPLib and Module API as well as documentation will be in /usr/local/rsp.

For Linux systems using the RPM package structure, download or copy from the CD the Linux RPM, and install it using the `rpm' command, for example:

# rpm -Uvh rsp-1.1.0-1.i586.rpm
		

After installation in Linux, all files will be located as follows. Configuration scripts for RSPD, the History Listener, and RSP Web will be in /etc/rsp, and all programs may be started and stopped by executing init.d scripts in /etc/rc.d/init.d. RSP Web will be in /usr/rspweb. In addition, all versions of the RSP Lib and Module API as well as documentation will be in /usr/rsp.

In addition, RSP may be installed on both Linux and UNIX systems by downloading the appropriate tarball and running the included install script (install.sh). An example of this on a Linux system would be:

# gunzip rsp-linux-1.1.0.tar.gz
# tar -xvf rsp-linux-1.1.0.tar
# cd rsp-linux-1.1.0
# ./install.sh
		

On Windows systems, simply run the Setup executable on the install CD or download it from the website. From there an install wizard will guide you through the rest of the process. All programs as well as documentation will be accessible from the Start menu.

What's Included in this Manual

This manual is divided into six main chapters. The first is this introductory chapter, and the next two cover the daemon applications, which include the RSPD and History Listener. These programs are the faceless background applications that collect system information, store it and transfer it, respectively. Chapter 4 covers the modules, which collect various pieces of data to monitor. Chapter 5 covers RSP Web, the web-based interface application, and finally Chapter 6 covers the RSP Lib API, provided with C, Java and Perl interfaces.