Monitor de Sistema
(español)

Version 6.1.1, 19th March 2018

Copyright © 2008-2018 Mark G. Daniel
This program, comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it under the
conditions of the GNU GENERAL PUBLIC LICENSE, version 3, or any later version.
http://www.gnu.org/licenses/gpl.txt

Contents




MonDeSi  (pronounced "mon-deh-sih")  is a browser-based VMS system monitor with a sufficiently small resource footprint** to not impact system performance. No, the name's etiology has little significance at all (a small homage at most). I was just looking for a short (and cute) name. ** YMMV with platform and selected items but on an AlphaServer DS20E and HP rx2660 significantly less than 0.001 of a CPU.

MonDeSi is intended as a general tool for system observation. It is not a troubleshooting tool as such, especially when a system is beginning to suffer from resource exhaustion. Not only does the data collection script need to continue processing effectively (see Sufficient System Priority below) there is also a Web server in the data transfer path.

MonDeSi provides (depending on environment and configuration) textual and graphical data showing

MonDeSi should work with all relatively modern browsers. Developed against Chrome, Firefox, MSIE (10+), and Safari, on OS X and Windows platforms. It uses HTML5 elements including SVG for graphing and will not work with the HTML4 generation of browsers.

MonDeSi operates as a CGI web application and so is suitable for VMS Apache, OSU and WASD scripting. It can also run as a CGIplus application under WASD, improving latency and performance, and more importantly as a WebSocket application under WASD 10.1 or later, further improving latency and in particular per-process monitoring behaviours. When selecting per-process display there is some latency (and patience required) on non-WASD (non-WebSocket, CGI) platforms.

NOTE: MonDeSi version 6 reverts to the undocumented system service $GETSPI. Version 5 and earlier used $GETRMI. $GETRMI seems to have been intended as the "modern" and documented version of the $GETSPI functionality. Unfortunately, after dealing with it for a while, it's difficult to shake the impression that someone lost interest halfway through the project! Reverting to $GETSPI also allows MonDeSi to be deployed on VAX (although some minor items are not supported).

Displayed values have been validated using the interactive MONITOR utility.

Usage

MonDeSi is activated by accessing the URL for its script location. For WASD this is usually something like (and may well open MonDeSi on this system):
http://the.site.name/cgiplus-bin/mondesi
Alternatively, a standalone MonDeSi can be opened using
a bookmarklet

MonDeSi opens displaying the textual system information at the top left and system resource instantaneous utilisation bar graphs at the top right, seen on the image below. Checkboxes below the system information allow various aspects to be toggled on/off. Depending on system and configuration, a checkbox can be disabled and greyed-out, with underlying functionality unavailable. Sections open revealing additional information, and close hiding that information again. Values in graphs are adjusted to meaningful units, and maxima, if not fixed, represent values of the last five, or fifteen, minutes. Checkboxes activate the described functionality. Alerts will be displayed in red immediately below the block of textual information, and can be cleared by clicking over them. Alerts include increases in disk and NI error count, change in cluster membership, low page file free space, and other messages. Tooltips are provided for all major elements of the report.

 (left) Adjacent to the node name, the checkbox minimises the per-node display. When unchecked, the node name, host name, VMS time, proceessing synopsis, and any recent alert, are displayed in place of the full display.
Click and hold to enlarge ... or ... mondesi.png

(Safari 8 on OS X, showing standalone MonDeSi)

disables data collection, closing the connection to the data source script.
disables data update but continues to collect and store data. Pausing the update allows a specific report to be examined without disturbance. Re-checking the box updates the display from the point it was disabled.
disable in the case of excessive alerting.
pop-up tooltips.
opens the line graphs seen at the lower half of the image. These provide five, or fifteen, minute summaries of the instantaneous system data shown in the bar graphs. Appropriate graphs contain an average. CPU shows total and then non-USER (S+E+K) times; faults show total and hard; locks show total activity and waits; NI (network) shows total and reads; disk shows total and writes, and processes, total and interactive. NI error counts are displayed in red on the graphs. Some graphs display a ↷ character following the label indicating additional or alternate data may be displayed by clicking on the graph.

expands data collection and the history graphs from 5 to 15 minutes. The complementary checkbox returns to a 5 minute history display but continues to collect over 15 minutes.
enables related items as bar and history graphs.


(when configured) displays individual disk device activity. Bar graphs for each are appended to the default, and when the history display is visible, line graphs representing device activity for the last five, or fifteen, minutes are also available. These graphs also display device size, percentage free, IOP queue length, and free space delta. Clicking on the graph cycles the display to show IOP queue length and then volume free space delta over the data period. Alternatively, graphs concurrently displaying the IOP queue length and/or free space delta may be opened using the adjacent ☰ and Δ checkboxes respectively. Non-zero device error counts are displayed in red.
(when configured) displays immediately below the buttons and bar graphs, counts of the various process states, then the five top processes for CPU, page faults and I/O. Clicking on any of these processes will (if configured) display, below the top five, detailed textual information for that process. Quotas below a threshold (default 15%) are displayed in red. On the far right is the process checkbox which will display, immediately below the textual information, line graphs showing the process CPU, working set, private and global pages, I/O and page faults over a five or fifteen minute period. Process history graphs are more easily distinguished from node graphs by a dagger placed adjacent to the metric name (e.g. CPU† )
deletes all current and stored data
invoke system print dialogue for this monitor
  (top left) The unlabeled checkbox located in the top-left of the monitor displays a section allowing the URLs for multiple MonDeSi sites (one per line) to be configured into a single display. Do not try to mix http:// and https:// specifications in any combination; browsers often block content with mixed security domains. Note that MonDeSi and à la mode URLs can be combined on the one display in either application, as well as DCLinabox terminal URLs.
activates MonDeSi in the same window
activates MonDeSi in a new, independent window. This window is sized precisely for the display and so resembles more a standalone application than a web page. The standalone MonDeSi does not display the configuration option.
JavaScript link for a standalone MonDeSi suitable for embedding as an anchor or usefully, as a bookmarklet for addition to a browser's bookmarks/favorites
the input elements of the configuration page
invoke system print dialogue for entire browser window

Installation

Configuration

JavaScript and other resources located in the [.RUNTIME] subdirectory of the source code must be available to MonDeSi. These must this be mapped into application web-space. For WASD this requires a WASD_CONFIG_MAP rule similar to the following:

pass /mondesi/-/* /wasd_root/src/mondesi/runtime/*

For WASD 10.1 and later WebSocket access requires an additional rule to force CGIplus access, making the WASD mappings:

redirect /cgi-bin/mondesi* ///cgiplus-bin/mondesi*
pass /mondesi/-/* /wasd_root/src/mondesi/runtime/*
...
exec+ /cgiplus-bin/* /cgi-bin/*

Most other MonDeSi configuration items are set using logical names.

Network Devices are automatically scanned for by MonDeSi, with any found used for NI statistics. If the system admin wishes to tailor the source of the statistics the multi-valued logical name MONDESI_NI can be used to specify one or more network interfaces. Define this logical name system-wide (or in a script wrapper procedure) as required.

$ DEFINE /SYSTEM MONDESI_NI EWA0:,EWB0:

This logical name must exist as MonDeSi initialises. If undefined or the specified device(s) cannot be accessed the NI datum is greyed-out.

Disk Devices are displayed as operations (IOPs) per second. To enable this element the system admin needs to define a multi-valued logical name containing the devices to be monitored. Those selected for display must be defined using the device names as shown by a $ SHOW DEVICE command.

$ SHOW DEVICE DKA

Device                Device        Error    Volume         Free  Trans Mnt
 Name                 Status        Count     Label         Space Count Cnt
$1$DKA0:    (KLAATU)  Mounted           0  ALPHASYS       90.22GB   597   1
$1$DKA100:  (KLAATU)  Mounted           0  BACKUP        208.86GB    10   1

and defined as follows:

$ DEFINE /SYSTEM MONDESI_DISK $1$DKA0:,$1$DKA100:

This logical name must exist as MonDeSi initialises. Devices are only displayed when mounted (unsurprisingly :-).

Per-process Quotas are displayed red when that remaining reaches 15%. To change this threshhold define a logical name with the required percentage as in the following example.

$ DEFINE /SYSTEM MONDESI_PROC_ALERT 30

This logical name must exist as MonDeSi initialises.

System process (job) modes using a wildcard $GETJPI scan requires SYSPRV.

$ INSTALL ADD MONDESI.EXE /PRIV=(SYSPRV)

Sufficient System Priority is necessary for a monitor such as this to be effective on a busy system. If INSTALLed with ALTPRI privilege it will bump it's process priority up to 6 when starting (and reduce it back to previous when exiting).

$ INSTALL ADD <location>MONDESI.EXE /PRIV=(ALTPRI)

It sometimes helps to have a bit of an edge!

Per-process data requires WORLD privilege provided by INSTALLing the image appropriately.

$ INSTALL ADD <location>MONDESI.EXE /PRIV=(WORLD)

Concurrrent access to Network Interface (NI) data requires SHARE privilege provided by INSTALLing the image appropriately. Concurrent access is required if multiple utilities or instances of a utility are accessing the NI devices.

$ INSTALL ADD <location>MONDESI.EXE /PRIV=(SHARE)

Of course, the required privileges may need to be combined.

$ INSTALL ADD <location>MONDESI.EXE /PRIV=(ALTPRI,SHARE,SYSPRV,WORLD)

The example MONDESI_STARTUP.COM can assist with this.

Access Control

MonDeSi provides a graduated insight into a system and the security implications of this must be considered. The default data essentially displays resource consumption but the textual information includes node name, cluster membership, VMS version, etc. Do you really want the world viewing this data? Perhaps.  Additionally, it is possible to view top resource consuming processes, PIDs, names, and so forth. World view? Hmmm. Perhaps still.  Then further, it is possible to display intimate detail of any one of those processes. Interesting? Useful? You bet! But you probably wouldn't want such intimacy on the Internet, or even an intranet.

So, it's a given, that most sites using MonDeSi will want some control over who can use it.

Web Server Authorisation can be exercised on the script and optionally its resources. This is the simplest approach.

At the time of writing (early 2017) not all browsers (Chrome, Edge, Firefox and Opera - not Safari) implement HTTP authorisation over WebSocket. WASD users employing WebSocket and authorisation are currently required to disable WebSocket for any other than these!

Additional Access Control may be exercised over who can access the basic monitor information, and then again the more revealing process detail. This is provided using the MONDESI_ACCESS multi-valued logical name. Undefined, the basic system monitor is available to all and process data is unavailable. When defined the first value controls access to the basic monitor, the second value access to top-process data, and the third to per-process data (which also requires the image be INSTALLed with WORLD privilege). An asterisk ("*") indicates anyone. A leading dollar symbol ("$") indicates an authenticated user (not necessarily VMS username). A hash symbol ("#") an IPv4 address and optional CIDR notation. An underscore ("_") can be used to disable access. Multiple elements may be combined as a comma-separated list. This logical name is translated each time MonDeSi assesses access and so may be modified at any time.

This example allows open access to all monitor information including top- and per- process data.

$ DEFINE /SYSTEM MONDESI_ACCESS *,*,*

This allows open access to top-process data and confines access to per-process data to the three specified authenticated users.

$ DEFINE /SYSTEM MONDESI_ACCESS *,*,"$curly,$larry,$moe"

This further constrains access to hosts in the specified subnet.

$ DEFINE /SYSTEM MONDESI_ACCESS *,*,"#192.168.1.0/24,$curly,$larry,$moe"

This example allows the specified three authenticated users access to the monitor, including top-process and per-process data.

$ DEFINE /SYSTEM MONDESI_ACCESS "$curly,$larry,$moe",*,*

Disable WebSocket for all but selected user-agents. As noted above, not all browsers support HTTP authorisation with WebSocket. MonDeSi allows WebSocket access (only available with WASD 10.1 and later) to be automatically disabled for all but selected browsers. Just define a multi-valued logical name with zero followed by values containing unique strings found in capable user-agent strings.

$ DEFINE /SYSTEM MONDESI_WEBSOCKET 0,"Chrome","Edge","Firefox","MSIE","Opera"

Disabling WebSocket adds a little latency and server overhead to some actions, such as per-process display, but does not affect overall functionality.

Problems?

Releases

v6.1.1  19-MAR-2018
•  use DVI$_VOLSIZE for disk capacity (except on VAX)
v6.1.0  15-AUG-2015
•  add volume IOP queue length
v6.0.1  21-APR-2015
•  add volume mount/dismount alerts
•  detect and alert extended refresh period (e.g. suspended)
•  bugfix; build.js fix [link] generation
•  bugfix; CollectDiskSPI() and CollectDiskDvi() in the detection of mount verify in progress
v6.0.0  05-APR-2015
•  significant implementation rework with some user-interface changes
•  JavaScript driven front-end communicating with the executable back-end via JSON
•  HTML5 Scalable Vector Graphics (SVG) graphing
•  reduced footprint and improved efficiency
•  NOTE: resources have changed and mapping rules need to be modified when upgrading (see Configuration)
v5.0.1  02-DEC-2013
•  bugfix; SCS data on I64 (ACCVIO)
v5.0.0  24-NOV-2013
•  expanded 15 minute history display
•  counts of the various process states
•  disk size and usage percentage
•  bookmarklet/open application mode
•  some style changes
v4.0.0  31-MAR-2013
•  Well! Version four! Who would have thought?
   I suppose if it's good enough for Google Chrome to leap major versions in a single bound then it's good enough for us.
•  per-process monitoring
•  this useful little readmore
v3.0.1  22-JAN-2013
•  finally discovered what garbles printable WZ graphics on MSIE (or at least how to prevent it)
v3.0.0  06-JAN-2013
•  significant rework
•  top process monitoring
•  individual disk monitoring
v2.1.0  28-JAN-2012
•  migrate to WASD WebSocket library
v2.0.0  23-OCT-2010
•  add network and process data
•  add cluster statistics
•  add lock waits to lock display
•  page file is now shown by hovering over memory
•  data are now displayed in more meaningful units
•  support for in-development WASD WebSocket
v1.0.1  13-DEC-2008
•  CollectRMI() allow for 7.3-1 and earlier (sigh!)
v1.0.0  29-NOV-2008
•  initial

Acknowlegements