Logs
Logs¶
The log messages generated by the different tasks running on an application
container can be accessed via the log command:
1 2 3 4 5 6 7 8 9 | # display all messages from all log files
$ symfony log all
# display the messages of a specific log file
# (the argument is the name of the log file without the '.log' extension)
$ symfony log error
# display the messages of several log files
$ symfony log app error
|
As explained in the next sections, the exact log files available depend on the application container in use. Log rotation is not enabled by default, but each log file is limited to 10 MB in size automatically because log files are counted towards your disk quota (if a log file reaches that size limit, older messages are discarded).
Caution
Only files managed by SymfonyCloud in /var/log (not to be confused with
/app/var/log) are trimmed this way. Every other log files must be managed
by the user.
Tip
In addition to the log command, log files are also accessible via SSH
in the /var/log directory of the application container.
Note
Although the /var/log directory is writable, it should not be written
to directly. Only write to it via standard logging mechanisms, such as your
application’s logging facility.
Deployment Logs¶
deploy.log¶
The deploy log contains the output of the most recent runs of the
deploy hook for the container. If there is no deploy
hook then this file will be absent.
post_deploy.log¶
The post_deploy log contains the output of the most recent runs of the
post_deploy hook for the container. If there is no
post_deploy hook then this file will be absent.
Application Logs¶
app.log¶
Any log messages generated by the application will be sent to this file. That
includes language errors such as PHP Errors, Warnings, and Notices, as well as
uncaught exceptions. It also contains your application logs if you log on
stderr.
Because SymfonyCloud manages this file for you (preventing disks to get filled
and using very fast local drives instead of slower network disk), we recommend
that applications always output their log to stderr.
Note
For developers convenience and for historical reasons, Monolog default recipe continues to log directly into files. Don’t forget to update its configuration to match our recommendations:
1 2 3 4 5 6 7 8 9 10 11 | --- a/config/packages/prod/monolog.yaml
+++ b/config/packages/prod/monolog.yaml
@@ -11,7 +11,7 @@ monolog:
members: [nested, buffer]
nested:
type: stream
- path: "%kernel.logs_dir%/%kernel.environment%.log"
+ path: php://stderr
level: debug
buffer:
type: buffer
|
If you log deprecations, don’t forget to log them on stderr as
well.
Tip
When running a Symfony application, the log command also gives access to
the log files stored under /app/app/logs/*.log, /app/var/logs/*.log,
and /app/var/log/*.log:
1 2 | # tail on /app/app/logs/prod.log
$ symfony log prod
|
cron.log¶
The cron log contains the output of all recent executions of
cron jobs. If there is no cron hook specified in the
container configuration or if no cron has been executed yet, then this file will
be absent.
php.access.log¶
On a PHP container, the php.access contains a record of all requests to the
PHP service.
Nginx Logs¶
access.log¶
This is the raw access log for the nginx instance running on the application container. That is, it does not include any requests that return a redirect or cache hit from the router.
error.log¶
Nginx-level errors that occur once nginx has fully started will be recorded
here. This will include HTTP 500 errors for missing directories, file types
that are excluded based on the .symfony.cloud.yaml file, etc.
nginx/error.log¶
Nginx startup log messages will be recorded in this file. It rarely happens except when debugging possible nginx configuration errors.
This work, including the code samples, is licensed under a Creative Commons BY-SA 3.0 license.