Remote Monitoring Remote Server Monitoring

  1. Home
  2. Remote Monitoring
Status Server Ping Time Response Time Message
No monitoring jobs configured.
Waiting
Alert! Remote monitoring requires eXist's scheduler module to be enabled. See extensions/build.properties and conf.xml.

Information

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>

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.