The platform log files include the following:

  • platform-admin-server.log: Information about events of the install process such as extraction, preparation, and other post-processing tasks. It is located at <platform_admin_home>/logs.
  • server.log: Information for the embedded Glassfish application server used by the Controller. It is located at <controller_home>/logs.
  • audit.log: Information about Account/User/Group/Role CRUD/User login/logout/SSH connections, and all other operations. This can be used to forward auditable events from the Controller into a central log management system or SIEM. It is located at <controller_home>/logs, and replicates the Controller Audit Report. 
  • database.log: Information for the MySQL database that is used by the Controller. It is located at <controller_home>/db/logs.
  • startAS.log: Output generated by the underlying Glassfish domain for the Controller.
  • orcha-modules.log: Information about all the tasks and commands that are run during installation. platform-admin-server.log has high-level information about the task executed. However, orcha-modules.log has more information on the specific command and output. It is located at <platform-dir>/orcha/<version>/orcha-modules/logs/orcha-modules.log.

Retrieve Log Files

You can use the Enterprise Console to retrieve log files for the Controller and Events Service. On the Controller or Events Service page, expand More options and click Retrieve Log to start a Retrieve Log job. When the job has successfully completed, it will retrieve and save the Controller or Events Service log files, which include AppServer, Reports Service, and DB logs, as a zip file to /home/appdynamics/appdynamics/platform/platform-admin on the Enterprise Console host.

You can also run the following command on the Enterprise Console host:

bin/platform-admin.sh submit-job --service <controller or events-service> --job retrieve-log --platform-name <name_of_the_platform>

Manage Log Files

You can manage your log files by setting up log rotation and adjusting the retention periods.

Log Rotation

The application server is preconfigured to rotate the server.log file regularly, based on settings in the domain configuration file. On Windows, there is an additional log file for Glassfish service launcher that needs to be rotated.

For the other log files, such as database.log or audit.log, you may need to set up log rotation to prevent them from consuming excessive disk space. The audit.log file, in particular, may grow quickly because it contains SSH connections to Controller and Event Services hosts that occur every minute. You also need to set up log rotation for an additional log file, <controller_home>/db/data/slow.log. This log contains information about slow MySQL queries.

The tool you use to perform the rotation depends on your operating system. On Linux, you can use the mysql-log-rotate script. The script is included with the Controller database installation at <controller_home>/db/support-files. You need to modify the script for your environment since it is not set up to rotate the database.log file by default. On other systems, you need to create or install a script that performs log rotation and make sure that it get run regularly, for example, by cron or an equivalent task scheduler.

Retention Period

Enterprise Console logs in platfom-admin/logs are automatically archived in a .gz format with a date-time stamp after they grow too large. The size of each archived log is around 300 KB. Only the latest seven files are archived in the logs directory.

If you want to retain the archived logs for longer periods of time, you can configure the settings in the Dropwizard configuration file, PlatformAdminApplication.yml. Under the logging/appenders/type: file section, you need to specify a larger archivedFileCount, as well as maxFileSize. See the Dropwizard Configuration Reference for more information.

Change the Default Location or Names of the Controller Logs

  1. Set the new location for start.ini by editing the following property:

    -Dcom.appdynamics.controller.logs.dir=<New log location>

     If you specify a directory that does not exist, it is created when you restart the application server.

  2. Change the database.log location by opening the <controller_home>/db/db.cnf file. You can also change the db.cnf file from the Enterprise Console GUI Database Configurations page. Doing so also restarts the database server.

    The Enterprise Console takes a backup when you modify these configurations.

  3. Set the value of the log-error property to the new location of the database.log file. This directory location must exist before you restart the Controller or you will get start-up errors

  4. Copy if desired any existing logs from the default directory (<controller_home>/logs) to the new location.

  5. Restart the Controller. See Start or Stop the Controller.

  6. Verify that the server.log files are being written to the new location and remove the old log files. The database.log location is <controller_home>/db/logs/database.log.

Log Level Granularity

The Controller logs provide information about possible errors in Controller operations. By default, the Controller writes to the log at the INFO level. When debugging your Controller deployment, you may need to increase the logging level to generate additional information.

You can set the logging level by Controller component, which include:

  • Agents
  • Business Transactions (BTS)
  • Events
  • Incidents
  • Information Points (IPS)
  • Metrics
  • Orchestration
  • Rules
  • Snapshots

Change Default Logging Level by Component

By default, the Controller generates logs at the INFO level. You can change the level for one or all of the components. This may be needed, for example, when you are debugging your system, and want the Controller to generate more information in the form of logs. On the other hand, you may wish to reduce logging verbosity to minimize the reduce the rate of growth of log files. The following steps describe how to change the default log levels.

  1. Log in to the server where you have deployed the Controller.

  2. Navigate to the <controller_home>/appserver/jetty/resources/logback.xml file.
    By default, the log level changes apply within in few minutes without a restart.

  3. Modify the required loggers and save the file. See, Logback Configuration.
    For example, if you wish to change the com.hibernate logger, update as follows:

    <logger name="com.hibernate" level="DEBUG"/>
    CODE