Remote Monitoring Remote Server Monitoring

Ping Time is the actual time (in milliseconds) spent on the server for processing a very small query. It is thus a good indicator for the responsiveness of the system. Response Time is the elapsed time until the client received the response.

Configuration

To monitor remote eXist-db instances, edit the XML file instances.xml in the root collection of the monex application. Monex pings each server at configurable times or intervals. You can also set up email alerts in notifications.xml.

The configuration for monitoring a remote instance looks as follows:

<instance name="my.server.com" url="http://my.server.com" token="0ade4ba1-cebb-4085-b12c-0ef87f6f032b" cron="0 0/5 * * * ?">
    <poll cron="0 0/2 * * * ?" store="true">
        <alert name="More than 40 threads waiting for locks to be released" condition="count($jmx//LockManager/WaitingThreads/row) &gt; 40"/>
    </poll>
</instance>

Vector alerts (eXist 7+)

Monex polls c=vector automatically, so snapshot XML includes VectorStore and (when the extension is loaded) VectorEmbedding. Alert conditions are XPath expressions evaluated with $jmx bound to the poll response root; elements use the JMX namespace implicitly (write VectorStore/EntryCount, not jmx:VectorStore).

<!-- Embedding models configured but none ready (missing ONNX, unreachable HTTP model, etc.) -->
<alert name="Vector models configured but none ready"
       condition="exists($jmx//VectorEmbedding) and number(($jmx//VectorEmbedding/ReadyModelCount)[1]) = 0 and number(($jmx//VectorEmbedding/ModelCount)[1]) &gt; 0"/>

<!-- Vector store entry count exceeds threshold (only when EntryCountKnown is true) -->
<alert name="Vector store entries above 100k"
       condition="string(($jmx//VectorStore/EntryCountKnown)[1]) = 'true' and number(($jmx//VectorStore/EntryCount)[1]) &gt; 100000"/>

<!-- vector.dbx DATA cache pages nearly full -->
<alert name="vector.dbx DATA cache above 90%"
       condition="let $c := ($jmx//Cache[contains(@name, 'name=vector.dbx,cache-type=DATA')])[1] return exists($c) and number($c/Size) gt 0 and (number($c/Used) div number($c/Size)) gt 0.9"/>

Adjust numeric thresholds to match your deployment. When the vector extension is absent, VectorEmbedding is omitted and the first alert stays silent; VectorStore may still be present from exist-core.

The attributes of <instance> are:

name	a name for the server used for display
url	the base URL to connect to. /status is appended to this URL and should point to the JMX servlet.
token	the unique JMX token required to connect to the JMX servlet. This token is generated for every server and can be found in the file jmxservlet.token inside the data directory of the eXist instance. Note: eXist versions before 2.2 do not use this mechanism, so no token is required.
cron	a valid cron expression which defines the intervals at which the server will be pinged.

There are two types of checks which can be performed:

1. is the server responsive? This sends a "ping" to the server and tries to evaluate a very basic query
2. if polling is defined, monex additionally retrieves JMX diagnostics and checks each alert against the data returned. Optionally the polled JMX data is stored and can be analysed over time.

The frequency of both types of checks is configured via a cron expression. The responsiveness check is always done, even if no alerts are defined. Its interval is configured by the cron expression given in the <instance> element.

Alerts are processed in a separate request, whose frequency is determined by the cron attribute attached to the <poll> element. The checks proceed as follows:

1. retrieve JMX diagnostics in XML by calling url/status
2. process each alert in sequence by evaluating its XPath expression. The root of the JMX document is referenced by variable $jmx
3. if the effective binary value of the evaluated XPath expression is true, the alert fires and a notification is sent to registered users. The JMX output will be attached to the email for analysis by the administrator.