The WASD server monitor, HTTPdMon, has been around since the year dot
(plus-one-point-five), that is since late 1995 (v3.0) when it seemed
desirable to have a terminal session for keeping an eye on server resources
and behaviour.

I'd be surprised if any WASD site has not seen and used the utility.  It is
designed for an 80x24 terminal.  There were still plenty of VTs in use in
those days of yore, and my eyes couldn't, even then, cope with 132x on such a
narrow CRT.  This also explains why WASD code is constrained to 80x.

  https://wasd.vsm.com.au/wasd_root/wasdoc/features/#httpdmonitor

There are four main sections; 1) server process data, 2+3) request processing
data, 4) most recent request.  Though in the example below you can see a
couple of additional elements that may be unfamiliar; what looks like (and
is) geolocation information against the most recent request host name/IP, and
an instance status line.

| VSMX86:: 1         HTTPDMON v3.1.0 X86          Sunday, 27-AUG-2023 10:55:12
|
| Process: WASD:80  PID: 000009CC  User: HTTP$SERVER  Version: 12.1.3
|      Up: 0 00:56:52.25  CPU: 0 00:00:07.46  Startup: 9  Exit: %X00000001
| Pg.Flts: 1456  Pg.Used: 12%  WsSize: 103280  WsPeak: 40976
|     AST: 1988/2000  BIO: 1992/2000  BYT: 4875392/4875392  DIO: 997/1000
|     ENQ:  465/500   FIL:  292/300   PRC:     100/100       TQ:  98/100
|
| Request: 11709  Current: 0/0/0/0  Throttle: 0/0/0%  Peak: 17/9
|  HTTP/2: 450/4%  /1.n: 11259/96%  SSL: 9480/81%  WS: 0/0%  Busy: 0
| CONNECT: 15  GET: 11374  HEAD: 9  POST: 219  PUT: 0  (3)
|   Admin: 165  Cache: 258/841/0  DECnet: 0/0  Dir: 902
|     DCL: CGI:168 CGIplus:6838/6076 RTE:0/0 Prc:857/0 Prct:9
|    File: 2193/8  Proxy: 0  Put: 215  SSI: 7  WebDAV: 0/0
|
|     0xx: 1  2xx: 9470  3xx: 26  4xx: 2228 (403:305)  5xx: 47
|      Rx: 18,821,629 (0 err) Tx: 802,876,133 (0 err) (248kB/s)
|
|    Time: 27 10:52:35  Status: 403  Rx: 533  Tx: 941  Dur: 0.0s
| Service: http://vsmx86.vsm.com.au:80         HTTP/1.1 (0B/s)
|    Host: 45.88.90.144 {United States, Virginia, Ashburn}
| Request: POST /boaform/admin/formLogin
|
|  Instance         Ago   Up Count Exit Status     Version /Min  /Hour
|  VSMX86::WASD:80  11s  56m     9  57m %X00000001  12.1.3    0     19

The server process data are generated directly by the utility using the
process PID and $GETJPI.  The request processing and most recent request data
are read from the global common as populated by the server.

Where a system is running multiple instances (see below) the HTTPdMon display
shows the number of instances adjacent the node name (top-left, in this case
1), and switches between them at each refresh, the process data, request
processing and recent request reflecting each of the instances in turn, the
'Process:' name indicating the current.

The geolocation data is an optional feature not provided by the standard
HTTPdMon.  Three levels are displayed, essentially {country, region, city}
(or something resembling those).  It is optional as it is based on a
free-to-use but traffic-limited service provided by http://ip-api.com/.
YMMV so use at your own discretion.  Also optional because the service may be
withdrawn or otherwise change at any time.  I find it useful to easily see
the origin of certain requests.  The functionality is provided by

  https://wasd.vsm.com.au/wasd_root/src/utils/geolocate.c

and enabled by linking with the GEOLOCATE object module.

  $ SET DEFAULT WASD_ROOT:[SRC.UTILS]
  $ @BUILD_HTTPDMON_GEOLOCATE LINK

There is also a QdLogStats that incorporates geolocation, and a standalone
GEOLOCATE utility that can provide geolocation data as DCL symbols, for use
in DCL-mediated scripting.

  https://wasd.vsm.com.au/wasd_root/src/utils/

The other perhaps novel element of the example is what is termed the status
display.  On systems running multiple instances

  https://wasd.vsm.com.au/wasd_root/wasdoc/features/features008.html

or a cluster of systems running WASD instances, it provides a continuous,
near-real-time indication of the processing status of each WASD process. 
There are 80x and 132x versions of the data.  The fields are explained in

  https://wasd.vsm.com.au/wasd_root/wasdoc/features/#status

and won't be repeated here.  The intent of this facility is to allow a larger
WASD site to be readily assessed, basically at a glance.  For a single
instance running on a single system the above display can be added by the
HTTPdMon /STATUS qualifier.  Obviously requires more than the x24 lines of a
standard terminal.

As noted in the documentation above, the same status information is available
using HTTPD/DO=STATUS and when multiple instances on a node or across a
cluster are automatically displayed in a panel at the bottom of the Server
Administration report.

  https://wasd.vsm.com.au/wasd_root/wasdoc/features/#serveradministration

Implementation Note:  Each instance generates its own unique status data,
folds these into a 64 byte value block of a lock, and in clusters distributes
this using the DLM to every other instance once per minute.  For multi-
instance single systems it avoids using the DLM entirely.  In this way every
instance has a complete picture of every other instance at that point in time
and even if a complete system in a cluster goes away (shutdown or crash)
other instances will retain and display the last data update.

This item is one of a collection at
https://wasd.vsm.com.au/other/#occasional