Monitor de Sistema
(español)

Version 7.3.0, 27th September 2023

Copyright © 2008-2023 Mark G. Daniel
Licensed under the Apache License, Version 2.0 (the "License");
https://www.apache.org/licenses/LICENSE-2.0
Software distributed under the License is on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

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!

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. 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.

 (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 16 on macOS 13, 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. Default CPU shows total and then non-USER (S+E+K) times, or if modes checked, individual CPU modes; 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.

single or double height history graphs. With more detail available from the modes data it is often useful to separate further the lines associated with each datum.

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.
opens CPU modes data display and changes CPU history graph from total plus non-USER to display CPU modes. The data display includes a colour coded key for each mode line.


(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 at the bottom of the page, a section containing the most recent OPCOM messages, more recent to less recent, top to bottom.
(when configured) OPCOM includes AUDIT$SERVER messages. For example, login failure.
(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† )

Query String

Each of the above checkboxes may be checked or unchecked using appropriate elements of the request query string. The following keywords can each be checked with a =1 or =X, and unchecked with a =0 or =O. Height and minutes takes an integer value.

Keywords:  alerts=  cluster=  collect=  delta=  disk=  height=[1|2]  history=  minutes=[5|15]  modes=  opcom=  process=  queue=  tips=  update= 

As in the following example which enables history and disk displays, and ensures disk delta is disabled:

http://the.site.name/cgiplus-bin/mondesi?history=1&disk=1&delta=0

Also refer logical name MONDESI_QUERY in Configuration section.

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

Usage

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.

Display checkboxes can be configured by the request query string (see Usage) with default values configured using the logical name MONDESI_QUERY as defined on the system executing MonDeSi. 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 :-).

OPCOM message count is accumulated and displayed with the timestamp of the most recent message adjacent the process counts in the top-left of the page.

OPCOM messages themselves are considered sensitive information and so are not available by default. Display must be explicitly configured, with the checkbox control disabled by default.

There are several ways to enable display of OPCOM messages.

  1. Make the script subject to authorisation.
    If the request contains a non-empty CGI variable REMOTE_USER the request is considered access-controlled and so permitted to view the message log.

  2. Provide a logical name with the first character an asterisk. 
    $ DEFINE /SYSTEM MONDESI_OPCOM *

  3. Permit using Access Control.

By default, all OPCOM message categories are enabled. To restrict the monitor to specific categories, define the logical name to contain the required category/ies using the same syntax as required by the REPLY verb. For example, to enable cluster and network messages, use 

$ DEFINE /SYSTEM MONDESI_OPCOM "*/ENABLE=(CLUSTER,NETWORK)"

and to enable all then explicitly disable security reporting 

$ DEFINE /SYSTEM MONDESI_OPCOM "*/DISABLE=SECURITY"

NOTE: As noted below, to access security-related OPCOM data the executable must be INSTALLed with SECURITY privilege.

Non- WASD WebSocket usage disables OPCOM by default (reasons described in the code). To enable OPCOM for CGI access prefix the MONDESI_OPCOM logical name value with a plus symbol, as in the following example. 

$ DEFINE /SYSTEM MONDESI_OPCOM "+*(CLUSTER,NETWORK)"

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)

OPCOM data requires OPER privilege provided by image INSTALL. 

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

To access security-related OPCOM data it must also have SECURITY privilege. 

$ INSTALL ADD <location>MONDESI.EXE /PRIV=(OPER,SECURITY)

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.

MonDeSi may be proctored into existence. 

# WASD_CONFIG_GLOBAL
[DclScriptProctor]
1 /cgiplus-bin/mondesi /cgiplus-bin/mondesi

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, Opera and Safari – almost) 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",*,*

A fourth value enables similar access-control for viewing OPCOM messages, with the following example providing that for the three usual suspects. 

$ DEFINE /SYSTEM MONDESI_ACCESS "$curly,$larry,$moe",*,*,"$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.

Apache

MonDeSi is a combination of functionality on the server side (the executable script) and client side run-time resources (e.g. JavaScript).

The server-side is CGI and so must be activated as such. The usual mechamism is to copy the MONDESI.EXE image to APACHE$COMMON:[CGI-BIN] and activate it by the browser using the URI /cgi-bin/mondesi

Client-side resources (JavaScript, style sheets, etc.) are requested using the partial URI /mondesi/-/ to which the name of the resource is appended. So the file MONDESI.CSS would be requested from the server using the URI /mondesi/-/mondesi.css

Where should MonDeSi be installed?

General principles are discussed in the Configuration section. For Apache this depends a little on site policy. Some sites put the source kit in with the server root APACHE$COMMON:[000000], or in the node specific equivalent APACHE$SPECIFIC:[000000], and build the executable from there. This section will assume MonDeSi residing in the file-system as APACHE$COMMON:[MONDESI] and the client-side run-time resources in APACHE$COMMON:[MONDESI.RUNTIME].

Of course it is also possible to install and build the kit outside of the Apache file-system root and map those run-time resources into web-space. In either case the resources provided by [.MONDESI.RUNTIME] must have permissions (protections) allowing them to be accessed and served by the Apache account.

In this section the simplest scenario is used as an example with the kit installed and built in the Apache file-system root. 

$ set default apache$common:[000000]
$ unzip location:MONDESInnn.ZIP
$ set default [.mondesi]

MonDeSi server configuration

Two considerations:

  1. Activating the server-side script (either one way or the other)

    • Copy the MONDESI.EXE image into the common or node-specific CGI directory. For example: 

      $ copy [.mondesi.obj_axp]mondesi.exe apache$common:[cgi-bin]

    • Make the install directory executable. For example: 
      <Directory "/apache$commmon/mondesi/obj_axp">
Options +ExecCGI
</Directory>

      Note that with this approach the activation URI is no longer /cgi-bin/mondesi

  2. Providing the client-side run-time resources 

    Alias /mondesi/-/ "/apache$commmon/mondesi/runtime/"

One, final server configuration consideration – Authorisation. As discussed in the Access Control section, restricting use of MonDeSi. There are a plethora of ways to provide or restrict access to a subset of potential users. The simplest is to control access to the server-side CGI script. For example (in the simplest case): 

<Location /cgi-bin/mondesi>
AuthType Basic
AuthName "OpenVMS authentication"
AuthUserOpenVMS On
require valid-user
</Location>

MonDeSi image configuration

Also as discussed in the Configuration section, the CGI executable bering activated must be INSTALLed with privileges appropriate to what is required of it, and some run-time characteristics by defining logical names. As for WASD the example MONDESI_STARTUP.COM can assist with this. It will require some customisation under Apache (e.g. DCL symbol script_location). It must be executed at Apache server startup.

Problems?

Releases
v7.3.0  29-SEP-2023
•  add double height history graph
•  builds with VSI C X7.4-785 (GEM 50X65) on OpenVMS x86_64 V9.2-1
v7.2.0  18-MAR-2023
•  add CPU modes
•  builds with VSI C X7.4-726 (GEM 50X23) on OpenVMS x86_64 V9.2
v7.1.0  25-OCT-2021
•  supports x86-64 VMS — if building Using IA64-hosted X86 Cross-Complier
•  in line with WASD in general, moved to Apache 2.0 license
v7.0.0  08-FEB-2021
•  VAX no longer implemented
•  move to native 64 bit data storage
•  OPCOM monitor
v6.2.2  20-JUL-2019
•  bugfix; WebSockAvailable()
v6.2.1  03-NOV-2018
•  bugfix; query string processing
•  geolocation is now generally pay-for-service and been deprecated
v6.2.0  08-APR-2018
•  allow configuration of checkboxes using request query string
•  logical name MONDESI_QUERY provides default query string
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