This blog post is the second in a series about how to monitor NGINX and make the most out of your web delivery infrastructure with NGINX Amplify:
NGINX Amplify, our new cloud‑based monitoring and assistance platform, has been very successful so far. Thousands of NGINX users are learning more about their installations, monitoring and improving server performance, and tuning configuration, security, and scalability problems using NGINX Amplify.
NGINX Amplify analyzes your NGINX configuration, and provides useful recommendations based on years of our collective experience with tuning, optimizing, and operating NGINX‑powered sites. We created this service so you can take advantage of this knowledge and have all your configuration files checked by our automated system. This post provides some deeper insight into one specific feature of NGINX Amplify – configuration reports – and how to use the service to optimize your NGINX configuration.
NGINX Amplify interacts with NGINX servers and users through the following components:
The NGINX Amplify Agent is open source Python‑based software. The agent collects metadata and metrics from the operating system and all metrics available from NGINX.
NGINX Amplify processes and analyzes the configuration files for all your NGINX instances.
Every time the agent is started, or when the NGINX configuration is changed, the NGINX Amplify Agent parses configuration files. It does this for every running NGINX instance on the system. Parsed configuration data is sent to NGINX Amplify Cloud for automated analysis.
Configuration details that are sent to the NGINX Amplify Cloud include:
Parsed configuration files, including:
log_format
Sensitive and private data is never sent to the cloud, for example:
After analyzing the data from the agent, NGINX Amplify Web gives you valuable feedback about:
To run the configuration report in NGINX Amplify, follow these steps:
The report consists of several sections. We will describe each section here.
The Version section reports the version of NGINX software in use, the NGINX branch the version comes from (stable or mainline), the release date, and the most recent release on this branch.
Use this information to see if you are on the latest release from the branch you’ve chosen – for instance, if you are on the most recent mainline release. If not, consider upgrading to get the latest features and most recent bug fixes.
The Overview section includes information you need in order to review and update your current configuration:
nginx
‑t
commandinclude
directive for more details)Use this information to confirm the current status of your NGINX configuration files and to look for recent changes.
The Security section does not appear if no security issues are found. This section lists security advisories against the currently installed version of NGINX. The information includes a description, a pointer to any relevant advisories, the severity level, and a list of versions of NGINX that are not vulnerable to this security advisory, so you can consider upgrading.
If you are not using an official build, there’s a potential complicating factor: some security fixes may be “backported” into older versions. For instance, you may see a report that says you are running version 1.8.1 with a vulnerability to CVE‑2016‑4450, which is shown as fixed for version 1.8.3. However, for non‑official builds, the fix may have already been applied to your system by your own security team or by a third party. Check the documentation for non‑official builds to see if security vulnerabilities listed in NGINX Amplify reports have been fixed for that build.
We recommend using the latest official builds whenever possible.
The Virtual servers section provides the following information for the virtual servers defined for the NGINX instance being reported on:
Note: In order for NGINX Amplify Agent to check your SSL certificates, you must grant it filesystem access. See the instructions in our introductory NGINX Amplify blog post and the NGINX Amplify reference documentation for more information.
The SSL section tells you which version of SSL this NGINX instance is built with and which version it is dynamically linked with. This section lists the number of SSL‑enabled servers, HTTP/2‑enabled servers, and SSL certificates. Additional warnings are displayed when the SSL certificate expiration date is close or certificate renewal is overdue.
Your SSL certificates are analyzed in place, and private keys NEVER leave your servers.
Note: If you have performed an upgrade of the OpenSSL library, perform a full restart or upgrade of the NGINX service. A configuration reload (nginx
‑s
reload
) does not change the running libraries.
The Static analysis section lists recommendations for improving your configuration file and settings. Recommendations can address security, completeness, error prevention, and other areas.
For each recommendation, NGINX Amplify lists it, along with filenames and line numbers where it was triggered. Recommendations include links to the reference documentation, where all directives and their parameters are fully described.
Figure 2 shows an example of an error and a warning resulting from static analysis of the configuration. Additional examples appear below the figure.
Here’s how to mitigate issues – and confirm that the mitigation has worked:
Some additional examples of warnings and errors:
Warning: Can’t find /etc/nginx/conf.d/default.conf
. This can potentially lead to a failed update when installing a new Plus nginx package. New package may bring a default.conf
incompatible with your setup. It might get included then in the nginx configuration since nginx.conf
contains include
directive for conf.d/*.conf
.
Warning: It is recommended to include default_server
parameter for each unique listen
IP:port combination. If none of the listen
directives have the default_server
parameter, then the first server with a particular IP:port tuple becomes the default one. Default server is the server that will process requests that can’t be matched against any of the configured server_name
’s.
Warning: There should be normally a unique server_name
directive per server
.
Please ensure that a server_name
contains all possible virtual server names for your site(s).
Warning: It is recommended that a proxy_pass
always includes header definitions (at least Host
header has to be explicitly defined). Consider adding the following additional directives to your nginx configuration:
proxy_set_header Host $host;
and optionally the following:
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Port $server_port;
proxy_set_header X-Forwarded-Protocol $scheme;
Error: Found parameter to a listen
directive with a specific IP address, that puts it in conflict with a wildcard listen
directive for the same port. While it is possible to make nginx listen
on the same port with a wildcard socket and a specific IP address, such combination is not compatible with anything but default_server
, ssl
, spdy
, proxy_protocol
or http2
listen parameters.
Error: location has a regex pattern, but does not have a valid regex operator. Please make sure this is a desired behavior, since nginx location matching will not work with what is seemingly a regex pattern – but without proper regex operator.
If your configuration is clean and has no warnings or errors, the following message is displayed:
No issues found with the current configuration.
You can control which kinds of configuration analysis the NGINX Amplify Agent performs. To change which reports are run for the covered systems, follow these steps:
You can change three settings:
nginx
‑t
command to check whether the configuration has syntax errors. Typically a fully successful execution of the configuration test requires root privileges, and running it with the agent’s default permissions results in warnings in the NGINX error.log file. This option is disabled by default.You can further control which reporting options are allowed on a per‑system basis:
This post goes into depth about one capability of NGINX Amplify: configuration reporting. We’ve shown you how to get a report on your current configuration, customized by the type of information you want to review and the servers (Unix servers and NGINX servers) you wish to include.
Future blog posts will go into more depth about other ways to use NGINX Amplify to monitor NGINX and improve the performance of your site and apps. We look forward to your using NGINX Amplify, and to your feedback about how to improve it further.
Click the ? icon in the lower right corner of the NGINX Amplify Web page to provide feedback, or send us a message in the Comments below.
Sign up for free and start using NGINX Amplify today.
"This blog post may reference products that are no longer available and/or no longer supported. For the most current information about available F5 NGINX products and solutions, explore our NGINX product family. NGINX is now part of F5. All previous NGINX.com links will redirect to similar NGINX content on F5.com."