在生产环境中，我会更喜欢做与自动化相关的所有事情。如果计算机能完成你的任务，何必需要你亲自动手呢？但是，在不断变化并存在多种技术的环境中，创建和实施自动化是一项艰巨的任务。这就是为什么我喜欢 Ansible 的原因。Ansible 是一个用于 IT 配置管理，部署和业务流程的开源工具，使用起来非常方便。

我最喜欢 Ansible 的一个特点是，它是完全无客户端的。要管理一个系统，通过 SSH 建立连接，它使用Paramiko（一个 Python 库）或本地的 OpenSSH。Ansible 另一个吸引人的地方是它有许多可扩展的模块。这些模块可被系统管理员用于执行一些的常见任务。特别是，它们使用 Ansible 这个强有力的工具可以跨多个服务器、环境或操作系统安装和配置任何程序，只需要一个控制节点。

在本教程中，我将带你使用 Ansible 完成安装和部署开源 NGINX 和我们的商业产品 NGINX Plus。我将在 CentOS 服务器上演示，但我也在下面的“在 Ubuntu 上创建 Ansible Playbook 来安装 NGINX 和 NGINX Plus”小节中包含了在 Ubuntu 服务器上部署的细节。

在本教程中我将使用 Ansible 1.9.2 版本，并在 CentOS 7.1 服务器上部署运行。

$ ansible --version
ansible 1.9.2

$ cat /etc/redhat-release
CentOS Linux release 7.1.1503 (Core)

如果你还没有 Ansible，可以在 Ansible 网站 查看说明并安装它。

如果你使用的是 CentOS，安装 Ansible 十分简单，只要输入以下命令。如果你想使用源码编译安装或使用其他发行版，请参阅上面 Ansible 链接中的说明。

$ sudo yum install -y epel-release && sudo yum install -y ansible

根据环境的不同，在本教程中的命令有的可能需要 sudo 权限。文件路径，用户名和目标服务器取决于你的环境的情况。

创建一个 Ansible Playbook 来安装 NGINX (CentOS)

首先，我们要为 NGINX 的部署创建一个工作目录，包括子目录和部署配置文件。我通常建议在你的主目录中创建该目录，在文章的所有例子中都会有说明。

$ cd $HOME
$ mkdir -p ansible-nginx/tasks/
$ touch ansible-nginx/deploy.yml
$ touch ansible-nginx/tasks/install_nginx.yml

目录结构看起来是这样的。你可以使用 tree 命令来查看。

$ tree $HOME/ansible-nginx/
/home/kjones/ansible-nginx/
├── deploy.yml
└── tasks
    └── install_nginx.yml

1 directory, 2 files

如果你没有安装 tree 命令，使用以下命令去安装。

$ sudo yum install -y tree

创建主部署文件

接下来，我们在文本编辑器中打开 deploy.yml。我喜欢在命令行上使用 vim 来编辑配置文件，在整个教程中也都将使用它。

$ vim $HOME/ansible-nginx/deploy.yml

deploy.yml 文件是 Ansible 部署的主要文件，在“使用 Ansible 部署 NGINX”小节中，我们运行 ansible‑playbook 命令时会使用此文件。在这个文件中，我们指定 Ansible 运行时使用的库以及其它配置文件。

在这个例子中，我使用 include 模块来指定配置文件一步一步来安装NGINX。虽然可以创建一个非常大的 playbook 文件，我建议你将其分割为小文件，让它们更有条理。include 的示例中可以复制静态内容，复制配置文件，为更高级的部署使用逻辑配置设定变量。

在文件中输入以下行。我在顶部的注释包含了文件名用于参考。

# ./ansible-nginx/deploy.yml

- hosts: nginx
  tasks:
    - include: 'tasks/install_nginx.yml'

hosts 语句说明 Ansible 部署 nginx 组的所有服务器，服务器在 /etc/ansible/hosts 中指定。我们会在下面的“创建 NGINX 服务器列表”小节编辑此文件。

include 语句说明 Ansible 在部署过程中从 tasks 目录下读取并执行 install\_nginx.yml 文件中的内容。该文件包括以下几步：下载，安装，并启动 NGINX。我们将在下一节创建此文件。

为 NGINX 创建部署文件

现在，先保存 deploy.yml 文件，并在编辑器中打开 install\_nginx.yml 。

$ vim $HOME/ansible-nginx/tasks/install_nginx.yml

该文件包含有指令（使用 YAML 格式写的）， Ansible 会按照指令安装和配置我们的 NGINX 部署过程。每个节（过程中的步骤）起始于一个描述此步骤的 name 语句（前面有连字符）。 name 后的字符串是 Ansible 部署过程中输出到标准输出的，可以根据你的意愿来修改。YAML 文件中的节的下一行是在部署过程中将使用的模块。在下面的配置中，使用了 yum 和 service 模块。yum 模块用于在 CentOS 上安装软件包。service 模块用于管理 UNIX 的服务。在这个节的最后一行或几行指定了几个模块的参数（在本例中，这些行以 name 和 state 开始）。

在文件中输入以下行。就像 deploy.yml，在我们文件的第一行是用于参考的文件名的注释。第一个节告诉 Ansible 在CentOS 7 上从 NGINX 仓库安装该 .rpm 文件。这让软件包管理器直接从 NGINX 仓库安装最新最稳定的版本。根据你的 CentOS 版本修改路径。所有可用的包的列表可以在 开源 NGINX 网站 上找到。接下来的两节告诉 Ansible 使用 yum 模块安装最新的 NGINX 版本，然后使用 service 模块启动 NGINX。

注意: 在第一个节中，CentOS 包中的路径名可能由于宽度显示为连着的两行。请在一行上输入其完整路径。

# ./ansible-nginx/tasks/install_nginx.yml

- name: NGINX | Installing NGINX repo rpm
  yum:
    name: http://nginx.org/packages/centos/7/noarch/RPMS/nginx-release-centos-7-0.el7.ngx.noarch.rpm

- name: NGINX | Installing NGINX
  yum:
    name: nginx
    state: latest

- name: NGINX | Starting NGINX
  service:
    name: nginx
    state: started

创建 NGINX 服务器列表

现在，我们设置好了 Ansible 部署的所有配置文件，我们需要告诉 Ansible 部署哪个服务器。我们需要在 Ansible 中指定 hosts 文件。先备份现有的文件，并新建一个新文件来部署。

$ sudo mv /etc/ansible/hosts /etc/ansible/hosts.backup
$ sudo vim /etc/ansible/hosts

在文件中输入（或编辑）以下行来创建一个名为 nginx 的组并列出安装 NGINX 的服务器。你可以通过主机名、IP 地址、或者在一个范围，例如 server[1-3].domain.com 来指定服务器。在这里，我通过 IP 地址指定一台服务器。

# /etc/ansible/hosts

[nginx]
172.16.239.140

设置安全性

接近完成了，但在部署之前，我们需要确保 Ansible 已被授权通过 SSH 访问我们的目标服务器。

首选并且最安全的方法是添加 Ansible 所要部署服务器的 RSA SSH 密钥到目标服务器的 authorized\_keys 文件中，这给予 Ansible 在目标服务器上的不受限制 SSH 权限。要了解更多关于此配置，请参阅 wiki.centos.org 上 安全加固 OpenSSH。这样，你就可以自动部署而无需用户交互。

另外，你也可以在部署过程中要求输入密码。我强烈建议你只在测试过程中使用这种方法，因为它是不安全的，没有办法跟踪目标主机的身份（fingerprint）变化。如果你想这样做，将每个目标主机 /etc/ssh/ssh\_config 文件中 StrictHostKeyChecking 的默认值 yes 改为 no。然后在 ansible-playbook 命令中添加 --ask-pass 参数来让 Ansible 提示输入 SSH 密码。

在这里，我将举例说明如何编辑 ssh\_config 文件来禁用在目标服务器上严格的主机密钥检查。我们手动连接 SSH 到我们将部署 NGINX 的服务器，并将 StrictHostKeyChecking 的值更改为 no。

$ ssh [email protected]
[email protected]'s password:***********

[kjones@nginx ]$ sudo vim /etc/ssh/ssh_config

当你更改后，保存 ssh\_config，并通过 SSH 连接到你的 Ansible 服务器。保存后的设置应该如下所示。

# /etc/ssh/ssh_config

StrictHostKeyChecking no

运行 Ansible 部署 NGINX

如果你一直照本教程的步骤来做，你可以运行下面的命令来使用 Ansible 部署 NGINX。（再次提示，如果你设置了 RSA SSH 密钥认证，那么 --ask-pass 参数是不需要的。）在 Ansible 服务器运行命令，并使用我们上面创建的配置文件。

$ sudo ansible-playbook --ask-pass $HOME/ansible-nginx/deploy.yml

Ansible 提示输入 SSH 密码，输出如下。recap 中显示 failed=0 这条信息，意味着部署成功了。

$ sudo ansible-playbook --ask-pass $HOME/ansible-nginx/deploy.yml
SSH password:

PLAY [all] ********************************************************************

GATHERING FACTS ***************************************************************
ok: [172.16.239.140]

TASK: [NGINX | Installing NGINX repo rpm] *************************************
changed: [172.16.239.140]

TASK: [NGINX | Installing NGINX] **********************************************
changed: [172.16.239.140]

TASK: [NGINX | Starting NGINX] ************************************************
changed: [172.16.239.140]

PLAY RECAP ********************************************************************
172.16.239.140             : ok=4    changed=3    unreachable=0    failed=0

如果你没有得到一个成功的 play recap，你可以尝试用 -vvvv 参数（带连接调试的详细信息）再次运行 ansible-playbook 命令来解决部署过程的问题。

当部署成功（假如我们是第一次部署）后，你可以在远程服务器上运行基本的 cURL 命令验证 NGINX 。在这里，它会返回 200 OK。Yes！我们使用 Ansible 成功安装了 NGINX。

$ curl -Is 172.16.239.140 | grep HTTP
HTTP/1.1 200 OK

创建 Ansible Playbook 来安装 NGINX Plus (CentOS)

现在，我已经展示了如何安装 NGINX 的开源版本，我将带你完成安装 NGINX Plus。这需要更改一些额外的部署配置，并展示了一些 Ansible 的其他功能。

复制 NGINX Plus 上的证书和密钥到 Ansible 服务器

使用 Ansible 安装和配置 NGINX Plus 时，首先我们需要将 NGINX Plus Customer Portal NGINX Plus 订阅的密钥和证书复制到 Ansible 部署服务器上的标准位置。

购买了 NGINX Plus 或正在试用的客户也可以访问 NGINX Plus Customer Portal。如果你有兴趣测试 NGINX Plus，你可以申请免费试用30天，点击这里。在你注册后不久你将收到一个试用证书和密钥的链接。

在 Mac 或 Linux 主机上，我在这里使用 scp 工具演示。在 Microsoft Windows 主机，可以使用 WinSCP。在本教程中，先下载文件到我的 Mac 笔记本电脑上，然后使用 scp 将其复制到 Ansible 服务器。密钥和证书的位置都在我的家目录下。

$ cd /path/to/nginx-repo-files/
$ scp nginx-repo.* user@destination-server:.

接下来，我们通过 SSH 连接到 Ansible 服务器，确保 NGINX Plus 的 SSL 目录存在，移动文件到这儿。

$ ssh user@destination-server
$ sudo mkdir -p /etc/ssl/nginx/
$ sudo mv nginx-repo.* /etc/ssl/nginx/

验证你的 /etc/ssl/nginx 目录包含了证书(.crt)和密钥(.key)文件。你可以使用 tree 命令检查。

$ tree /etc/ssl/nginx
/etc/ssl/nginx
├── nginx-repo.crt
└── nginx-repo.key

0 directories, 2 files

如果你没有安装 tree，可以使用下面的命令去安装。

$ sudo yum install -y tree

创建 Ansible 目录结构

以下执行的步骤和我们的“创建 Ansible Playbook 来安装 NGINX（CentOS)”小节中部署开源 NGINX 的非常相似。首先，我们建一个工作目录用于部署 NGINX Plus 使用。我喜欢将它创建为我主目录的子目录。

$ cd $HOME
$ mkdir -p ansible-nginx-plus/tasks/
$ touch ansible-nginx-plus/deploy.yml
$ touch ansible-nginx-plus/tasks/install_nginx_plus.yml

目录结构看起来像这样。

$ tree $HOME/ansible-nginx-plus/
/home/kjones/ansible-nginx-plus/
├── deploy.yml
└── tasks
└── install_nginx_plus.yml

1 directory, 2 files

创建主部署文件

接下来，像开源的 NGINX 一样，我们使用 vim 创建 deploy.yml 文件。

$ vim ansible-nginx-plus/deploy.yml

和开源 NGINX 的部署唯一的区别是，我们将包含文件的名称修改为 install\_nginx\_plus.yml。该文件告诉 Ansible 在 nginx 组中的所有服务器（/etc/ansible/hosts 中定义的）上部署 NGINX Plus ，然后在部署过程中从 tasks 目录读取并执行 install\_nginx\_plus.yml 的内容。

# ./ansible-nginx-plus/deploy.yml

- hosts: nginx
  tasks:
    - include: 'tasks/install_nginx_plus.yml'

如果你之前没有安装过的话，你需要创建 hosts 文件，详细说明在上面的“创建 NGINX 服务器的列表”小节。

为 NGINX Plus 创建部署文件

在文本编辑器中打开 install\_nginx\_plus.yml。该文件包含了使用 Ansible 来安装和配置 NGINX Plus 部署过程中的指令。这些命令和模块仅针对 CentOS，有些是 NGINX Plus 独有的。

$ vim ansible-nginx-plus/tasks/install_nginx_plus.yml

第一节使用 file 模块，告诉 Ansible 使用指定的path和state参数为 NGINX Plus 创建特定的 SSL 目录，设置属主为 root，将权限 mode 更改为0700。

# ./ansible-nginx-plus/tasks/install_nginx_plus.yml

- name: NGINX Plus | 创建 NGINX Plus ssl 证书目录
  file: path=/etc/ssl/nginx state=directory group=root mode=0700

接下来的两节使用 copy 模块从 Ansible 部署服务器上将 NGINX Plus 的证书和密钥复制到 NGINX Plus 服务器上，再修改属主为 root，权限 mode 为0700。

- name: NGINX Plus | 复制 NGINX Plus repo 证书 
  copy: src=/etc/ssl/nginx/nginx-repo.crt dest=/etc/ssl/nginx/nginx-repo.crt owner=root group=root mode=0700

- name: NGINX Plus | 复制 NGINX Plus 密钥
  copy: src=/etc/ssl/nginx/nginx-repo.key dest=/etc/ssl/nginx/nginx-repo.key owner=root group=root mode=0700

接下来，我们告诉 Ansible 使用 get_url 模块在 url 参数指定的远程位置从 NGINX Plus 仓库下载 CA 证书，通过 dest 参数把它放在指定的目录 dest ，并设置权限 mode 为 0700。

- name: NGINX Plus | 下载 NGINX Plus CA 证书
  get_url: url=https://cs.nginx.com/static/files/CA.crt dest=/etc/ssl/nginx/CA.crt mode=0700

同样，我们告诉 Ansible 使用 get_url 模块下载 NGINX Plus repo 文件，并将其复制到 NGINX Plus 服务器上的 /etc/yum.repos.d 目录下。

- name: NGINX Plus | 下载 yum NGINX Plus 仓库
  get_url: url=https://cs.nginx.com/static/files/nginx-plus-7.repo dest=/etc/yum.repos.d/nginx-plus-7.repo mode=0700

最后两节的 name 告诉 Ansible 使用 yum 和 service 模块下载并启动 NGINX Plus。

- name: NGINX Plus | 安装 NGINX Plus
  yum:
    name: nginx-plus
    state: latest

- name: NGINX Plus | 启动 NGINX Plus
  service:
    name: nginx
    state: started

运行 Ansible 来部署 NGINX Plus

在保存 install\_nginx\_plus.yml 文件后，运行 ansible-playbook 命令来部署 NGINX Plus。同样在这里，我们使用 --ask-pass 参数使用 Ansible 提示输入 SSH 密码并把它传递给每个 NGINX Plus 服务器，并指定主配置文件路径 deploy.yml 文件。

$ sudo ansible-playbook --ask-pass $HOME/ansible-nginx-plus/deploy.yml

PLAY [nginx] ******************************************************************

GATHERING FACTS ***************************************************************
ok: [172.16.239.140]

TASK: [NGINX Plus | Creating NGINX Plus ssl cert repo directory] **************
changed: [172.16.239.140]

TASK: [NGINX Plus | Copying NGINX Plus repository certificate] ****************
changed: [172.16.239.140]

TASK: [NGINX Plus | Copying NGINX Plus repository key] ************************
changed: [172.16.239.140]

TASK: [NGINX Plus | Downloading NGINX Plus CA certificate] ********************
changed: [172.16.239.140]

TASK: [NGINX Plus | Downloading yum NGINX Plus repository] ********************
changed: [172.16.239.140]

TASK: [NGINX Plus | Installing NGINX Plus] ************************************
changed: [172.16.239.140]

TASK: [NGINX Plus | Starting NGINX Plus] **************************************
changed: [172.16.239.140]

PLAY RECAP ********************************************************************
172.16.239.140             : ok=8    changed=7    unreachable=0    failed=0

playbook 的 recap 成功完成。现在，使用 curl 命令来验证 NGINX Plus 是否在运行。太好了，我们得到的是 200 OK！成功了！我们使用 Ansible 成功地安装了 NGINX Plus。

$ curl -Is http://172.16.239.140 | grep HTTP
HTTP/1.1 200 OK

在 Ubuntu 上创建 Ansible Playbook 来安装 NGINX 和 NGINX Plus

在 Ubuntu 服务器 上部署 NGINX 和 NGINX Plus 的过程与 CentOS 很相似，我将一步一步的指导来完成整个部署文件，并指出和 CentOS 的细微差异。

首先和 CentOS 一样，创建 Ansible 目录结构和 Ansible 主部署文件。也按“创建 NGINX 服务器的列表”小节的描述创建 /etc/ansible/hosts 文件。对于 NGINX Plus，你也需要安装“复制 NGINX Plus 证书和密钥到 Ansible 服务器”小节的描述复制证书和密钥。

下面是开源 NGINX 的 install\_nginx.yml 部署文件。在第一节，我们使用 apt_key 模块导入 NGINX 的签名密钥。接下来的两节使用 lineinfile 模块来添加 Ubuntu 14.04 的软件包 URL 到 sources.list 文件中。最后，我们使用 apt 模块来更新缓存并安装 NGINX（apt 取代了我们在 CentOS 中部署时的 yum 模块）。

# ./ansible-nginx/tasks/install_nginx.yml

- name: NGINX | 添加 NGINX 签名密钥
  apt_key: url=http://nginx.org/keys/nginx_signing.key state=present

- name: NGINX | 为 NGINX 添加 sources.list deb url  
  lineinfile: dest=/etc/apt/sources.list line="deb http://nginx.org/packages/mainline/ubuntu/ trusty nginx"

- name: NGINX Plus | 为 NGINX 添加 sources.list deb-src url  
  lineinfile: dest=/etc/apt/sources.list line="deb-src http://nginx.org/packages/mainline/ubuntu/ trusty nginx"

- name: NGINX | 更新 apt 缓存
  apt:
    update_cache: yes

- name: NGINX | 安装 NGINX
  apt:
    pkg: nginx
    state: latest

- name: NGINX | 启动 NGINX
  service:
    name: nginx
    state: started

下面是 NGINX Plus 的部署文件 install\_nginx.yml。前四节设置了 NGINX Plus 密钥和证书。然后，我们像开源的 NGINX 一样用 apt_key 模块导入签名密钥，get_url 模块为 NGINX Plus 下载 apt 配置文件。shell 模块使用 printf 命令写下输出到 sources.list.d 目录中的 nginx-plus.list 文件。最终的 name 模块和开源 NGINX 一样。

# ./ansible-nginx-plus/tasks/install_nginx_plus.yml

- name: NGINX Plus | 创建 NGINX Plus ssl 证书 repo 目录
  file: path=/etc/ssl/nginx state=directory group=root mode=0700

- name: NGINX Plus | 复制 NGINX Plus 仓库证书
  copy: src=/etc/ssl/nginx/nginx-repo.crt dest=/etc/ssl/nginx/nginx-repo.crt owner=root group=root mode=0700

- name: NGINX Plus | 复制 NGINX Plus 仓库密钥
  copy: src=/etc/ssl/nginx/nginx-repo.key dest=/etc/ssl/nginx/nginx-repo.key owner=root group=root mode=0700

- name: NGINX Plus | 安装 NGINX Plus CA 证书
  get_url: url=https://cs.nginx.com/static/files/CA.crt dest=/etc/ssl/nginx/CA.crt mode=0700

- name: NGINX Plus | 添加 NGINX Plus 签名密钥
  apt_key: url=http://nginx.org/keys/nginx_signing.key state=present

- name: NGINX Plus | 安装 Apt-Get NGINX Plus 仓库
  get_url: url=https://cs.nginx.com/static/files/90nginx dest=/etc/apt/apt.conf.d/90nginx mode=0700

- name: NGINX Plus | 为 NGINX Plus 添加 sources.list url  
  shell: printf "deb https://plus-pkgs.nginx.com/ubuntu `lsb_release -cs` nginx-plus\n" >/etc/apt/sources.list.d/nginx-plus.list

- name: NGINX Plus | 运行 apt-get update
  apt:
    update_cache: yes

- name: NGINX Plus | 安装 NGINX Plus 通过 apt-get
  apt:
    pkg: nginx-plus
    state: latest

- name: NGINX Plus | 启动 NGINX Plus
  service:
    name: nginx
    state: started

现在我们已经准备好运行 ansible-playbook 命令：

$ sudo ansible-playbook --ask-pass $HOME/ansible-nginx-plus/deploy.yml

你应该得到一个成功的 play recap。如果你没有成功，你可以使用冗余参数，以帮助你解决出现的问题。

小结

我在这个教程中演示是什么是 Ansible，可以做些什么来帮助你自动部署 NGINX 或 NGINX Plus，这仅仅是个开始。还有许多有用的模块，包括从用户账号管理到自定义配置模板等。如果你有兴趣了解关于这些的更多信息，请访问 Ansible 官方文档。

via: https://www.nginx.com/blog/installing-nginx-nginx-plus-ansible/

作者：Kevin Jones 译者：strugglingyouth 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

早些时候，我们发布了支持 HTTP/2 协议的 NGINX Plus R7。作为 HTTP 协议的最新标准，HTTP/2 的设计为现在的 web 应用程序带来了更高的性能和安全性。（LCTT 译注： 开源版本的 NGINX 1.95 也支持 HTTP/2 了。）

NGINX Plus 所实现的 HTTP/2 协议可与现有的网站和应用程序进行无缝衔接。只需要一点改变，不管用户选择什么样的浏览器，NGINX Plus 都能为用户同时提供 HTTP/1.x 与HTTP/2 的最佳体验。

要支持 HTTP/2 仅需通过可选的 nginx‑plus‑http2 软件包。nginx‑plus 和 nginx‑plus‑extras 软件包支持 SPDY 协议，目前推荐用于生产站点，因为其被大多数浏览器所支持并且代码也是相当成熟了。

为什么要使用 HTTP/2？

HTTP/2 使数据传输更高效，对你的应用程序更安全。 HTTP/2 相比于 HTTP/1.x 有五个提高性能特点：

• 完全复用 – 在一个保持激活（keepalive）的连接上，HTTP/1.1 强制按严格的顺序来处理请求。一个请求必须在下一个请求开始前结束。 HTTP/2 消除了这一要求，允许并行和乱序来处理请求。
• 单一，持久连接 – 由于 HTTP/2 允许请求完全复用，所以可以通过单一连接并行下载网页上的所有对象。在 HTTP/1.x 中，使用多个连接来并行下载资源，从而导致使用底层 TCP 协议效率很低。
• 二进制编码 – Header 信息使用紧凑的二进制格式发送，而不是纯文本格式，节省了传输字节。
• Header 压缩 – Headers 使用专用的 HPACK 压缩算法来进行压缩，这进一步降低数据通过网络传输的字节。
• SSL/TLS 加密 – 在 HTTP/2 中，强制使用 SSL/TLS。在 RFC 中并没有强制，其允许纯文本的 HTTP/2，但是当前所有实现 HTTP/2的 Web 浏览器都只支持加密。 SSL/TLS 可以使你的网站更安全，并且使用 HTTP/2 各项性能会有提升，加密和解密过程的性能损失就减少了。

要了解更多关于 HTTP/2:

• 请阅读我们的 白皮书，它涵盖了你需要了解HTTP/2 的一切。
• 下载由 Google 的 Ilya Grigorik 编写的 特别版的高性能浏览器网络电子书 （ LCTT 译注：涵盖 HTTP/2 的部分）。

NGINX Plus 如何实现 HTTP/2

我们的 HTTP/2 实现是基于 SPDY 支持的，它已经被广泛部署（使用了 NGINX 或 NGINX Plus 的网站近 75％ 都使用了 SPDY）。使用 NGINX Plus 部署 HTTP/2 时，几乎不会改变你应用程序的配置。本节将讨论 NGINX Plus如何实现对 HTTP/2 的支持。

一个 HTTP/2 网关

NGINX Plus 作为一个 HTTP/2 网关。它与支持 HTTP/2 的客户端 Web 浏览器用 HTTP/2 通讯，而转换 HTTP/2 请求给后端服务器通信时使用 HTTP/1.x（或者 FastCGI, SCGI, uWSGI, 等等. – 取决于你目前正在使用的协议）。

向后兼容性

在一段时间内，你需要同时支持 HTTP/2 和 HTTP/1.x。在撰写本文时，超过50％的用户使用的 Web 浏览器已经支持 HTTP/2，但这也意味着近50％的人还没有使用。

为了同时支持 HTTP/1.x 和 HTTP/2，NGINX Plus 实现了 TLS 上的 Next Protocol Negotiation (NPN)扩展。当 Web 浏览器连接到服务器时，其将所支持的协议列表发送到服务器端。如果浏览器支持的协议列表中包括 h2 - 即 HTTP/2，NGINX Plus 将使用 HTTP/2 连接到浏览器。如果浏览器不支持 NPN 或在发送支持的协议列表中没有 h2，NGINX Plus 将继续回落到 HTTP/1.x。

转向 HTTP/2

NGINX 公司会尽可能帮助大家无缝过渡到使用 HTTP/2。本节介绍了通过对你应用进行改变来启用对 HTTP/2 支持，其中只需对 NGINX Plus 配置进行几个变化。

前提条件

使用 nginx‑plus‑http2 软件包升级到 NGINX Plus R7。注意现在还没有支持 HTTP/2 版本的 nginx‑plus‑extras 软件包。

重定向所有流量到 SSL/TLS

如果你的应用尚未使用 SSL/TLS 加密，现在启用它正是一个好的时机。加密你的应用程序可以保护你免受间谍以及来自其他中间人的攻击。一些搜索引擎甚至在搜索结果中对加密站点提高排名。下面的配置块重定向所有的普通 HTTP 请求到该网站的加密版本。

server {
    listen 80;
    location / {
        return 301 https://$host$request_uri;
    }
}

启用 HTTP/2

要启用对 HTTP/2 的支持，只需将 http2 参数添加到所有的 listen 指令中，也要包括 SSL 参数，因为浏览器不支持不加密的 HTTP/2 请求。

server {
    listen 443 ssl http2 default_server;

    ssl_certificate     server.crt;
    ssl_certificate_key server.key;
    …
}

如果有必要，重启 NGINX Plus，例如通过运行 nginx -s reload 命令。要验证 HTTP/2 是否正常工作，你可以在 Google Chrome 和 Firefox 中使用 “HTTP/2 and SPDY indicator” 插件来检查。

注意事项

• 在安装 nginx‑plus‑http2 包之前, 你必须删除配置文件中所有 listen 指令后的 SPDY 参数（使用 http2 和 ssl 参数来替换它以启用对 HTTP/2 的支持）。使用这个包后，如果 listen 指令后有 spdy 参数，NGINX Plus 将无法启动。
• 如果你在 NGINX Plus 前端使用了 Web 应用防火墙（WAF），请确保它能够解析 HTTP/2，或者把它移到 NGINX Plus 后面。
• 此版本不支持在 HTTP/2 RFC 中定义的 “Server Push” 特性。 NGINX Plus 以后的版本可能会支持它。
• NGINX Plus R7 同时支持 SPDY 和 HTTP/2（LCTT 译注：但是你只能同时使用其中一种）。在以后的版本中，我们将弃用对 SPDY 的支持。谷歌在2016年初将 弃用 SPDY，因此同时支持这两种协议也非必要。
• 如果 ssl\_prefer\_server\_ciphers 设置为 on 或者使用了定义在 Appendix A: TLS 1.2 Ciper Suite Black List 中的 ssl\_ciphers 列表时，浏览器会出现 handshake-errors 而无法正常工作。详细内容请参阅 section 9.2.2 of the HTTP/2 RFC。

特别感谢

NGINX 公司要感谢 Dropbox 和 Automattic，他们是我们软件的重度使用者，并帮助我们实现 HTTP/2。他们的贡献帮助我们加速完成这个软件，我们希望你也能支持他们。

via: https://www.nginx.com/blog/http2-r7/

作者：Faisal Memon 译者：strugglingyouth 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

如果你已经阅读了前面的如何监控 NGINX，你应该知道从你网络环境的几个指标中可以获取多少信息。而且你也看到了从 NGINX 特定的基础中收集指标是多么容易的。但要实现全面，持续的监控 NGINX，你需要一个强大的监控系统来存储并将指标可视化，当异常发生时能提醒你。在这篇文章中，我们将向你展示如何使用 Datadog 安装 NGINX 监控，以便你可以在定制的仪表盘中查看这些指标：

Datadog 允许你以单个主机、服务、流程和度量来构建图形和警告，或者使用它们的几乎任何组合构建。例如，你可以监控你的所有主机，或者某个特定可用区域的所有NGINX主机，或者您可以监视具有特定标签的所有主机的一个关键指标。本文将告诉您如何：

• 在 Datadog 仪表盘上监控 NGINX 指标，就像监控其他系统一样
• 当一个关键指标急剧变化时设置自动警报来通知你

配置 NGINX

为了收集 NGINX 指标，首先需要确保 NGINX 已启用 status 模块和一个 报告 status 指标的 URL。一步步的配置开源 NGINX 和 NGINX Plus 请参见之前的相关文章。

整合 Datadog 和 NGINX

安装 Datadog 代理

Datadog 代理是一个开源软件，它能收集和报告你主机的指标，这样就可以使用 Datadog 查看和监控他们。安装这个代理通常仅需要一个命令

只要你的代理启动并运行着，你会看到你主机的指标报告在你 Datadog 账号下。

配置 Agent

接下来，你需要为代理创建一个简单的 NGINX 配置文件。在你系统中代理的配置目录应该在这儿找到。

在目录里面的 conf.d/nginx.yaml.example 中，你会发现一个简单的配置文件，你可以编辑并提供 status URL 和可选的标签为每个NGINX 实例：

init_config:

instances:

    -   nginx_status_url: http://localhost/nginx_status/
        tags:
            -   instance:foo

当你提供了 status URL 和任意 tag，将配置文件保存为 conf.d/nginx.yaml。

重启代理

你必须重新启动代理程序来加载新的配置文件。重新启动命令在这里，根据平台的不同而不同。

检查配置文件

要检查 Datadog 和 NGINX 是否正确整合，运行 Datadog 的 info 命令。每个平台使用的命令看这儿。

如果配置是正确的，你会看到这样的输出：

Checks
======

  [...]

  nginx
  -----
      - instance #0 [OK]
      - Collected 8 metrics & 0 events 

安装整合

最后，在你的 Datadog 帐户打开“Nginx 整合”。这非常简单，你只要在 NGINX 整合设置中点击“Install Integration”按钮。

指标!

一旦代理开始报告 NGINX 指标，你会看到一个 NGINX 仪表盘出现在在你 Datadog 可用仪表盘的列表中。

基本的 NGINX 仪表盘显示有用的图表，囊括了几个我们的 NGINX 监控介绍中的关键指标。 （一些指标，特别是请求处理时间要求进行日志分析，Datadog 不支持。）

你可以通过增加 NGINX 之外的重要指标的图表来轻松创建一个全面的仪表盘，以监控你的整个网站设施。例如，你可能想监视你 NGINX 的主机级的指标，如系统负载。要构建一个自定义的仪表盘，只需点击靠近仪表盘的右上角的选项并选择“Clone Dash”来克隆一个默认的 NGINX 仪表盘。

你也可以使用 Datadog 的主机地图在更高层面监控你的 NGINX 实例，举个例子，用颜色标示你所有的 NGINX 主机的 CPU 使用率来辨别潜在热点。

NGINX 指标警告

一旦 Datadog 捕获并可视化你的指标，你可能会希望建立一些监控自动地密切关注你的指标，并当有问题提醒你。下面将介绍一个典型的例子：一个提醒你 NGINX 吞吐量突然下降时的指标监控器。

监控 NGINX 吞吐量

Datadog 指标警报可以是“基于吞吐量的”（当指标超过设定值会警报）或“基于变化幅度的”（当指标的变化超过一定范围会警报）。在这个例子里，我们会采取后一种方式，当每秒传入的请求急剧下降时会提醒我们。下降往往意味着有问题。

1. 创建一个新的指标监控。从 Datadog 的“Monitors”下拉列表中选择“New Monitor”。选择“Metric”作为监视器类型。

2. 定义你的指标监视器。我们想知道 NGINX 每秒总的请求量下降的数量，所以我们在基础设施中定义我们感兴趣的 nginx.net.requestpers 之和。

3. 设置指标警报条件。我们想要在变化时警报，而不是一个固定的值，所以我们选择“Change Alert”。我们设置监控为无论何时请求量下降了30％以上时警报。在这里，我们使用一个一分钟的数据窗口来表示 “now” 指标的值，对横跨该间隔内的平均变化和之前 10 分钟的指标值作比较。

4. 自定义通知。如果 NGINX 的请求量下降，我们想要通知我们的团队。在这个例子中，我们将给 ops 团队的聊天室发送通知，并给值班工程师发送短信。在“Say what’s happening”中，我们会为监控器命名，并添加一个伴随该通知的短消息，建议首先开始调查的内容。我们会 @ ops 团队使用的 Slack，并 @pagerduty 将警告发给短信。

5. 保存集成监控。点击页面底部的“Save”按钮。你现在在监控一个关键的 NGINX 工作指标，而当它快速下跌时会给值班工程师发短信。

结论

在这篇文章中，我们谈到了通过整合 NGINX 与 Datadog 来可视化你的关键指标，并当你的网络基础架构有问题时会通知你的团队。

如果你一直使用你自己的 Datadog 账号，你现在应该可以极大的提升你的 web 环境的可视化，也有能力对你的环境、你所使用的模式、和对你的组织最有价值的指标创建自动监控。

如果你还没有 Datadog 帐户，你可以注册免费试用，并开始监视你的基础架构，应用程序和现在的服务。

via: https://www.datadoghq.com/blog/how-to-monitor-nginx-with-datadog/

作者：K Young 译者：strugglingyouth 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出

如何获取你所需要的 NGINX 指标

如何获取需要的指标取决于你正在使用的 NGINX 版本以及你希望看到哪些指标。（参见 如何监控 NGINX（第一篇） 来深入了解NGINX指标。）自由开源的 NGINX 和商业版的 NGINX Plus 都有可以报告指标度量的状态模块，NGINX 也可以在其日志中配置输出特定指标：

指标可用性

指标收集：NGINX（开源版）

开源版的 NGINX 会在一个简单的状态页面上显示几个与服务器状态有关的基本指标，它们由你启用的 HTTP stub status module 所提供。要检查该模块是否已启用，运行以下命令：

nginx -V 2>&1 | grep -o with-http_stub_status_module 

如果你看到终端输出了 httpstubstatus\_module，说明该状态模块已启用。

如果该命令没有输出，你需要启用该状态模块。你可以在从源代码构建 NGINX 时使用 --with-http_stub_status_module 配置参数:

./configure \
… \
--with-http_stub_status_module
make
sudo make install

在验证该模块已经启用或你自己启用它后，你还需要修改 NGINX 配置文件，来给状态页面设置一个本地可访问的 URL（例如： /nginx\_status）：

server {
    location /nginx_status {
        stub_status on;

        access_log off;
        allow 127.0.0.1;
        deny all;
    }
}

注：nginx 配置中的 server 块通常并不放在主配置文件中（例如：/etc/nginx/nginx.conf），而是放在主配置会加载的辅助配置文件中。要找到主配置文件，首先运行以下命令：

nginx -t 

打开列出的主配置文件，在以 http 块结尾的附近查找以 include 开头的行，如：

include /etc/nginx/conf.d/*.conf; 

在其中一个包含的配置文件中，你应该会找到主 server 块，你可以如上所示配置 NGINX 的指标输出。更改任何配置后，通过执行以下命令重新加载配置文件：

nginx -s reload 

现在，你可以浏览状态页看到你的指标：

Active connections: 24 
server accepts handled requests
1156958 1156958 4491319
Reading: 0 Writing: 18 Waiting : 6 

请注意，如果你希望从远程计算机访问该状态页面，则需要将远程计算机的 IP 地址添加到你的状态配置文件的白名单中，在上面的配置文件中的白名单仅有 127.0.0.1。

NGINX 的状态页面是一种快速查看指标状况的简单方法，但当连续监测时，你需要按照标准间隔自动记录该数据。监控工具箱 Nagios 或者 Datadog，以及收集统计信息的服务 collectD 已经可以解析 NGINX 的状态信息了。

指标收集: NGINX Plus

商业版的 NGINX Plus 通过它的 ngxhttpstatus\_module 提供了比开源版 NGINX 更多的指标。NGINX Plus 以字节流的方式提供这些额外的指标，提供了关于上游系统和高速缓存的信息。NGINX Plus 也会报告所有的 HTTP 状态码类型（1XX，2XX，3XX，4XX，5XX）的计数。一个 NGINX Plus 状态报告例子可在此查看：

注：NGINX Plus 在状态仪表盘中的“Active”连接的定义和开源 NGINX 通过 stubstatusmodule 收集的“Active”连接指标略有不同。在 NGINX Plus 指标中，“Active”连接不包括Waiting状态的连接（即“Idle”连接）。

NGINX Plus 也可以输出 JSON 格式的指标，可以用于集成到其他监控系统。在 NGINX Plus 中，你可以看到 给定的上游服务器组的指标和健康状况，或者简单地从上游服务器的单个服务器得到响应代码的计数：

{"1xx":0,"2xx":3483032,"3xx":0,"4xx":23,"5xx":0,"total":3483055}

要启动 NGINX Plus 指标仪表盘，你可以在 NGINX 配置文件的 http 块内添加状态 server 块。 (参见上一节，为收集开源版 NGINX 指标而如何查找相关的配置文件的说明。）例如，要设置一个状态仪表盘 （http://your.ip.address:8080/status.html）和一个 JSON 接口（http://your.ip.address:8080/status），可以添加以下 server 块来设定：

server {
    listen 8080;
    root /usr/share/nginx/html;

    location /status {
        status;
    }

    location = /status.html {
    }
}

当你重新加载 NGINX 配置后，状态页就可以用了：

nginx -s reload 

关于如何配置扩展状态模块，官方 NGINX Plus 文档有 详细介绍 。

指标收集：NGINX 日志

NGINX 的 日志模块 会把可自定义的访问日志写到你配置的指定位置。你可以通过添加或移除变量来自定义日志的格式和包含的数据。要存储详细的日志，最简单的方法是添加下面一行在你配置文件的 server 块中（参见上上节，为收集开源版 NGINX 指标而如何查找相关的配置文件的说明。）：

access_log logs/host.access.log combined;

更改 NGINX 配置文件后，执行如下命令重新加载配置文件：

nginx -s reload

默认包含的 “combined” 的日志格式，会包括一系列关键的数据，如实际的 HTTP 请求和相应的响应代码。在下面的示例日志中，NGINX 记录了请求 /index.html 时的 200（成功）状态码和访问不存在的请求文件 /fail 的 404（未找到）错误。

127.0.0.1 - - [19/Feb/2015:12:10:46 -0500] "GET /index.html HTTP/1.1" 200 612 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.111 Safari 537.36"

127.0.0.1 - - [19/Feb/2015:12:11:05 -0500] "GET /fail HTTP/1.1" 404 570 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.111 Safari/537.36"

你可以通过在 NGINX 配置文件中的 http 块添加一个新的日志格式来记录请求处理时间：

log_format nginx '$remote_addr - $remote_user [$time_local] '
                 '"$request" $status $body_bytes_sent $request_time '
                 '"$http_referer" "$http_user_agent"';

并修改配置文件中 server 块的 access\_log 行：

access_log logs/host.access.log nginx;

重新加载配置文件后（运行 nginx -s reload），你的访问日志将包括响应时间，如下所示。单位为秒，精度到毫秒。在这个例子中，服务器接收到一个对 /big.pdf 的请求时，发送 33973115 字节后返回 206（成功）状态码。处理请求用时 0.202 秒（202毫秒）：

127.0.0.1 - - [19/Feb/2015:15:50:36 -0500] "GET /big.pdf HTTP/1.1" 206 33973115 0.202 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.111 Safari/537.36"

你可以使用各种工具和服务来解析和分析 NGINX 日志。例如，rsyslog 可以监视你的日志，并将其传递给多个日志分析服务；你也可以使用自由开源工具，比如 logstash 来收集和分析日志；或者你可以使用一个统一日志记录层，如 Fluentd 来收集和解析你的 NGINX 日志。

结论

监视 NGINX 的哪一项指标将取决于你可用的工具，以及监控指标所提供的信息是否满足你们的需要。举例来说，错误率的收集是否足够重要到需要你们购买 NGINX Plus ，还是架设一个可以捕获和分析日志的系统就够了？

在 Datadog 中，我们已经集成了 NGINX 和 NGINX Plus，这样你就可以以最小的设置来收集和监控所有 Web 服务器的指标。在本文中了解如何用 NGINX Datadog 来监控 ，并开始 Datadog 的免费试用吧。

via: https://www.datadoghq.com/blog/how-to-collect-nginx-metrics/

作者：K Young 译者：strugglingyouth 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出

NGINX 是什么?

NGINX (发音为 “engine X”) 是一种流行的 HTTP 和反向代理服务器。作为一个 HTTP 服务器，NGINX 可以使用较少的内存非常高效可靠地提供静态内容。作为反向代理，它可以用作多个后端服务器或类似缓存和负载平衡这样的其它应用的单一访问控制点。NGINX 是一个自由开源的产品，并有一个具备更全的功能的叫做 NGINX Plus 的商业版。

NGINX 也可以用作邮件代理和通用的 TCP 代理，但本文并不直接讨论 NGINX 的那些用例的监控。

NGINX 主要指标

通过监控 NGINX 可以 捕获到两类问题：NGINX 本身的资源问题，和出现在你的基础网络设施的其它问题。大多数 NGINX 用户会用到以下指标的监控，包括每秒请求数，它提供了一个由所有最终用户活动组成的上层视图；服务器错误率 ，这表明你的服务器已经多长没有处理看似有效的请求；还有请求处理时间，这说明你的服务器处理客户端请求的总共时长（并且可以看出性能降低或当前环境的其他问题）。

更一般地，至少有三个主要的指标类别来监视：

• 基本活动指标
• 错误指标
• 性能指标

下面我们将分析在每个类别中最重要的 NGINX 指标，以及用一个相当普遍但是值得特别提到的案例来说明：使用 NGINX Plus 作反向代理。我们还将介绍如何使用图形工具或可选择的监控工具来监控所有的指标。

本文引用指标术语来自我们的“监控 101 系列”,，它提供了一个指标收集和警告框架。

基本活跃指标

无论你在怎样的情况下使用 NGINX，毫无疑问你要监视服务器接收多少客户端请求和如何处理这些请求。

NGINX Plus 上像开源 NGINX 一样可以报告基本活跃指标，但它也提供了略有不同的辅助模块。我们首先讨论开源的 NGINX，再来说明 NGINX Plus 提供的其他指标的功能。

NGINX

下图显示了一个客户端连接的过程，以及开源版本的 NGINX 如何在连接过程中收集指标。

Accepts（接受）、Handled（已处理）、Requests（请求数）是一直在增加的计数器。Active（活跃）、Waiting（等待）、Reading（读）、Writing（写）随着请求量而增减。

*严格的来说，丢弃的连接是 一个资源饱和指标，但是因为饱和会导致 NGINX 停止服务（而不是延后该请求），所以，“已丢弃”视作 一个工作指标 比较合适。

NGINX worker 进程接受 OS 的连接请求时 Accepts 计数器增加，而Handled 是当实际的请求得到连接时（通过建立一个新的连接或重新使用一个空闲的）。这两个计数器的值通常都是相同的，如果它们有差别则表明连接被Dropped，往往这是由于资源限制，比如已经达到 NGINX 的worker\_connections的限制。

一旦 NGINX 成功处理一个连接时，连接会移动到Active状态，在这里对客户端请求进行处理：

Active状态

• Waiting: 活跃的连接也可以处于 Waiting 子状态，如果有在此刻没有活跃请求的话。新连接可以绕过这个状态并直接变为到 Reading 状态，最常见的是在使用“accept filter（接受过滤器）” 和 “deferred accept（延迟接受）”时，在这种情况下，NGINX 不会接收 worker 进程的通知，直到它具有足够的数据才开始响应。如果连接设置为 keep-alive ，那么它在发送响应后将处于等待状态。
• Reading: 当接收到请求时，连接离开 Waiting 状态，并且该请求本身使 Reading 状态计数增加。在这种状态下 NGINX 会读取客户端请求首部。请求首部是比较小的，因此这通常是一个快速的操作。
• Writing: 请求被读取之后，其使 Writing 状态计数增加，并保持在该状态，直到响应返回给客户端。这意味着，该请求在 Writing 状态时， 一方面 NGINX 等待来自上游系统的结果（系统放在 NGINX “后面”），另外一方面，NGINX 也在同时响应。请求往往会在 Writing 状态花费大量的时间。

通常，一个连接在同一时间只接受一个请求。在这种情况下，Active 连接的数目 == Waiting 的连接 + Reading 请求 + Writing 。然而，较新的 SPDY 和 HTTP/2 协议允许多个并发请求/响应复用一个连接，所以 Active 可小于 Waiting 的连接、 Reading 请求、Writing 请求的总和。 （在撰写本文时，NGINX 不支持 HTTP/2，但预计到2015年期间将会支持。）

NGINX Plus

正如上面提到的，所有开源 NGINX 的指标在 NGINX Plus 中是可用的，但另外也提供其他的指标。本节仅说明了 NGINX Plus 可用的指标。

Accepted （已接受）、Dropped，总数是不断增加的计数器。Active、 Idle（空闲）和处于 Current（当前）处理阶段的各种状态下的连接或请​​求的当前数量随着请求量而增减。

*严格的来说，丢弃的连接是 一个资源饱和指标，但是因为饱和会导致 NGINX 停止服务（而不是延后该请求），所以，“已丢弃”视作 一个工作指标 比较合适。

当 NGINX Plus worker 进程接受 OS 的连接请求时 Accepted 计数器递增。如果 worker 进程为请求建立连接失败（通过建立一个新的连接或重新使用一个空闲），则该连接被丢弃， Dropped 计数增加。通常连接被丢弃是因为资源限制，如 NGINX Plus 的worker\_connections的限制已经达到。

Active 和 Idle 和如上所述的开源 NGINX 的“active” 和 “waiting”状态是相同的，但是有一点关键的不同：在开源 NGINX 上，“waiting”状态包括在“active”中，而在 NGINX Plus 上“idle”的连接被排除在“active” 计数外。Current 和开源 NGINX 是一样的也是由“reading + writing” 状态组成。

Total 为客户端请求的累积计数。请注意，单个客户端连接可涉及多个请求，所以这个数字可能会比连接的累计次数明显大。事实上，（total / accepted）是每个连接的平均请求数量。

开源 和 Plus 之间指标的不同

提醒指标: 丢弃连接

被丢弃的连接数目等于 Accepts 和 Handled 之差（NGINX 中），或是可直接得到的标准指标（NGINX Plus 中）。在正常情况下，丢弃连接数应该是零。如果在每个单位时间内丢弃连接的速度开始上升，那么应该看看是否资源饱和了。

提醒指标: 每秒请求数

按固定时间间隔采样你的请求数据（开源 NGINX 的requests或者 NGINX Plus 中total） 会提供给你单位时间内（通常是分钟或秒）所接受的请求数量。监测这个指标可以查看进入的 Web 流量尖峰，无论是合法的还是恶意的，或者突然的下降，这通常都代表着出现了问题。每秒请求数若发生急剧变化可以提醒你的环境出现问题了，即使它不能告诉你确切问题的位置所在。请注意，所有的请求都同样计数，无论 URL 是什么。

收集活跃指标

开源的 NGINX 提供了一个简单状态页面来显示基本的服务器指标。该状态信息以标准格式显示，实际上任何图形或监控工具可以被配置去解析这些相关数据，以用于分析、可视化、或提醒。NGINX Plus 提供一个 JSON 接口来供给更多的数据。阅读相关文章“NGINX 指标收集”来启用指标收集的功能。

错误指标

NGINX 错误指标告诉你服务器是否经常返回错误而不是正常工作。客户端错误返回4XX状态码，服务器端错误返回5XX状态码。

提醒指标: 服务器错误率

服务器错误率等于在单位时间（通常为一到五分钟）内5xx错误状态代码的总数除以状态码（1XX，2XX，3XX，4XX，5XX）的总数。如果你的错误率随着时间的推移开始攀升，调查可能的原因。如果突然增加，可能需要采取紧急行动，因为客户端可能收到错误信息。

关于客户端错误的注意事项：虽然监控4XX是很有用的，但从该指标中你仅可以捕捉有限的信息，因为它只是衡量客户的行为而不捕捉任何特殊的 URL。换句话说，4xx出现的变化可能是一个信号，例如网络扫描器正在寻找你的网站漏洞时。

收集错误度量

虽然开源 NGINX 不能马上得到用于监测的错误率，但至少有两种方法可以得到：

• 使用商业支持的 NGINX Plus 提供的扩展状态模块
• 配置 NGINX 的日志模块将响应码写入访问日志

关于这两种方法，请阅读相关文章“NGINX 指标收集”。

性能指标

提醒指标: 请求处理时间

请求处理时间指标记录了 NGINX 处理每个请求的时间，从读到客户端的第一个请求字节到完成请求。较长的响应时间说明问题在上游。

收集处理时间指标

NGINX 和 NGINX Plus 用户可以通过添加 $request\_time 变量到访问日志格式中来捕​​捉处理时间数据。关于配置日志监控的更多细节在NGINX指标收集。

反向代理指标

反向代理是 NGINX 最常见的使用方法之一。商业支持的 NGINX Plus 显示了大量有关后端（或“上游 upstream”）的服务器指标，这些与反向代理设置相关的。本节重点介绍了几个 NGINX Plus 用户可用的关键上游指标。

NGINX Plus 首先将它的上游指标按组分开，然后是针对单个服务器的。因此，例如，你的反向代理将请求分配到五个上游的 Web 服务器上，你可以一眼看出是否有单个服务器压力过大，也可以看出上游组中服务器的健康状况，以确保良好的响应时间。

活跃指标

每上游服务器的活跃连接的数量可以帮助你确认反向代理是否正确的分配工作到你的整个服务器组上。如果你正在使用 NGINX 作为负载均衡器，任何一台服务器处理的连接数的明显偏差都可能表明服务器正在努力消化请求，或者是你配置使用的负载均衡的方法（例如round-robin 或 IP hashing）不是最适合你流量模式的。

错误指标

错误指标，上面所说的高于5XX（服务器错误）状态码，是监控指标中有价值的一个，尤其是响应码部分。 NGINX Plus 允许你轻松地提取每个上游服务器的 5xx 错误代码的数量，以及响应的总数量，以此来确定某个特定服务器的错误率。

可用性指标

对于 web 服务器的运行状况，还有另一种角度，NGINX 可以通过每个组中当前可用服务器的总量很方便监控你的上游组的健康。在一个大的反向代理上，你可能不会非常关心其中一个服务器的当前状态，就像你只要有可用的服务器组能够处理当前的负载就行了。但监视上游组内的所有工作的服务器总量可为判断 Web 服务器的健康状况提供一个更高层面的视角。

收集上游指标

NGINX Plus 上游指标显示在内部 NGINX Plus 的监控仪表盘上，并且也可通过一个JSON 接口来服务于各种外部监控平台。在我们的相关文章“NGINX指标收集”中有个例子。

结论

在这篇文章中，我们已经谈到了一些有用的指标，你可以使用表格来监控 NGINX 服务器。如果你是刚开始使用 NGINX，监控下面提供的大部分或全部指标，可以让你很好的了解你的网络基础设施的健康和活跃程度：

• 已丢弃的连接
• 每秒请求数
• 服务器错误率
• 请求处理数据

最终，你会学到更多，更专业的衡量指标，尤其是关于你自己基础设施和使用情况的。当然，监控哪一项指标将取决于你可用的工具。参见相关的文章来逐步指导你的指标收集，不管你使用 NGINX 还是 NGINX Plus。

在 Datadog 中，我们已经集成了 NGINX 和 NGINX Plus，这样你就可以以最少的设置来收集和监控所有 Web 服务器的指标。 在本文中了解如何用 NGINX Datadog来监控，并开始免费试用 Datadog吧。

诚谢

在文章发表之前非常感谢 NGINX 团队审阅这篇，并提供重要的反馈和说明。

via: https://www.datadoghq.com/blog/how-to-monitor-nginx/

作者：K Young 译者：strugglingyouth 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出

Nginx （engine-x）是一个开源的高性能 HTTP 服务器、反向代理和 IMAP/POP3 代理服务器。nginx 杰出的功能有：稳定、丰富的功能集、简单的配置和低资源消耗。nginx 被用于一些高性能网站并在站长之间变得越来越流行。本教程会从源码构建一个带有 google paespeed 模块的用于 Ubuntu 15.04 的 nginx .deb 安装包。

pagespeed 是一个由 google 开发的 web 服务器模块来加速网站响应时间、优化 html 和减少页面加载时间。ngx\_pagespeed 的功能如下：

• 图像优化：去除元数据、动态缩放、重压缩。
• CSS 与 JavaScript 压缩、串联、内联、外联。
• 小资源内联
• 图像与 JavaScript 延迟加载
• HTML 重写
• 缓存生命期插件

更多请见 https://developers.google.com/speed/pagespeed/module/。

前置要求

• Ubuntu Server 15.04 64位
• root 权限

本篇我们将要：

• 安装必备软件包
• 安装带 ngx\_pagespeed 的 nginx
• 测试

安装必备包

sudo apt-get install dpkg-dev build-essential zlib1g-dev libpcre3 libpcre3-dev

安装带 ngx\_pagespeed 的 nginx

第一步 - 添加nginx仓库

vim /etc/apt/sources.list.d/nginx.list

加入下面的行：

deb http://nginx.org/packages/ubuntu/ trusty nginx
deb-src http://nginx.org/packages/ubuntu/ trusty nginx

更新仓库：

sudo apt-get update

注意：如果你看到信息：GPG error [...] NO\_PUBKEY [...] 等等

请添加key：

sudo sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys KEYNUMBER
sudo apt-get update

第二步 - 从仓库下载 nginx 1.8

sudo su
cd ~
mkdir -p ~/new/nginx_source/
cd ~/new/nginx_source/
apt-get source nginx
apt-get build-dep nginx

第三步 - 下载 Pagespeed

cd ~
mkdir -p ~/new/ngx_pagespeed/
cd ~/new/ngx_pagespeed/
ngx_version=1.9.32.3
wget https://github.com/pagespeed/ngx_pagespeed/archive/release-${ngx_version}-beta.zip
unzip release-${ngx_version}-beta.zip

cd ngx_pagespeed-release-1.9.32.3-beta/
wget https://dl.google.com/dl/page-speed/psol/${ngx_version}.tar.gz
tar -xzf 1.9.32.3.tar.gz

第四步 - 配置 nginx 来编译 Pagespeed

cd ~/new/nginx_source/nginx-1.8.0/debin/
vim rules

在两处 CFLAGS .configure 下添加模块：

--add-module=../../ngx_pagespeed/ngx_pagespeed-release-1.9.32.3-beta \

第五步 - 打包 nginx 软件包并安装

cd ~/new/nginx_source/nginx-1.8.0/
dpkg-buildpackage -b

dpkg-buildpackage 会编译 ~/new/ngix\_source/ 为 nginx.deb。打包完成后，看一下目录：

cd ~/new/ngix_source/
ls

接着安装 nginx。

dpkg -i nginx_1.8.0-1~trusty_amd64.deb

测试

运行 nginx -V 测试 nginx 是否已经自带 ngx\_pagespeed。

nginx -V

总结

稳定、快速、开源的 nginx 支持许多不同的优化模块。这其中之一是 google 开发的‘pagespeed’。不像 apache，nginx 模块不是动态加载的，因此你必须在编译之前就选择好需要的模块。

via: https://www.howtoforge.com/tutorial/how-to-install-nginx-and-google-pagespeed-on-ubuntu-15-04/

作者：Muhammad Arul 译者：geekpi 校对：wxy

本文由 LCTT 原创翻译，Linux中国 荣誉推出