When debugging PHP applications running behind Nginx with PHP-FPM, you might notice that some log entries appear truncated. This typically happens with:

  
Stack traces
  
Complex error messages
  
Var_dump() outputs
  
Long SQL queries



The solution requires adjusting both Nginx and PHP-FPM configurations:

1. Nginx FastCGI Configuration
Add or modify these parameters in your nginx.conf or virtual host configuration:
fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;
fastcgi_max_temp_file_size 0;
fastcgi_param PHP_VALUE "log_errors=On \n error_log=/var/log/php_errors.log";

2. PHP-FPM Configuration
In your php-fpm.conf or pool.d/www.conf:
[www]
catch_workers_output = yes
php_admin_value[error_log] = /var/log/php-fpm.log
php_admin_value[log_errors] = on

For systems using syslog or journald:
# For rsyslog
$MaxMessageSize 64k

# For journald
Storage=persistent
SystemMaxUse=1G

Here's a complete working example for an Ubuntu server:
# /etc/nginx/nginx.conf
http {
    fastcgi_buffers 16 16k;
    fastcgi_buffer_size 32k;
    
    # Virtual host configuration
    server {
        location ~ \.php$ {
            fastcgi_param PHP_VALUE "error_log=/var/log/nginx/php_errors.log";
            include fastcgi_params;
        }
    }
}

# /etc/php/8.1/fpm/pool.d/www.conf
[www]
catch_workers_output = yes
php_admin_value[error_log] = /var/log/php-fpm.log
php_admin_value[log_errors] = on

Create a test PHP script to verify:
<?php
// Generate a long error message
$long_string = str_repeat('x', 50000);
error_log("Testing long log message: " . $long_string);
?>

Check your logs to confirm the complete message appears.
While increasing buffer sizes solves truncation, be mindful of:

Memory usage (especially with many concurrent requests)
Disk space for log files
Log rotation configurations



When debugging complex PHP applications, I recently encountered an issue where error logs were mysteriously cut off mid-message. This became particularly noticeable when logging:

// Example of a long log entry that gets truncated
error_log("User ID: 12345 | Transaction: 7890 | Data: " . json_encode($largeArray) . " | Trace: " . print_r(debug_backtrace(), true));

After thorough investigation, I discovered this truncation happens at two potential levels:

PHP-FPM: Has a buffer limit for error_log() output
Nginx: Limits FastCGI response buffer sizes

Here's how to adjust both components:
PHP-FPM Configuration
Edit your php-fpm.conf or pool.d/www.conf:

; Increase buffer size for error logs
php_admin_value[error_log] = /var/log/php-fpm/error.log
php_admin_value[log_errors_max_len] = 8192  ; Default is 1024

Nginx Configuration
In your nginx.conf or site configuration:

http {
    fastcgi_buffers 16 16k;
    fastcgi_buffer_size 32k;
    fastcgi_temp_file_write_size 64k;
    
    # For access logs specifically
    log_format extended '$remote_addr - $remote_user [$time_local] '
                       '"$request" $status $body_bytes_sent '
                       '"$http_referer" "$http_user_agent" '
                       '$request_length $bytes_sent $request_time';
    access_log /var/log/nginx/access.log extended buffer=64k;
}

Create a test script to verify:

<?php
// Generate a log message exceeding typical limits
$longMessage = str_repeat("Testing log length ", 500);
error_log($longMessage);
?>

After making these changes, restart both services:

sudo systemctl restart php-fpm
sudo systemctl restart nginx

For extremely verbose logging needs, consider:

Implementing log rotation more frequently
Using structured logging with tools like Monolog
Logging to separate files based on severity

While increasing these limits solves truncation, be mindful of:

Disk I/O overhead from larger log entries
Memory usage for buffering
Log rotation and storage requirements