Intro
Hello and welcome back to this introductory tutorial on Nginx. Yesterday we learned about how to use Nginx to act as a reverse proxy, load balancer, then work as a cache for our various assets. Now, we're ready to shift towards handling more of the mundane day to day tasks that come with administering an Nginx server.
To do this, we will just the same proxy server we were working with yesterday and merely adding on to what was already there. Let's get started.
Error Logs
Our first order of business is to handle our error logs. To do this, we will only be
needing to invoke one directive. However, within this directive we will defining both
where our error logs will be stored along with what kind of information we will choose to
store. So let's open up our nginx.conf
file and insert our new directive.
error_log /var/log/nginx/error.log info;
http{
upstream myapi {
server api_ip_address;
server api2_ip_address;
}
...
}
Good, now let's look at what we have just done. First, we have defined the location for where our log files will be stored. Not bad at all. Next we have defined the level of severity for the types of error logs we will store. To better understand what Nginx is doing here. Let's take a look at the list of error categories that we have available.
- debug
- info
- notice
- warn
- error
- crit
- alert
- emerg
This is a list of the error categories that we could have in order of severity. Debug
being the least severe and emerg being the highest severity. The key thing to understand
is that when selecting a lower tier of severity, you are choosing the minimum level of
severe logs that will be displayed in your error log file. So if you choose the info
setting, you will display everything from info
to emerg
. If you choose alert
you
will only display errors categorized as alert
and emerg
. There is no one size fits all
advice as to which level of error you should choose for your needs. It all comes down to
server resources and limitations, traffic, etc. When in production, you may not need to see
every little error that comes out but perhaps only focus on the most important ones that
are directly affecting users and their end goals. Now, let's turn our attention to access
logging.
Access logging
In this case, we'll be configuring our access logs so we can know who is accessing our service along with other relevant information about our visitors. Let's go ahead and write our access log script then we will dissect what is going on within.
error_log /var/log/nginx/error.log info;
log_format main '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" "$gzip_ratio"';
http{
upstream myapi {
server api_ip_address;
server api2_ip_address;
}
location / {
access_log /var/log/nginx/access.log main;
proxy_pass http://myapi
}
}
Let's breakdown what all we have going on here. First we need to look at our log_format
directive. This allows us to name and define how we want our access logs formatted in our
file. In this case we're showing the remote address, remote user, local time that the
request took place, the request status, bytes sent, http referrer, http user agent, then
finally the compression ration we are using via gzip. This can be customized as you see
fit but for now, we will just go with this set up. Now we need to take a look at the
location where we have actually defined our access_log
directive. You'll see here that we
have defined exactly where our access log file goes and you'll also notice that we have
included the name of our log_format
at the end.
It is crucial to also note that this isn't all that we can do for logging. First,
remember that we had defined a compression ratio in our log_format
. Let's enable that
compression right quick in our access_log
.
access_log /var/log/nginx/access.log main gzip=1 flush=10m;
That was easy. Here we have defined our compression ration. The key thing to understand is that 1 will equal the lowest compression but fastest speed. A 9 on the other hand would be the maximum compression and lowest speed. So what you choose will have to come down to your individual needs.
Conclusion
Congratulations, you have made it through this introductory tutorial on Nginx. We have gone over what it is, how it works, how to load static sites, work with dynamic server rendered web apps, act as a reverse proxy/load balancer/cache, and now we have gone over how to configure and monitor our logs. I want to say thank you very much for your diligence in going through this tutorial and I sincerely hope that it has provided some value in your drive to work with Nginx. Thank you and have a wonderful day.
Helpful Links
- https://www.nginx.com/resources/wiki/
- https://www.freebsd.org
- https://wbond.net/sublime_packages/sftp
- https://docs.nginx.com/nginx/admin-guide/monitoring/logging/
Comments for Logging and Monitoring