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
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/mondesiAlternatively, 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. These checkboxes can be configured using the request query string; see below. 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.
|
http://wasd.vsm.com.au/wasd/
$ SET DEFAULT WASD_ROOT:[SRC]
$ UNZIP <location>:MONDESInnn.ZIP $ UNZIP <location>:MONDESInnn-<platform>.ZIP
$ SET DEFAULT [.MONDESI] $ @BUILD_MONDESI LINK
$ COPY [.OBJ_<platform>]MONDESI.EXE CGI_EXE:
OSU requires use of the MONDESI.COM wrapper procedure.
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.
Display checkboxes can be configured by the request query string (see Usage) with default values configured using the logical name MONDESI_QUERY. A request keyword overrides any equivalent found in the logical name value. For example the following definition ensures a history display is enabled unless overriden by a request ?history=0.
$ DEFINE /SYSTEM MONDESI_QUERY "history=1&disk=1"
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
$ INSTALL ADDMONDESI.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?