Types : Monitors

Types of Monitoring

Basically, there are two approaches to monitor machines under test:

1. Internal Probes/Agents that run within the server (as a process/daemon) and sends counter values to an application like the Windows Task Manager or out to a Diagnostics Mediator/Server
2. External Monitors (such as the unix rstad daemon) that respond to operator commands sent using SSH (Secure Shell) protocol through the network to the server being monitored, which then responds with another transmission over the network.

External Monitors

The amount of resources used by each server in an J2EE or .NET application can be monitored externally by sending requests to Windows performance monitor or commands as a Unix Secure Shell (SSH) session user.

Since all monitoring requests orginate from outside the server being monitored, some call this a "black box" approach to testing.

This is the approach used by Mercury SiteScope, LoadRunner and Business Process Monitor.

Just because a monitor is "agent-less" doesn't mean that it is "non-intrusive" in that it imposes overhead on the system being tested.

Probes/Agents Within Servers

This approach is classified as "white box" testing because probes are installed inside each app server under test (SUT).

This is why product ReliAgent, calls its probes embedded "narks".

After a probe is "instrumented" to recognize methods running on its app server, it makes an announcement whenever it detects invocations of servlets, JSPs, EJBs, JNDI, JDBC, JMS, and Struts.

Probes report on JVM memory heap usage and the memory consumption of Java collections.

MS Windows Task Manager There are several ways to invoke the Task Manager: Press Ctrl-Shift-Esc keys at the same time. Press Ctrl-Alt-Del, then select Task Manager. Press and R at the same time or press then R for Run and press Enter, then type taskmgr and click OK. This sample screen shows both green User mode and red kernel mode CPU Usage because View, Show Kernel Times has been selected: By default, the update speed is set to “Normal”, which means once per second. I prefer the "Low" setting when I see what is hogging up CPU cycles (by clicking the "CPU" heading): Metrics shown in the Processes tab can be selected from View, Select Columns: The above are defaults. Session ID and User Name are new since Windows XP.

Unix Systems Monitoring This section discusses performance monitoring tools among variants of the UNIX operating system which consists of: The kernel, the shell, and the file system. Nagios is a popular open-source performance monitoring. Pro Nagios 2.0 (Apress, 2006, 424 pages) by James Turnbull Site Scope Mercury Site Scope monitors almost all (50) aspects of running Windows and UNIX systems (networks, servers, services, datatabases, applications, etc.) Colorado based Freshwater Software charged $2,495 for it before (on April, 2003) Mercury bought it and now sells it for $60 per unit (the number of servers multiplied by the number of counters monitored on each machine). So Sitescope monitors can be viewed among other LoadRunner Controller System Resource Graphs: CPU Utilization Monitor DNS Monitor Directory Monitor Disk Space Monitor Log File Monitor Memory Monitor Network Monitor Ping Monitor Port Monitor Script Monitor Service Monitor URL Monitor URL List Monitor URL Sequence Monitor Web Server Monitor WebLogic Application Server Monitor SiteScope is called an "agent-less" technology because it sends native UNIX commands (defined in \SiteScope\templates.os). Sitescope exerts about a 10% overhead on servers responding to remote queries. However, it duplicates the same requests made by LoadRunner's UNIX monitors (hitting servers with twice as much monitoring traffic). Perhaps for this reason the SiteScope monitor has a default measurement update rate of once every 10 minutes. Unless you change this default to 15 seconds (the most frequent allowed), you won't see measurements in Controller graphs. Invoke SiteScope. Click on the name of the monitor. Click on "Edit" next to the Counter name. In the "Update Every" entry, change the value to 15 seconds. Click on the "Update" button to register the change. Linux Status Commands uptime provides an instantaneous summary such as 11:42pm up 18 days, 8:45, 5 users, load average: 0.01, 0.03, 0.07 For the current time, the Number of days up since last boot, the number of users currently logged in, and the load average for the last 1, 5, and 15 minute intervals. The load average (LA) is the average number of processes (the sum of the run queue length and the number of jobs currently running) that are ready to run, but are waiting for access to a busy CPU. Averages from 0 to 1.0 are acceptable for a single CPU. As a general rule of thumb, a machine is being overworked if load averages consistently exceed three times the number of CPUs. top provides load average with auto refresh and additional data (sorted by %CPU): 68 processes: 67 sleeping, 1 running, 0 zombie, 0 stopped CPU states: 12.2% user, 1.6% system, 0.0% nice, 86.1% idle Solaris comes with the prstat command to provide this info. Graphical versions of this include gtop within Gnome and the KDE Process Monitor. Linux Load Average Not Your Average Average by Neil J. Gunther For memory usage, press M. For CPU info, press P. To stop display, enter q. The 'SIZE' field is the total virtual memory size of each process, including all code, data, stack, mapped files, libraries etc. procinfo -fn30 is used to gather system data from the /proc directory every 30 seconds. Last Boot time Load Average average number of jobs running number of runnable processes total number of processes PID of the last process run (idem) Swap info Memory resources Number of disks IRQ info Installed modules (with the -a or -m option) File Systems (with the -a or -m option) xos provides a constantly updated colorful summary view of various components.