26,39 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Sprache: Englisch
Investigate and solve problems with Nginx-powered websites using a deep understanding of the underlying principles
About This Book
- Solve problems with your Nginx-powered websites before your audience notices anything
- Peek into the Nginx architecture and gain knowledge that will help you be valuable to you in the long run
- Gain knowledge of different types of problems in a step-by-step way
Who This Book Is For
The book is for technical specialists who already use Nginx to serve web pages for their users. Whether you are an experienced system administrator or a new professional, this book will help you do your job in the most efficient way.
What You Will Learn
- Detect and investigate problems with your web servers
- Create correct and professional configuration files
- Get an in-depth understanding of the web server software
- Interpret Nginx log files easily and with actionable insights
- Make your websites respond as fast as possible
- Prevent problems by setting up proper monitoring and alerts
In Detail
Nginx is clearly winning the race to be the dominant software to power modern websites. It is fast and open source, maintained with passion by a brilliant team. This book will help you maintain your Nginx instances in a healthy and predictable state.
It will lead you through all the types of problems you might encounter as a web administrator, with a special focus on performance and migration from older software.
You will learn how to write good configuration files and will get good insights into Nginx logs. It will provide you solutions to problems such as missing or broken functionality and also show you how to tackle performance issues with the Nginx server. A special chapter is devoted to the art of prevention, that is, monitoring and alerting services you may use to detect problems before they manifest themselves on a big scale. The books ends with a reference to error and warning messages Nginx could emit to help you during incident investigations.
Style and approach
This comprehensive tutorial on Nginx troubleshooting takes an practical approach to guiding you through common issues in Nginx server.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 245
Veröffentlichungsjahr: 2016
Ähnliche
Table of Contents
Nginx Troubleshooting
Nginx Troubleshooting
Copyright © 2016 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
First published: April 2016
Production reference: 1190416
Published by Packt Publishing Ltd.
Livery Place
35 Livery Street
Birmingham B3 2PB, UK.
ISBN 978-1-78528-865-4
www.packtpub.com
Credits
Author
Alex Kapranoff
Reviewers
Titouan Galopin
Valery Kholodkov
Commissioning Editor
Dipika Gaonkar
Acquisition Editor
Reshma Raman
Content Development Editor
Sanjeet Rao
Technical Editor
Mohit Hassija
Copy Editor
Dipti Mankame
Project Coordinator
Judie Jose
Proofreader
Safis Editing
Indexer
Priya Sane
Graphics
Kirk D'Penha
Production Coordinator
Shantanu N. Zagade
Cover Work
Shantanu N. Zagade
About the Author
Alex Kapranoff is an established IT professional with more than 20 years of experience in roles ranging from a database developer to the CTO of a social search engine start-up to an infrastructure manager of a huge web application with hundreds of millions of users. His background allows him to be more on the developer side of things, and he is happy to share some of that perspective with fellow system administration specialists.
About the Reviewers
Titouan Galopin is a certified PHP/Symfony French web architect from Paris. He currently works for SensioLabs, the company behind the PHP framework Symfony, and he has worked for various other companies, including LIIP, Emakina, Ademis, and Coburo.
Titouan graduated in computer science and information technology from the Paris-Saclay University, and he is currently pursuing an engineering degree at the University of Technology of Compiègne.
First as a web developer and then as a web architect since 2012, Titouan has worked on Nginx intensively for PHP applications and Dockerized environments. Within the few years of his work, he has accumulated a lot of experience with Nginx and shares his experience in this book and in the related one, Nginx High Performance, Packt Publishing.
Valery Kholodkov is a seasoned IT professional with a decade of experience in creating, building, scaling, and maintaining industrial-grade web services, web applications, and mobile application backends. Throughout his career, he has worked for well-known brands such as Yandex, Booking.com, and AVG. He currently works as the CTO of QubiQ Digital, a consumer acquisition agency. Valery has a deep understanding of technology, and he is able to express its essence, advantages, and risks to a layman, which makes him an accomplished author and technical reviewer.
www.PacktPub.com
eBooks, discount offers, and more
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.PacktPub.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at <[email protected]> for more details.
At www.PacktPub.com, you can also read a collection of free technical articles, sign up for a range of free newsletters and receive exclusive discounts and offers on Packt books and eBooks.
https://www2.packtpub.com/books/subscription/packtlib
Do you need instant solutions to your IT questions? PacktLib is Packt's online digital book library. Here, you can search, access, and read Packt's entire library of books.
Why subscribe?
Preface
You will learn how to notes problems before your boss calls you about some pages not loading. You will learn how to find those problems using logs and your usual Linux toolbox. You will also learn how to minimize the probability of problems happening again.
Nginx started as a web accelerator reverse proxy inside one of the big Russian web companies of the early 2000s. The main web server software was Apache 1.3, and it started to show architectural problems serving thousands of relatively slow clients using the old process-based model. Smart web engineers were already building two-tier systems of light frontends based on the mod_proxy Apache module or even used the squid caching proxy in the reverse proxy mode.
The early predecessor of Nginx was named mod_accel, and it was also implemented as an Apache module. The mod_accel module gained some popularity among the administrators of some of the busiest websites, but it is nothing compared with what Nginx later enjoyed. Both of them are built on the idea that the additional level of proxying on the server side of a busy website is a good thing, providing both the extra flexibility and separating the job of serving slow clients from the actual response generation.
Nginx took the idea of mod_proxy module to the extreme by being a self-sufficient separate HTTP server with a goal to solve the so-called C10K problem, that is, serving 10,000 concurrent connections. The numbers do not look impressive at all in 2016, but they did in 2007 when Nginx first claimed a significant share of 1% of the Web according to Netcraft.
Since that time, the share grew manifold while Nginx steadily gained new functionality and remained the ideal open source success story project with a single, talented developer devoting his genius to producing free quality software, which the whole Web could benefit from.
In 2011, a commercial enterprise named Nginx, Inc. was founded, which allowed even more freedom for the developers (now a team). The firm provides both support services and a special subscription-based extended version of the software named Nginx Plus. We will mention some of the Nginx Plus features in the sixth chapter.
In 2016, Nginx is a great tool many businesses are built upon. However, it is still just a tool which requires a master to show its full potential. If you want to understand what is going on in your web server, to be able to write correct Nginx configuration files and read Nginx logs, and if you want your web server to be very fast, you will have to become that master.
What this book covers
Chapter 1, Searching for Problems in Nginx Configuration, briefly describes the configuration language of Nginx and presents some of the corner cases and several techniques to search for problems.
Chapter 2, Searching for Problems in Log Files, describes the logging subsystem, log syntax, and what to look for when you troubleshoot. Nginx provides thorough logs of everything it does.
Chapter 3, Troubleshooting Functionality, the central chapter in this book, contains a list of steps you will make while investigating a problem. You will find the types of problems people generally encounter with their Nginx-powered web servers.
Chapter 4, Optimizing Website Performance, is dedicated to all things about performance. Starting with thorough explanation of the basic principles behind the Nginx event-driven processing model, it also touches on caching and even gives some advice on possible upstream optimization.
Chapter 5, Troubleshooting Rare Specific Problems, is devoted to studies of several real cases that you may face, from some of the simplest and easiest cases to fix to more problematic cases. The cases described might not be the most frequent, but they still provide valuable insight on the internals of the software and the methods of troubleshooting.
Chapter 6, Monitoring Nginx, is devoted to the abundance of tools available today that you may use for monitoring. No system is complete without good processes for the detection of emerging problems.
Chapter 7, Going Forward with Nginx, the short final chapter, provides a selection of directions you may choose for your further development as a specialist. The whole industry is very dynamic, and you should never settle.
Appendix, Rare Nginx Error Messages, provides a reference of interesting and not very common error messages that you might encounter in your log files.
What you need for this book
Although modern versions of Nginx support Windows, this configuration is not considered production-ready. Most of the examples in this book will work on your Windows machines, but we still recommend having a Linux or FreeBSD server for experiments.
Nginx itself is pretty stable, so any version released since 2013 will suffice. Some of the newer features are only available in more recent versions, and those cases are marked in the book. We always recommend running modern Nginx from the stable line in production. As of the start of the year 2016, it is 1.8.1.
Who this book is for
The book is for technical specialists who already use Nginx to serve web pages for their users. Whether you are an experienced system administrator or a new professional, this book will help you do your job in the most efficient way.
Conventions
In this book, you will find a number of text styles that distinguish between different kinds of information. Here are some examples of these styles and an explanation of their meaning.
Code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles are shown as follows: "The error_page directive installs a handler for an HTTP error based on the famous HTTP status codes."
A block of code is set as follows:
When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:
Any command-line input or output is written as follows:
New terms and important words are shown in bold. Words that you see on the screen, for example, in menus or dialog boxes, appear in the text like this: "You should have a way to reboot an otherwise unreachable server; every sane modern hosting provider has it, whether in the form of a simple menu item Reboot, such as in Amazon EC2 or a whole IPMI console access."
Note
Warnings or important notes appear in a box like this.
Tip
Tips and tricks appear like this.
Reader feedback
Feedback from our readers is always welcome. Let us know what you think about this book—what you liked or disliked. Reader feedback is important for us as it helps us develop titles that you will really get the most out of.
To send us general feedback, simply e-mail <[email protected]>, and mention the book's title in the subject of your message.
If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, see our author guide at www.packtpub.com/authors.
Customer support
Now that you are the proud owner of a Packt book, we have a number of things to help you to get the most from your purchase.
Downloading the example code
You can download the example code files for this book from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
You can download the code files by following these steps:
You can also download the code files by clicking on the Code Files button on the book's webpage at the Packt Publishing website. This page can be accessed by entering the book's name in the Search box. Please note that you need to be logged in to your Packt account.
Once the file is downloaded, please make sure that you unzip or extract the folder using the latest version of:
Downloading the color images of this book
We also provide you with a PDF file that has color images of the screenshots/diagrams used in this book. The color images will help you better understand the changes in the output. You can download this file from https://www.packtpub.com/sites/default/files/downloads/NginxTroubleshooting_ColorImages.pdf.
Errata
Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you find a mistake in one of our books—maybe a mistake in the text or the code—we would be grateful if you could report this to us. By doing so, you can save other readers from frustration and help us improve subsequent versions of this book. If you find any errata, please report them by visiting http://www.packtpub.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details of your errata. Once your errata are verified, your submission will be accepted and the errata will be uploaded to our website or added to any list of existing errata under the Errata section of that title.
To view the previously submitted errata, go to https://www.packtpub.com/books/content/support and enter the name of the book in the search field. The required information will appear under the Errata section.
Piracy
Piracy of copyrighted material on the Internet is an ongoing problem across all media. At Packt, we take the protection of our copyright and licenses very seriously. If you come across any illegal copies of our works in any form on the Internet, please provide us with the location address or website name immediately so that we can pursue a remedy.
Please contact us at <[email protected]> with a link to the suspected pirated material.
We appreciate your help in protecting our authors and our ability to bring you valuable content.
Questions
If you have a problem with any aspect of this book, you can contact us at <[email protected]>, and we will do our best to address the problem.
Chapter 1. Searching for Problems in Nginx Configuration
Nginx is a complex piece of software that will help you implement your own part of the World Wide Web—one of the killer applications of the Internet as a whole. Although seeming to be simple, the Web and the underlying HTTP have a lot of intricate details that may require special attention. Nginx gives you the power to pay that attention to those details by means of the extensive configuration language. Following the grand UNIX tradition of human-readable and writable text configuration files, Nginx expects a certain level of understanding and zeal from you so that it can serve in the best way possible. It also means that there is freedom and huge potential for mistakes.
The main goal of this chapter is to lead you through the way Nginx is configured and show you some of the areas that are prone to errors.
You will find further:
Introducing basic configuration syntax, directives, and testing
Igor Sysoev, the principal author of Nginx, said, on several occasions, that he designed the Nginx configuration language in such a way that writing the configuration should not feel like programming, or actual coding. For a long time, he himself worked as a professional system administrator for several relatively big websites in Russia. He understood perfectly that the goal of a website administrator is not to end up with beautiful, elegant configurations or to have at one's disposal every imaginable function for all possible situations no matter how rare they are. The goal is to be able to declaratively describe the business requirements, to formulate which behavior is needed without delving into how that could be achieved in software. One interesting example of quite the opposite idea in language design is the Lighttpd configuration language, but that's out of the scope of this book.
This is what we have now—a simple declarative language inspired by Apache's one but without all the XML-like tags. Open the default nginx.conf file to see what Nginx configuration looks like. Some distributions contain their own modifications to the default file. We will use the one from the original tarball available at http://nginx.org/download/nginx-1.9.12.tar.gz. What follows is a quick syntax introduction using parts of that file as examples. You might find it too obvious but bear with us; even the most experienced reader will do good to refresh his or her memory.
Let us look at the very beginning of the file. Lines starting with # are comments, and they are ignored. Commenting out is a very common technique to make Nginx ignore a part of configuration. The topmost line in default Nginx configuration file (as of version 1.9.12) is actually commented out:
One easy way to comment out a block of lines in vim is highlighting them visually with Shift-V and then issuing the :s/^/#/ ex command. In Emacs, just select a region and then press M-;.
Nonempty noncommented lines in Nginx configuration are of the two following types.
Simple directives
Simple directives consist of a command word followed by a number of parameters and a semicolon. For example (see at the top of the default nginx.conf file):
Nothing to worry about here. People having too much experience with modern scripting languages, such as Python and Ruby, tend to forget the semicolon; we advise you to make sure that you add it.
The parameters mentioned here can be either constant values (numbers or strings, which does not matter, they are all parsed in the same way at this level) or they may contain variables. Variables in Nginx are the $dollar_prefixed identifiers that are replaced with some actual value at runtime. For example, there are variables containing data from an HTTP request, and you can modify website behavior depending on their values or just log them.
A very good example of variables in the default nginx.conf file is this:
This directive creates a log format by constructing a template for each line of the log. It uses a number of variables available during the request/response cycle.
Multiline directives
Multiline directives are simple directives with a BUT. Instead of a semicolon in the end, there is a block enclosed in braces { ... }. And here instead is meant literally. You don't put semicolons after closing braces. Those of you with just enough experience with more traditional C-like syntax programming languages will find this very natural.
Here is an example of the very first multiline directive in the default Nginx 1.9.12 nginx.conf file:
Now, this is an events directive, which does not have any parameters, and it contains a block instead of a semicolon. Because of these blocks, multiline directives are also named "block directives". Blocks contain various kinds of content, but one of the most important and interesting blocks is the one containing other directives—both simple and multiline.
In the previous example, the block of the events directive contains a simple worker_connections directive.
Multiline directives that allow other directives inside their blocks are named "contexts". They introduce new context for the enclosed, inner part of the configuration.
Most of the multiline directives are actually contexts—from the most popular, such as server or location, to the most obscure, such as limit_except. An example of a multiline directive that is not a context is types, which introduces the relation between file extensions and the so-called Multipurpose Internet Mail Extensions (MIME) types. We will look at types later in this chapter.
Contexts are very important. They are scopes and topics of the directives that are inside. If a command is not included in any multiline directive block, then it is considered part of the special context named "main" with the widest scope. Directives in this context affect the whole Nginx application. Other contexts are all either inside "main" or even deeper below, and the commands that are contained within those contexts have narrower scopes and affect only parts of the whole.
Include directive
We will not describe actual directives here except for one of them. It is the include directive, a special dear to the hearts of all sysadmins who scale their work to many websites, servers, or just URLs. It is a very simple block-level "package management tool" if we are allowed to use more programming terminology. This simple directive has one parameter, that is, a filename or a wild card (UNIX glob-style) matching a number of files. During processing, this directive is replaced by the contents of the files it refers to. A quick example (from the default nginx.conf file):
We won't offend you by spending more time on explaining include. What we need to add is that included files have to be fully correct syntactically. You cannot have half of a command in one file and then include the rest from another.
So, this is it, the whole syntax is described. Let us show you a fictional piece of configuration that demonstrates everything but does not actually work because it contains nonexistent directives (or maybe those are from some future version of Nginx):
Testing Nginx configuration
There is a very handy tool in the Nginx kit, a syntax checker for the configuration files. It is built into the main Nginx executable application and invoked by using the -t command-line switch as follows:
The command nginx -t tries to check your configuration quite thoroughly. For example, it will check all the included files and try to access all the auxiliary files like logs or pids to warn you about their nonexistence or insufficient permissions. You will become a better Nginx administrator if you acquire a habit of frequently running nginx -t.
The default configuration directory layout
We will now run through the entire configuration that you get bundled with Nginx by default. Some of it is a good example from which you will start writing your own. Some of it is just a sign of Nginx age. Again, we use the original tarball for the 1.9.12 version that is available on the official Nginx website.
This is a list of files inside the conf folder of the Nginx source archive:
The nginx.conf is the main file, the one everything starts with. All other files are either included from nginx.conf or not used at all. Actually, nginx.conf is the only configuration file that is required by Nginx code (and you can override even that by using -c command-line switch). We will discuss its content a little bit later.
A pair of fastcgi.conf and fastcgi_params files contains almost the same list of simple commands configuring the Nginx FastCGI client. FastCGI, being an interface to run web applications behind Nginx, is not turned on by default. These two files are provided as examples (one of them is even included with the include command from a commented section of the nginx.conf file).
Three files with enigmatic names koi-utf, koi-win, and win-utf are character maps to convert between different ways to encode Cyrillic characters in electronic documents. And Cyrillic is, of course, the script used for Russian and several other languages. In the old days of the first Internet hosts in Russia, there was a dispute on which way to encode Russian letters in documents. You can read about different Cyrillic charsets/encodings at http://czyborra.com/charsets/cyrillic.html. Several of them got popular, and web servers had to include functionality of converting documents on the fly in the case that a client browser requested a different encoding from what was used by the server. There was also a whole fork of Apache Web Server that had this functionality built in. Nginx had to do the same to stand a chance against Apache. And now, more than 10 years later, we still have these re-encoding files that are deeply obsolete as the global World Wide Web continues to move towards UTF-8 as the one universal encoding for all human languages. You won't ever use these koi-utf, koi-win, and win-utf files unless you support a very old website for Russian-speaking visitors.
The file named mime.types is used by default. You can see that it is included from the main nginx.conf, and you better leave it that way. "MIME types" is a registry of different types of information in files.
They have their origin in some of the email standards (hence, the MIME name) but are used everywhere, including the Web. Let's look inside mime.types:
Because it is included from nginx.conf, it should have a proper Nginx configuration language syntax. That's right, it contains a single multiline directive types, which is not a context (as described in the previous section). Its block is a list of pairs, each being a mapping from one MIME type to a list of file extensions. This mapping is used to mark static files served by Nginx as having a particular MIME (or content) type. According to the quoted segment, the files common.css and new.css will get the type text/css, whereas index.shtml will be text/html, and so on and so forth; it is really easy.
A quick example of modifying the MIME types registry
Sometimes, you will add things to this registry. Let's try to do this now and demonstrate an introduction of a simple mistake and the workflow to find and fix it.
Your website will host calendars for your colleagues. A calendar is a file in the iCalendar format generated by a third-party application and saved to a file with .ics extension. There is nothing about ics in the default mime.types
