The status script displays a summary of the state of the Appian engines and associated other services as well as a list of any active alerts.
Run this script periodically in order to monitor the state of the Appian engines.
<APPIAN_HOME>/services/bin/status.sh (.bat)
Short Name | Long Name | Required | Meaning |
---|---|---|---|
-h | --help | No | Show usage information |
-p | --password | Yes | Password for Admin REST API |
-c | --cluster | No | Show status of all nodes in cluster |
-nc | --no-color | No | Turn off colored output |
-wfr | --wait-for-running | No | Wait for all engines in topology to be in RUNNING state with leaders elected |
1
./status.sh -p <password> -c
Below is a listing of the alerts that can be reported by the status script, their possible causes, and likely steps to resolve.
The service manager instance on the specified host is either not running, not responsive, or blocked from network traffic from the host where the status script ran. Restart the down service manager instance or unblock the network connection.
The Kafka broker instance on the specified host is either not running, not responsive, or blocked from network traffic from the host where the status script ran. Restart the down Kafka broker instance or unblock the network connection.
The Zookeeper instance on the specified host is either not running, not responsive, or blocked from network traffic from the host where the status script ran. Restart the down Zookeeper instance or unblock the network connection.
Every Appian engine needs an instance in a PRIMARY
state in order to service requests from the rest of the application. If there is no instance in a PRIMARY
state, either start an instance if none are running or make sure that the other components of the system, like Kafka and Zookeeper, are up and running as well.
When checkpoints take a long time to complete, the likely causes are either very slow disk I/O speeds or other resource constraints like CPU utilization.
Running for a long time without checkpointing leaves the system at increased risk in the case of a disaster recovery scenario. Run the checkpoint script and make sure the checkpoint completes. If the checkpoint fails, confirm that the /services/data/temporary/
, /services/data/archived/
, and /server/**/gw1/
directories are writable by the user Appian is running as.
Running for a long time without checkpointing leaves the system at increased risk in the case of a disaster recovery scenario. Run the checkpoint script and make sure the checkpoint completes. If the checkpoint fails, confirm that the /services/data/temporary/
, /services/data/archived/
, and /server/**/gw1/
directories are writable by the user Appian is running as.
Running for a long time without checkpointing leaves the system at increased risk in the case of a disaster recovery scenario. Run the checkpoint script and make sure the checkpoint completes. If the checkpoint fails, confirm that the /services/data/temporary/
, /services/data/archived/
, and /server/**/gw1/
directories are writable by the user Appian is running as.
The load metric is measure of how much process data each execution engine contains. When the amount of process data reaches the configured load metric, new processes will not start on that execution engine anymore. When the MAX_EXEC_ENGINE_LOAD_METRIC is reached, the options are either to delete processes that are running on that execution engine or to increase the configured load metric limit.
Transaction data is not fully replicating throughout the Kafka cluster, leading to an increased risk of data loss in the event of a server failure. Restart all Kafka brokers, one at a time, to force a re-sync.
This alert is only applicable to high-availability configurations.
Transaction data replication between the primary and backup sites has drifted outside of the Recovery Point Objective (RPO). Check logs/service-manager/kafka/mirror-maker.log for more details.
This alert is only applicable to high-availability configurations that are running the Live Backup Procedure.
Status Script