About three years ago I wrote about this fantastic tool to view several logs simultaneously, search over them, see them highlighted, etc.
Today I bring you a couple of improvements and I refer you to the previous article to install it and see useful options such as keyboard combinations.
Using multitail remotely
In the previous article we were talking about uses on private servers, but we know that most of our clients’ websites are on standard hosting and we can’t install anything.
By default multitail will not be installed, but what all (or almost all) hostings will have available is tail.
What we will do is to install multitail in our WSL2 (as in my case) or Mac or Linux console, we can all do it.
After that, it will be enough to know where the log files are on the remote hosting and the error logs. If we have properly configured our file config in the directory .ssh we only need to run ssh Nombre-Host in our console to connect, if we enable the certificate
1
.
And we will already be from our console executing multitail that will bring the logs from the remote hosting through the remote tail to our computer.
This, which may seem very geek has been really useful to me in the last few weeks, on the one hand, to stop an attack on a client’s server with several million harmful requests per day (if I had CloudFlare) or to find the solution to some errors in another web site where it was complicated a debug classic and it was necessary to pull error_log.
Let’s see an example of a client’s website that I have configured in the SSH config file as Lucushost-Client1 (with hosting at LucusHost, of course):
multitail -cS ols -l 'ssh Lucus-Cliente1 "tail -f ~/access-logs/cliente1.com-ssl_log"'With this we will see the https log file that is saved in the user’s path, folder access-logs (although it is a symbolic link) and log with the domain name -ssl_log (without this termination for http access).
The error log is at ~/www/error_log, that is, in the root of your WordPress installation, so to see it we will put:
multitail -cS ols_error -l 'ssh Lucus-Cliente1 "tail -f ~/www/error_log"'
But in addition to viewing logs in real time, the ideal is to view both simultaneously (or more if we want, even from different hostings on the same screen).
multitail -wh 20 -cS ols_error -l 'ssh Lucus-Cliente1 "tail -f ~/www/error_log"' -cS ols -l 'ssh Lucus-Cliente1 "tail -f ~/access-logs/cliente1.com-ssl_log"'With this command we connect in the upper window to the error log with 20 lines and the rest of the screen for the access log.
As you can see, we can easily change the size of each log screen, where we connect to, etc.
Color Logs
In the previous examples we saw after the multitail command -cS ols which corresponds to:
-cdisplay logs with color.Suse a color scheme.olsthe color scheme to be used (Open Lite Speed in this case, own color scheme).
Unlike what I said in the article two years ago, which proposed to modify the configuration file in /etc/multitail.conf (which is totally valid and correct), now I prefer to manage it in a file inside the user directory, a dotfile.
The .multitailrc file is the one we will use in our profile to add or modify multitail configuration options.
In my dotfile repository and bash, zsh and WSL2 utilities, you can access my .multitailrc where I have configured the color schemes for Nginx(nginx) and Nginx Errors(nginx_error), as well as Open Lite Speed(ols) and Open Lite Speed errors(ols_error).
In this way, instead of modifying the configuration files, all changes are focused on these configuration files for each user, the dotfiles. 2 .
All dotfiles in my profile are symbolic links to the corresponding ones in the repository, which I sync between desktop and laptop, and any improvements in one are propagated to both or to any new installation.
