Skip to main content

Frequently Asked Questions

Get answers to your log questions.


This section provides answers to frequently asked questions about log files.

How can I parse my Nginx access logs?

Refer to Parsing nginx Access Logs with GoAccess for more information.

What is the first line in nginx-access.log?

The first entry reflects an internal IP address of Pantheon's routing layer. The last entry provides a list of IPs used to serve the request, starting with the client IP and ending with internal IPs from the routing layer. For environments with HTTPS enabled, the load balancer IP address will be listed second, after the client IP.

The client IP for the following example is 122.248.101.126:

203.0.113.56 - - [19/Feb/2016:02:00:00 +0000]  "GET /edu HTTP/1.1" 200 13142 "https://pantheon.io/agencies/pantheon-for-agencies" "Mozilla/5.0 (Windows NT 6.3; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0" 0.399 "122.248.101.126, 50.57.202.75, 10.x.x.x, 10.x.x.x"

Can I log to the system logger and access syslog?

No, syslog is unavailable. Technically, you can log Drupal events using the syslog module, but you won't be able to read or access them. You can use the error_log function to log to the php-error.log, which is accessible in the logs directory.

Can I access Apache Solr logs?

No, access to Apache Solr logs is unavailable. Refer to the documentation on Pantheon Search for more information on debugging Solr.

Can I download Varnish logs?

No, Varnish logs are unavailable for download.

How do I enable error logging for WordPress?

Warning:
Warning

The steps in this section enable debug logging. Debug logging increases resource overhead and presents a security risk. It is not recommended for production environments.

Disable debug logging when you are done to minimize risk exposure, especially in a Live environment.

Enable the WP_DEBUG and WP_DEBUG_LOG constants on Development environments (Dev and Multidevs) to write errors to wp-content/uploads/debug.log and show all PHP errors, notices, and warnings on the page. We suggest setting the WordPress debugging constants per environment in wp-config.php:

wp-config.php
// All Pantheon Environments.
if (defined('PANTHEON_ENVIRONMENT')) {
  // Turns on WordPress debug settings in development and multidev environments, and disables in test and live.
  if (!in_array(PANTHEON_ENVIRONMENT, array('test', 'live'))) {
    // Debugging enabled.
    if (!defined('WP_DEBUG')) {
      define( 'WP_DEBUG', true );
    }
    if (!defined('WP_DISABLE_FATAL_ERROR_HANDLER')) {
      define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true ); // 5.2 and later
    }
   if (!defined('WP_DEBUG_DISPLAY')) {
      define( 'WP_DEBUG_DISPLAY', true ); // requires WP_DISABLE_FATAL_ERROR_HANDLER set to true
    }
    define( 'WP_DEBUG_LOG', __DIR__ . '/wp-content/uploads/debug.log' ); // Moves the log file to a location writable while in git mode. Only works in WP 5.1
  }
  // WordPress debug settings in Test and Live environments.
  else {
    // Debugging disabled.
    ini_set( 'log_errors','Off');
    ini_set( 'display_errors','Off');
    ini_set( 'error_reporting', E_ALL );
    define( 'WP_DEBUG', false);
    define( 'WP_DEBUG_LOG', false);
    define( 'WP_DISABLE_FATAL_ERROR_HANDLER', false );
    define( 'WP_DEBUG_DISPLAY', false);
  }
}

By default, the WordPress debug log path is set to /wp-content/ and is not writable on Test or Live environments. This can be overridden to the /wp-content/uploads/ folder.

How can I access the Drupal event log?

Drupal logs events with the Database Logging module (dblog) by default. PHP fatal errors can sometimes be found in these logs, depending on how much Drupal bootstrapped. You can access the event logs in a couple ways:

  • Visit /admin/reports/dblog after you've logged in as administrator.

  • Use Terminus:

    terminus drush <site>.<env> -- watchdog-show
  • Terminus can invoke Drush commands to "watch" events in real-time; --tail can be used to continuously show new watchdog messages until interrupted (Control+C).

    terminus drush <site>.<env> -- watchdog-show --tail

My Drupal database logs are huge. Should I disable dblog?

We do not recommend disabling dblog. The best practice is to find and resolve the problems. PHP notices, warnings, and errors mean more work for PHP, the database, and your site. If your logs are filling up with PHP messages, find and eliminate the root cause of the problems. This will make your site faster.

Refer to PHP Errors and Exceptions for more information.

How do I access logs in environments with multiple containers?

You can use the shell script to download the logs from each application container. Application container numbers by plan are listed below:

Basic and Performance sites on paid plans:

  • Live environment: 1 main container and 1 failover container with logs

Performance Medium plans and above:

  • Live environment: multiple containers with logs
  • Test environment: multiple containers with logs

Can I tail server logs?

Not directly. You can download your logs locally using SFTP and then review the logs with any tool on your workstation.

You can also create the logwatcher.sh script below, which uses Terminus and the Terminus Rsync Plugin to download log files and display the last several lines.

  1. Create a logs directory in the local Git repository for each log you want to watch if you're working on multiple projects locally.

  2. Add logs/* to the project's .gitignore file.

  3. Navigate to your project's logs directory and create logwatcher.sh:

    logwatcher.sh
    #!/bin/bash
    export TERMINUS_HIDE_UPDATE_MESSAGE=1
    
    LOGPATH=~/projects/mysite/logs/
    LOGFILE=php-error.log
    SITE=sitename
    ENV=environment
    
    touch $LOGPATH/$LOGFILE
    terminus rsync $SITE.$ENV:logs/php/$LOGFILE $LOGPATH
    
    tail $LOGPATH/$LOGFILE
  4. Update the variables:

    • LOGPATH points to the logs directory in your project
    • SITE should match your site name
    • ENV is the environment in which you want to watch logs
  5. Make the script executable:

    chmod +x ~/projects/mysite/logs/logwatcher.sh
  6. Use watch (available on macOS via Homebrew) to keep an updated view of the logs:

    watch -n2 ~/projects/mysite/logs/logwatcher.sh

    Stop the process with CTRL-C.

More Resources