Monitoring
Available monitoring beans
For monitoring the current status of the server, Xima® Formcycle provides a monitoring bean for each server type. It can be accessed and read via JMX by using tools such as for example JConsole.
The beans are registered under the following names:
- Frontend-Server
- de.xima.fc:type=FSMonitor,qualifier=<contextName>
- Master-Server
- de.xima.fc:type=MSMonitor,qualifier=<contextName>
The context name is the context name of the applications. It is necessary for supporting parallel installations of Xima® Formcycle on a server. By default, the context name is the name of Xima® Formcycle's WAR file, but it can be changed by modifying the context name parameter XFC_CONTEXT_NAME within the web.xml.
When starting the server, the current context name is logged. You may need to modify the logging settings to see the name. There are different monitoring attributes available for each bean, which are listed below.
Attribute | Description | Possible options |
---|---|---|
running | Whether the master server has been started successfully. | true/false |
db_connected | Whether the master server could establish a connection to the database. | true/false |
fs_connected | A map of the names of all frontend servers and whether they are connected to this master server | Key: <serverName> Return value: true/false |
fs_active | A map of the names of all frontend servers and whether this master server should attempt to establish a connection to that server automatically. | Key: <serverName> Return value: true/false |
fs_status | A map of the names of all frontend servers and the connection status of that server. | Key: <serverName> Return values: CONNECTED, NOT_CONNECTED, ERROR, RECONNECTING, DISCONNECTING , CONNECTING, AUTHENTICATING, WAIT_FOR_CONNECTION |
fs_disconnected_count | The number of frontend servers not connected to this master server | A non-negative number |
fs_connected_count | The number of frontend servers connected to this master server | A non-negative number |
failed_login_count | For each login name, the login cache contains how many times a user made a failed login attempt with that login name. This is the number of login names in that cache. | A non-negative number |
connect_frontendserver_by_name | Triggers a connection to the frontend server by name. | Key: <serverName>, true/false to trigger reconnect always (no matter if there is a connection) Return value: true/false |
connect_frontendserver_by_id | Triggers a connection to the frontend server by id. | Key: <serverName>, true/false to trigger reconnect always (no matter if there is a connection) Return value: true/false |
Attribute | Description | Possible options |
---|---|---|
running | Whether the frontend server has been started successfully. | true/false |
connected | Whether this frontend server is connected to a master server. | true/false |
failed_login_count | For each login name, the login cache contains how many times a user made a failed login attempt with that login name. This is the number of login names in that cache. | A non-negative number |
status | The connection status of this frontend server. | CONNECTED, NOT_CONNECTED, ERROR, RECONNECTING, DISCONNECTING, CONNECTING, AUTHENTICATING, WAIT_FOR_CONNECTION |
restart | Triggers a restart of the frontend server. | None |
JSON REST API
The JSON interface has been removed since version 6.0.0 in favor of a separate Jolokia installation. The beans used for monitoring are still available. The JSON interface of the monitoring allowed read-only access and could only be called via the application server (localhost/127.0.0.1). If this is wanted, the access would have to be configured within the Jolokia application, more information can be found here.
A possible call, after installation of Jolokia, looks like the following:
JSON response:
"request": {
"mbean": "de.xima.fc:qualifier=formcycle,type=MSMonitor",
"type": "read"
},
"value": {
"running": true,
"failed_login_count": 0,
"fs_active": {
"localhost": true
},
"db_connected": true,
"fs_connected_count": 1,
"fs_connected": {
"localhost": true
},
"fs_disconnected_count": 0,
"fs_status": {
"localhost": "CONNECTED"
}
},
"timestamp": 1579186291,
"status": 200
}
More information about the integration of the framework Jolokia and a more detailed documentation can be found here.
Nagios integration
The Nagios monitoring application may be used for reading and showing monitoring info as well by using the JSON REST API described above. This requires the Nagios plugin jmx4perl to be installed. A detailed installation instruction can be found on their website. This allows querying the JSON REST API with the corresponding commands.
Examples
Command
command_name check_jmx4perl
command_line check_jmx4perl --url $ARG1$ --mbean $ARG2$ --attribute $ARG3$ $ARG4$
}
Service definitions
define service{
use generic-service
host_name localhost
service_description MS:FS-connected-count
check_command check_jmx4perl!http://localhost/formcycle/monitoring/!de.xima.fc:type=MSMonitor,qualifier=formcycle!fs_disconnected_count!--warning 1 --critical 2
}
Querying the database connection status of the master server
use generic-service
host_name localhost
service_description MS:DB-connected
check_command check_jmx4perl!http://localhost/formcycle/monitoring/!de.xima.fc:type=MSMonitor,qualifier=formcycle!db_connected!--string --critical 'false'
}
Querying whether the frontend server localhost is connected to the master server
use generic-service
host_name localhost
service_description MS:FS-localhost
check_command check_jmx4perl!http://localhost/formcycle/monitoring/!de.xima.fc:type=MSMonitor,qualifier=formcycle!fs_connected!--path=localhost --string --critical 'false'
}
Querying the frontend server whether it is connected to a master server
use generic-service
host_name localhost
service_description FS:connected
check_command check_jmx4perl!http://localhost/frontend-server/monitoring/!de.xima.fc:type=FSMonitor,qualifier=frontend-server!connected!--string --critical 'false'
}
Running Nagios on a different server
For security concerns, the JSON REST API does not allow querying the monitoring info from other IP addresses, only from the local server. Running Nagios on a different server and querying the monitoring info is still possible, but requires some additional setup.
One option is to setup the routing accordingly or using a proxy.
Another options for using Nagios on a different server is by providing certain options to the monitoring servlet. The parameter policyLocation provides the servlet with the URL to a Jolokia policy file, which will be passed on to Jolokia. The monitoring servlet is an extends Jolokia standard servlet and all Jolokia-specific parameters can be used. A list of relevant parameters can be found website.
A third option is running Jolokia in parallel to Xima® Formcycle or the frontend server. Jolokia provides an application with a Java-EE agent for this purpose, documentation and download).
This agent does not possess any restrictions for read operations or control commands. However, as this represents a potential security issue, we strongly recommend to configure this agent for the server and network settings in use and restrict access as much as possible. For example, access should be restricted to the server running the Nagios application.
Jolokia provides more details on security-related options in their documentation.
When Jolokia is run parallel to Xima® Formcycle, the connection to the frontend server localhost must be modified as follows:
use generic-service
host_name fc-test
service_description MS:FS-localhost
check_command check_jmx4perl!http://fc-test/jolokia/!de.xima.fc:type=MSMonitor,qualifier=formcycle!fs_connected!--path=localhost --string --critical 'false'
}