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.

  1. debug
  2. info
  3. notice
  4. warn
  5. error
  6. crit
  7. alert
  8. 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

Alex Allen

Alex is an independent developer who is obsessed with both performance and information security. When not writing code, Alex is either playing guitar or working in his garden.

  1. Comments for Logging and Monitoring

You must login to comment

You May Also Like