The “Log” command allows you to visualize logs in real time generated as a history of the various events on our server, either by the access of visitors to the pages of the hosted sites or by the different tools that are executed internally.
Whether you want to debug an error, monitor an application or tool (php, mail, mysql, etc) or simply detect a visitor, bot, etc., among other applications, it is important to have this tool to do it easily, quickly and in real time.
sudo log <domain> <option>
# Enable WP Debug mode sudo log example.com -wp=on # Enable access log sudo log example.com -only-error=off # See your logs in real-time sudo log example.com
Use Ctrl+C to exit or end.
Nginx Access Logs
By default, the Nginx Access logs are disabled.
To activate the general access log and apply to all the new sites created after this.
sudo log -only-error=off
To activate the log of a particular site.
sudo log example.com -only-error=off
We can deactivate it again using the
Webinoly has native integration with Datadog
Modern Log Management & Analytics.
Search and analyze your logs at any scale, on any budget.
Datadog Log Management unifies logs, metrics, and traces in a single view, giving you rich context for analyzing log data. Whether you’re troubleshooting issues, optimizing performance, or investigating security threats.
How can I view my website access log?
To view the log for a particular site:
sudo log example.com
To view the access log of all websites hosted on my server:
The above options only show the access event log, but omit the “error” events.
How can I view the error log?
For example, we might want to see the “warning” or “error” of our WordPress site generated by PHP during the execution of a particular page.
sudo log example.com -error
Similarly, if we wanted to see the error log generated by all the sites hosted on the server, we use the following command:
sudo log -error
* You can change the number of lines that the output of log command will show, by default is 10. You can always add the -lines argument to any
sudo log example.com -lines=25 or for a more permanent solution, you can modify this value directly in the Webinoly configuration file using
When we have configured the Debug mode in WordPress in
debug.log file, usually located in
To view in
sudo log example.com -wp
Also, we have an option to enable/disable (on/off) the WordPress debug mode on any of your sites:
sudo log example.com -wp=on
WordPress debug mode have an option to show the debug messages inside HTML pages and is enabled by default. To disable this feature and only send the debug messages to the log-file:
sudo log example.com -wp=on -display=off
Also, you can set the WordPress Environment Type from here:
sudo log example.com -wp=on -env=development.
How can I see the log generated by an application or tool?
Webinoly supports the visualization of events generated by PHP, MySQL, mail,
sudo log -php
sudo log -ssh
sudo log -mail
sudo log -syslog
sudo log -le
-php options are equivalent and
-le is for “Let’s Encrypt”.
The error log is always enabled.
sudo log -mysql=error
* On servers created before v1.11.0 all MySQL logs are sent to Syslog, which is the default MySQL configuration, since this version we have changed this to have an individual file.
The general log includes all queries and is very useful for debugging or auditing queries.
sudo log -mysql=general sudo log -mysql=general -enable sudo log -mysql=general -disable
The slow query log includes all queries that
-long-query-time (default is 10s) to run and is very useful to find queries that
sudo log -mysql=slow sudo log -mysql=slow -enable sudo log -mysql=slow -enable -long-query-time=3 sudo log -mysql=slow -disable
Binary log is mainly used by replication.
sudo log -mysql=binary sudo log -mysql=binary -enable sudo log -mysql=binary -disable
Purge log files
Permanently remove all files with the GZ extension (rotated logs) from the
sudo log -purge
-purge=force option to skip questions.
Also, you can remove the log files from a specific package (nginx, letsencrypt, mysql, redis, all, force):
sudo log -purge=nginx
Personal advice: If your disk space is so small that archived logs are too much to handle, get a bigger server.
If you have any suggestions, ideas, or comments, or if you (gasp!) found a bug, join us in the Community Forum.