K Young 发布的文章

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

NGINX dashboard

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

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

配置 NGINX

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

整合 Datadog 和 NGINX

安装 Datadog 代理

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

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

Datadog infrastructure list

配置 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”按钮。

Install integration

指标!

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

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

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

Clone dash

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

NGINX 指标警告

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

监控 NGINX 吞吐量

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

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

NGINX metric monitor

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

NGINX metric

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

NGINX metric change alert

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

NGINX metric notification

  1. 保存集成监控。点击页面底部的“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 PlusNGINX 日志
accepts(接受) / accepted(已接受)xx
handled(已处理)xx
dropped(已丢弃)xx
active(活跃)xx
requests (请求数)/ total(全部请求数)xx
4xx 代码 xx
5xx 代码 xx
request time(请求处理时间) x

指标收集: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 status board

注: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 如何在连接过程中收集指标。

connection, request states

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

名称描述指标类型
Accepts(接受)NGINX 所接受的客户端连接数资源: 功能
Handled(已处理)成功的客户端连接数资源: 功能
Active(活跃)当前活跃的客户端连接数资源: 功能
Dropped(已丢弃,计算得出)丢弃的连接数(接受 - 已处理)工作:错误*
Requests(请求数)客户端请求数工作:吞吐量

*严格的来说,丢弃的连接是 一个资源饱和指标,但是因为饱和会导致 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 可用的指标。

connection, request states

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

名称描述指标类型
Accepted(已接受)NGINX 所接受的客户端连接数资源: 功能
Dropped(已丢弃)丢弃的连接数(接受 - 已处理)工作:错误*
Active(活跃)当前活跃的客户端连接数资源: 功能
Idle(空闲)没有当前请求的客户端连接资源: 功能
Total(全部请求数)客户端请求数工作:吞吐量

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

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

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

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

开源 和 Plus 之间指标的不同

NGINX (开源)NGINX Plus
acceptsaccepted
dropped 通过计算得来dropped 直接得到
reading + writingcurrent
waitingidle
active (包括 “waiting”状态)active (排除 “idle” 状态)
requeststotal

提醒指标: 丢弃连接

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

Dropped connections

提醒指标: 每秒请求数

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

Requests per second

收集活跃指标

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

错误指标

名称描述指标类型可用于
4xx 代码客户端错误计数工作:错误NGINX 日志, NGINX Plus
5xx 代码服务器端错误计数工作:错误NGINX 日志, NGINX Plus

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

提醒指标: 服务器错误率

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

Server error rate

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

收集错误度量

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

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

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

性能指标

名称描述指标类型可用于
request time (请求处理时间)处理每个请求的时间,单位为秒工作:性能NGINX 日志

提醒指标: 请求处理时间

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

收集处理时间指标

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

反向代理指标

名称描述指标类型可用于
上游服务器的活跃链接当前活跃的客户端连接资源:功能NGINX Plus
上游服务器的 5xx 错误代码服务器错误工作:错误NGINX Plus
每个上游组的可用服务器服务器传递健康检查资源:可用性NGINX Plus

反向代理是 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中国 荣誉推出