You can use the command line to perform platform administration tasks with the Synthetic Server, such as starting and stopping the services. This page describes the available commands, the log files, and the endpoints for testing the reachability and health of the Synthetic Server. Run the commands from the root directory of the Synthetic Server home.

Start and Stop the Synthetic Server 

Start the Synthetic Server from the root directory of the Synthetic Server home as follows: 

unix/deploy.sh start
BASH

To check if the Synthetic Server services are running and accessible, run the following command and confirm that there is output:

netstat -lan | grep "1[0,2,6]10[1,2]"
BASH

To stop the Synthetic Server:

unix/deploy.sh stop
BASH

Increase the Synthetic Agent Support 

By default, the machine hosting the Synthetic Server should be able to support 100 concurrent Synthetic Agents. To support more than 100 concurrent Synthetic Agents, modify the throttle configuring for the Synthetic Shepherd and Synthetic Scheduler. The default maximum number of requests per second is 60. By increasing the maximum number of requests per second, the Synthetic Server can support more Synthetic Agents.

 To increase the maximum number of requests per second that the Synthetic Server can receive: 

  1. Log on to the machine hosting the Synthetic Server.
  2. Change to the root directory of the Synthetic Server home.
  3. Edit the file synthetic-processor/conf/synthetic-shepherd.yml and increase the value for the property maxRequestsPerSecondOverall. In this example configuration, the value is increased to 80.

    throttleConfiguration:
        maxRequestsPerSecondOverall: 80
    TEXT
  4. Edit the file synthetic-processor/conf/synthetic-scheduler.yml and increase the value for the property maxRequestsPerSecondOverall. Again, in this example configuration, the value is increased to 80.

    throttleConfiguration:
        maxRequestsPerSecondOverall: 80
    TEXT
  5. Restart the Synthetic Server:

    unix/deploy.sh stop
    unix/deploy.sh start
    TEXT
  6. You can verify that the settings have been updated by checking the logs for the Synthetic Server you changed:

    cat logs/scheduler/synthetic-scheduler.log | grep -oP -- "maxRequestsPerSecondOverall=\d+"
    cat logs/shepherd/synthetic-shepherd.log | grep -oP -- "maxRequestsPerSecondOverall=\d+"
    BASH
  7. You should also check the health of the Synthetic Server.

Create Preset Health Rules and Dashboards

Once you have monitored the Synthetic Server, run the following command to create the preset health rules and dashboards:

unix/post_deploy.sh
BASH

See Create Preset Dashboards and Health Rules to learn more about the preset health rules and dashboards.

Upgrade the Synthetic Server

You can update the Synthetic Server and the database schema without uninstalling and reinstalling the Synthetic Server using the update command. See Upgrade the Synthetic Server for instructions.

Check the Health of the Synthetic Server

To check if the Synthetic Server is running, you can run the following. You should receive the response pong.

curl <on-prem-synthetic_server_url>:10102/ping
curl <on-prem-synthetic_server_url>:12102/ping
curl <on-prem-synthetic_server_url>:16102/ping
BASH

To check the health of the Synthetic Server:

curl <on-prem-synthetic_server_url>:10102/healthcheck?pretty=true
curl <on-prem-synthetic_server_url>:12102/healthcheck?pretty=true
curl <on-prem-synthetic_server_url>:16102/healthcheck?pretty=true
BASH

If the Synthetic Server is healthy, the response should be similar to the following:

curl <on-prem-synthetic_server_url>:10102/healthcheck?pretty=true

{
  "authentication" : {
    "healthy" : true
  },
  "deadlocks" : {
    "healthy" : true
  },
  "httpClient" : {
    "healthy" : true
  },
  "quartzScheduler" : {
    "healthy" : true
  }
BASH

curl <on-prem-synthetic_server_url>:16102/healthcheck?pretty=true

{
  "deadlocks" : {
    "healthy" : true
  }
BASH

curl <on-prem-synthetic_server_url>:12102/healthcheck?pretty=true

{
  "authentication" : {
    "healthy" : true
  },
  "cluster" : {
    "healthy" : true
  },
  "deadlocks" : {
    "healthy" : true
  },
  "linter" : {
    "healthy" : true
  },
  "quartzSynthBackgroundScheduler" : {
    "healthy" : true
  },
  "quartzSynthJobScheduler" : {
    "healthy" : true
  }
CODE

Log Files for the Synthetic Server

The Synthetic Server creates the following error log files for each service:

  • <installDir>/logs/synthetic-scheduler.err
  • <installDir>/logs/synthetic-shepherd.err
  • <installDir>/logs/synthetic-feeder-client.err

For general (non-error) log files, see the following directories:

  • <installDir>/logs/scheduler
  • <installDir>/logs/shepherd
  • <installDir>/logs/feeder-client

The naming convention for the general log files is <log>-YYYY-MM-DD.log. You will need to set up a policy to archive or delete the general log files to prevent running out of disk space.