AppDynamics switched from Semantic Versioning to Calendar Versioning starting in February 2020 for some agents and March 2020 for the entire product suite.


    Skip to end of metadata
    Go to start of metadata

    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

    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]"

    To stop the Synthetic Server:

    unix/deploy.sh stop

    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
    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
    5. Restart the Synthetic Server:

      unix/deploy.sh stop
      unix/deploy.sh start
    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+"
    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

    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

    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

    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
      }
    curl <on-prem-synthetic_server_url>:16102/healthcheck?pretty=true
    {
      "deadlocks" : {
        "healthy" : true
      }
    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
      }

    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.

    • No labels