分类 系统运维 下的文章

RAID 的意思是廉价磁盘冗余阵列(Redundant Array of Inexpensive Disks),但现在它被称为独立磁盘冗余阵列(Redundant Array of Independent Drives)。早先一个容量很小的磁盘都是非常昂贵的,但是现在我们可以很便宜的买到一个更大的磁盘。Raid 是一系列放在一起,成为一个逻辑卷的磁盘集合。

RAID in Linux

在 Linux 中理解 RAID 设置

RAID 包含一组或者一个集合甚至一个阵列。使用一组磁盘结合驱动器组成 RAID 阵列或 RAID 集。将至少两个磁盘连接到一个 RAID 控制器,而成为一个逻辑卷,也可以将多个驱动器放在一个组中。一组磁盘只能使用一个 RAID 级别。使用 RAID 可以提高服务器的性能。不同 RAID 的级别,性能会有所不同。它通过容错和高可用性来保存我们的数据。

这个系列被命名为“在 Linux 下使用 RAID”,分为9个部分,包括以下主题:

这是9篇系列教程的第1部分,在这里我们将介绍 RAID 的概念和 RAID 级别,这是在 Linux 中构建 RAID 需要理解的。

软件 RAID 和硬件 RAID

软件 RAID 的性能较低,因为其使用主机的资源。 需要加载 RAID 软件以从软件 RAID 卷中读取数据。在加载 RAID 软件前,操作系统需要引导起来才能加载 RAID 软件。在软件 RAID 中无需物理硬件。零成本投资。

硬件 RAID 的性能较高。他们采用 PCI Express 卡物理地提供有专用的 RAID 控制器。它不会使用主机资源。他们有 NVRAM 用于缓存的读取和写入。缓存用于 RAID 重建时,即使出现电源故障,它会使用后备的电池电源保持缓存。对于大规模使用是非常昂贵的投资。

硬件 RAID 卡如下所示:

Hardware RAID

硬件 RAID

重要的 RAID 概念

  • 校验方式用在 RAID 重建中从校验所保存的信息中重新生成丢失的内容。 RAID 5,RAID 6 基于校验。
  • 条带化是将切片数据随机存储到多个磁盘。它不会在单个磁盘中保存完整的数据。如果我们使用2个磁盘,则每个磁盘存储我们的一半数据。
  • 镜像被用于 RAID 1 和 RAID 10。镜像会自动备份数据。在 RAID 1 中,它会保存相同的内容到其他盘上。
  • 热备份只是我们的服务器上的一个备用驱动器,它可以自动更换发生故障的驱动器。在我们的阵列中,如果任何一个驱动器损坏,热备份驱动器会自动用于重建 RAID。
  • 是 RAID 控制器每次读写数据时的最小单位,最小 4KB。通过定义块大小,我们可以增加 I/O 性能。

RAID有不同的级别。在这里,我们仅列出在真实环境下的使用最多的 RAID 级别。

  • RAID0 = 条带化
  • RAID1 = 镜像
  • RAID5 = 单磁盘分布式奇偶校验
  • RAID6 = 双磁盘分布式奇偶校验
  • RAID10 = 镜像 + 条带。(嵌套RAID)

RAID 在大多数 Linux 发行版上使用名为 mdadm 的软件包进行管理。让我们先对每个 RAID 级别认识一下。

RAID 0 / 条带化

条带化有很好的性能。在 RAID 0(条带化)中数据将使用切片的方式被写入到磁盘。一半的内容放在一个磁盘上,另一半内容将被写入到另一个磁盘。

假设我们有2个磁盘驱动器,例如,如果我们将数据“TECMINT”写到逻辑卷中,“T”将被保存在第一盘中,“E”将保存在第二盘,'C'将被保存在第一盘,“M”将保存在第二盘,它会一直继续此循环过程。(LCTT 译注:实际上不可能按字节切片,是按数据块切片的。)

在这种情况下,如果驱动器中的任何一个发生故障,我们就会丢失数据,因为一个盘中只有一半的数据,不能用于重建 RAID。不过,当比较写入速度和性能时,RAID 0 是非常好的。创建 RAID 0(条带化)至少需要2个磁盘。如果你的数据是非常宝贵的,那么不要使用此 RAID 级别。

  • 高性能。
  • RAID 0 中容量零损失。
  • 零容错。
  • 写和读有很高的性能。

RAID 1 / 镜像化

镜像也有不错的性能。镜像可以对我们的数据做一份相同的副本。假设我们有两个2TB的硬盘驱动器,我们总共有4TB,但在镜像中,但是放在 RAID 控制器后面的驱动器形成了一个逻辑驱动器,我们只能看到这个逻辑驱动器有2TB。

当我们保存数据时,它将同时写入这两个2TB驱动器中。创建 RAID 1(镜像化)最少需要两个驱动器。如果发生磁盘故障,我们可以通过更换一个新的磁盘恢复 RAID 。如果在 RAID 1 中任何一个磁盘发生故障,我们可以从另一个磁盘中获取相同的数据,因为另外的磁盘中也有相同的数据。所以是零数据丢失。

  • 良好的性能。
  • 总容量丢失一半可用空间。
  • 完全容错。
  • 重建会更快。
  • 写性能变慢。
  • 读性能变好。
  • 能用于操作系统和小规模的数据库。

RAID 5 / 分布式奇偶校验

RAID 5 多用于企业级。 RAID 5 的以分布式奇偶校验的方式工作。奇偶校验信息将被用于重建数据。它从剩下的正常驱动器上的信息来重建。在驱动器发生故障时,这可以保护我们的数据。

假设我们有4个驱动器,如果一个驱动器发生故障而后我们更换发生故障的驱动器后,我们可以从奇偶校验中重建数据到更换的驱动器上。奇偶校验信息存储在所有的4个驱动器上,如果我们有4个 1TB 的驱动器。奇偶校验信息将被存储在每个驱动器的256G中,而其它768GB是用户自己使用的。单个驱动器故障后,RAID 5 依旧正常工作,如果驱动器损坏个数超过1个会导致数据的丢失。

  • 性能卓越
  • 读速度将非常好。
  • 写速度处于平均水准,如果我们不使用硬件 RAID 控制器,写速度缓慢。
  • 从所有驱动器的奇偶校验信息中重建。
  • 完全容错。
  • 1个磁盘空间将用于奇偶校验。
  • 可以被用在文件服务器,Web服务器,非常重要的备份中。

RAID 6 双分布式奇偶校验磁盘

RAID 6 和 RAID 5 相似但它有两个分布式奇偶校验。大多用在大数量的阵列中。我们最少需要4个驱动器,即使有2个驱动器发生故障,我们依然可以更换新的驱动器后重建数据。

它比 RAID 5 慢,因为它将数据同时写到4个驱动器上。当我们使用硬件 RAID 控制器时速度就处于平均水准。如果我们有6个的1TB驱动器,4个驱动器将用于数据保存,2个驱动器将用于校验。

  • 性能不佳。
  • 读的性能很好。
  • 如果我们不使用硬件 RAID 控制器写的性能会很差。
  • 从两个奇偶校验驱动器上重建。
  • 完全容错。
  • 2个磁盘空间将用于奇偶校验。
  • 可用于大型阵列。
  • 用于备份和视频流中,用于大规模。

RAID 10 / 镜像+条带

RAID 10 可以被称为1 + 0或0 +1。它将做镜像+条带两个工作。在 RAID 10 中首先做镜像然后做条带。在 RAID 01 上首先做条带,然后做镜像。RAID 10 比 01 好。

假设,我们有4个驱动器。当我逻辑卷上写数据时,它会使用镜像和条带的方式将数据保存到4个驱动器上。

如果我在 RAID 10 上写入数据“TECMINT”,数据将使用如下方式保存。首先将“T”同时写入两个磁盘,“E”也将同时写入另外两个磁盘,所有数据都写入两块磁盘。这样可以将每个数据复制到另外的磁盘。

同时它将使用 RAID 0 方式写入数据,遵循将“T”写入第一组盘,“E”写入第二组盘。再次将“C”写入第一组盘,“M”到第二组盘。

  • 良好的读写性能。
  • 总容量丢失一半的可用空间。
  • 容错。
  • 从副本数据中快速重建。
  • 由于其高性能和高可用性,常被用于数据库的存储中。

结论

在这篇文章中,我们已经了解了什么是 RAID 和在实际环境大多采用哪个级别的 RAID。希望你已经学会了上面所写的。对于 RAID 的构建必须了解有关 RAID 的基本知识。以上内容可以基本满足你对 RAID 的了解。

在接下来的文章中,我将介绍如何设置和使用各种级别创建 RAID,增加 RAID 组(阵列)和驱动器故障排除等。


via: http://www.tecmint.com/understanding-raid-setup-in-linux/

作者:Babin Lonston 译者:strugglingyouth 校对:wxy

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

Darkstat是一个简易的,基于网页的流量分析程序。它可以在主流的操作系统如Linux、Solaris、MAC、AIX上工作。它以守护进程的形式持续工作在后台,不断地嗅探网络数据,以简单易懂的形式展现在它的网页上。它可以为主机生成流量报告,识别特定的主机上哪些端口是打开的,它兼容IPv6。让我们看下如何在Linux中安装和配置它。

在Linux中安装配置Darkstat

在Fedora/CentOS/RHEL中安装Darkstat:

要在Fedora/RHEL和CentOS中安装,运行下面的命令。

sudo yum install darkstat

在Ubuntu/Debian中安装Darkstat:

运行下面的命令在Ubuntu和Debian中安装。

sudo apt-get install darkstat

恭喜你,Darkstat已经在你的Linux中安装了。

配置 Darkstat

为了正确运行这个程序,我们需要执行一些基本的配置。运行下面的命令用gedit编辑器打开/etc/darkstat/init.cfg文件。

sudo gedit /etc/darkstat/init.cfg

编辑 Darkstat

修改START\_DARKSTAT这个参数为yes,并在“INTERFACE”中提供你的网络接口。确保取消了DIR、PORT、BINDIP和LOCAL这些参数的注释。如果你希望绑定Darkstat到特定的IP,在BINDIP参数中提供它。

启动Darkstat守护进程

安装并配置完Darkstat后,运行下面的命令启动它的守护进程。

sudo /etc/init.d/darkstat start

Restarting Darkstat

你可以用下面的命令来在开机时启动Darkstat:

chkconfig darkstat on

打开浏览器并打开http://localhost:666,它会显示Darkstat的网页界面。使用这个工具来分析你的网络流量。

Darkstat

总结

它是一个占用很少内存的轻量级工具。这个工具流行的原因是简易、易于配置使用。这是一个对系统管理员而言必须拥有的程序。


via: http://linuxpitstop.com/install-darkstat-on-ubuntu-linux/

作者:Aun 译者:geekpi 校对: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中国 荣誉推出

Chef是面对IT专业人员的一款配置管理和自动化工具,它可以配置和管理你的基础设施(设备),无论它在本地还是在云上。它可以用于加速应用部署并协调多个系统管理员和开发人员的工作,这包括可支持大量的客户群的成百上千的服务器和程序。chef最有用的是让基础设施变成代码。一旦你掌握了Chef,你可以获得自动化管理你的云端基础设施或者终端用户的一流的网络IT支持。

下面是我们将要在本篇中要设置和配置Chef的主要组件。

安装Chef的要求和版本

我们将在下面的基础环境下设置Chef配置管理系统。

管理和配置工具:Chef
基础操作系统Ubuntu 14.04.1 LTS (x86\_64)
Chef ServerVersion 12.1.0
Chef ManageVersion 1.17.0
Chef Development KitVersion 0.6.2
内存和CPU4 GB , 2.0+2.0 GHz

Chef服务端的安装和配置

Chef服务端是核心组件,它存储配置以及其他和工作站交互的配置数据。让我们在他们的官网https://www.chef.io下载最新的安装文件。

我使用下面的命令来下载和安装它。

1) 下载Chef服务端

root@ubuntu-14-chef:/tmp# wget https://web-dl.packagecloud.io/chef/stable/packages/ubuntu/trusty/chef-server-core_12.1.0-1_amd64.deb

2) 安装Chef服务端

root@ubuntu-14-chef:/tmp# dpkg -i chef-server-core_12.1.0-1_amd64.deb

3) 重新配置Chef服务端

现在运行下面的命令来启动所有的chef服务端服务,这一步也许会花费一些时间,因为它需要由许多不同一起工作的服务组成一个可正常运作的系统。

root@ubuntu-14-chef:/tmp# chef-server-ctl reconfigure

chef服务端启动命令'chef-server-ctl reconfigure'需要运行两次,这样就会在安装后看到这样的输出。

Chef Client finished, 342/350 resources updated in 113.71139964 seconds
opscode Reconfigured!

4) 重启系统

安装完成后重启系统使系统能最好的工作,不然我们或许会在创建用户的时候看到下面的SSL连接错误。

ERROR: Errno::ECONNRESET: Connection reset by peer - SSL_connect

5) 创建新的管理员

运行下面的命令来创建一个新的管理员账户及其配置。创建过程中,用户的RSA私钥会自动生成,它需要保存到一个安全的地方。--file选项会保存RSA私钥到指定的路径下。

root@ubuntu-14-chef:/tmp# chef-server-ctl user-create kashi kashi kashi [email protected] kashi123 --filename /root/kashi.pem

Chef服务端的管理设置

Chef Manage是一个针对企业级Chef用户的管理控制台,它提供了可视化的web用户界面,可以管理节点、数据包、规则、环境、Cookbook 和基于角色的访问控制(RBAC)。

1) 下载Chef Manage

从官网复制链接并下载chef manage的安装包。

root@ubuntu-14-chef:~# wget https://web-dl.packagecloud.io/chef/stable/packages/ubuntu/trusty/opscode-manage_1.17.0-1_amd64.deb

2) 安装Chef Manage

使用下面的命令在root的家目录下安装它。

root@ubuntu-14-chef:~# chef-server-ctl install opscode-manage --path /root

3) 重启Chef Manage和服务端

安装完成后我们需要运行下面的命令来重启chef manage和服务端。

root@ubuntu-14-chef:~# opscode-manage-ctl reconfigure
root@ubuntu-14-chef:~# chef-server-ctl reconfigure

Chef Manage网页控制台

我们可以使用localhost或它的域名来访问网页控制台,并用已经创建的管理员登录

chef amanage

1) Chef Manage创建新的组织

你或许被要求创建新的组织,或者也可以接受其他组织的邀请。如下所示,使用缩写和全名来创建一个新的组织。

Create Org

2) 用命令行创建新的组织

我们同样也可以运行下面的命令来创建新的组织。

root@ubuntu-14-chef:~# chef-server-ctl org-create linux Linoxide Linux Org. --association_user kashi --filename linux.pem

设置工作站

我们已经完成安装chef服务端,现在我们可以开始创建任何recipes(基础配置元素)、cookbooks(基础配置集)、attributes(节点属性),以及做一些其他修改。

1) 在Chef服务端上创建新的用户和组织

为了设置工作站,我们需要用命令行创建一个新的用户和组织。

root@ubuntu-14-chef:~# chef-server-ctl user-create bloger Bloger Kashif [email protected] bloger123 --filename bloger.pem

root@ubuntu-14-chef:~# chef-server-ctl org-create blogs Linoxide Blogs Inc. --association_user bloger --filename blogs.pem

2) 下载工作站入门套件

在工作站的网页控制台中下载并保存入门套件,它用于与服务端协同工作

Starter Kit

3) 下载套件后,点击"Proceed"

starter kit

用于工作站的Chef开发套件设置

Chef开发套件是一款包含开发chef所需的所有工具的软件包。它捆绑了由Chef开发的带Chef客户端的工具。

1) 下载 Chef DK

我们可以从它的官网链接中下载开发包,并选择操作系统来下载chef开发包。

Chef DK

复制链接并用wget下载

root@ubuntu-15-WKS:~# wget https://opscode-omnibus-packages.s3.amazonaws.com/ubuntu/12.04/x86_64/chefdk_0.6.2-1_amd64.deb

2) Chef开发套件安装

使用dpkg命令安装开发套件

root@ubuntu-15-WKS:~# dpkg -i chefdk_0.6.2-1_amd64.deb

3) Chef DK 验证

使用下面的命令验证客户端是否已经正确安装。

root@ubuntu-15-WKS:~# chef verify

Running verification for component 'berkshelf'
Running verification for component 'test-kitchen'
Running verification for component 'chef-client'
Running verification for component 'chef-dk'
Running verification for component 'chefspec'
Running verification for component 'rubocop'
Running verification for component 'fauxhai'
Running verification for component 'knife-spork'
Running verification for component 'kitchen-vagrant'
Running verification for component 'package installation'
Running verification for component 'openssl'
..............
---------------------------------------------
Verification of component 'rubocop' succeeded.
Verification of component 'knife-spork' succeeded.
Verification of component 'openssl' succeeded.
Verification of component 'berkshelf' succeeded.
Verification of component 'chef-dk' succeeded.
Verification of component 'fauxhai' succeeded.
Verification of component 'test-kitchen' succeeded.
Verification of component 'kitchen-vagrant' succeeded.
Verification of component 'chef-client' succeeded.
Verification of component 'chefspec' succeeded.
Verification of component 'package installation' succeeded.

4) 连接Chef服务端

我们将创建 ~/.chef目录,并从chef服务端复制两个用户和组织的pem文件到该目录下。

root@ubuntu-14-chef:~# scp bloger.pem blogs.pem kashi.pem linux.pem [email protected]:/.chef/

[email protected]'s password:
bloger.pem 100% 1674 1.6KB/s 00:00
blogs.pem 100% 1674 1.6KB/s 00:00
kashi.pem 100% 1678 1.6KB/s 00:00
linux.pem 100% 1678 1.6KB/s 00:00

5) 编辑配置来管理chef环境 **

现在使用下面的内容创建"~/.chef/knife.rb"。

root@ubuntu-15-WKS:/.chef# vim knife.rb
current_dir = File.dirname(__FILE__)

log_level :info
log_location STDOUT
node_name "kashi"
client_key "#{current_dir}/kashi.pem"
validation_client_name "kashi-linux"
validation_key "#{current_dir}/linux.pem"
chef_server_url "https://172.25.10.173/organizations/linux"
cache_type 'BasicFile'
cache_options( :path => "#{ENV['HOME']}/.chef/checksums" )
cookbook_path ["#{current_dir}/../cookbooks"]

创建knife.rb中指定的“~/cookbooks”文件夹。

root@ubuntu-15-WKS:/# mkdir cookbooks

6) 测试Knife配置

运行“knife user list”和“knife client list”来验证knife是否工作。

root@ubuntu-15-WKS:/.chef# knife user list

第一次运行的时候可能会看到下面的错误,这是因为工作站上还没有chef服务端的SSL证书。

ERROR: SSL Validation failure connecting to host: 172.25.10.173 - SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed
ERROR: Could not establish a secure connection to the server.
Use `knife ssl check` to troubleshoot your SSL configuration.
If your Chef Server uses a self-signed certificate, you can use
`knife ssl fetch` to make knife trust the server's certificates.

要解决上面的命令的错误,运行下面的命令来获取ssl证书,并重新运行knife user和client list,这时候应该就可以了。

root@ubuntu-15-WKS:/.chef# knife ssl fetch
WARNING: Certificates from 172.25.10.173 will be fetched and placed in your trusted_cert
directory (/.chef/trusted_certs).

knife没有办法验证这些是否是有效的证书。你应该在下载时验证这些证书的真实性。

在/.chef/trusted\_certs/ubuntu-14-chef\_test\_com.crt下面添加ubuntu-14-chef.test.com的证书。

在上面的命令取得ssl证书后,接着运行下面的命令。

root@ubuntu-15-WKS:/.chef#knife client list
kashi-linux

配置与chef服务端交互的新节点

节点是执行所有基础设施自动化的chef客户端。因此,在配置完chef-server和knife工作站后,通过配置与chef-server交互的新节点,来将新的服务端添加到我们的chef环境下。

我们使用下面的命令来添加与chef服务端协同工作的新节点。

root@ubuntu-15-WKS:~# knife bootstrap 172.25.10.170 --ssh-user root --ssh-password kashi123 --node-name mydns

Doing old-style registration with the validation key at /.chef/linux.pem...
Delete your validation key in order to use your user credentials instead

Connecting to 172.25.10.170
172.25.10.170 Installing Chef Client...
172.25.10.170 --2015-07-04 22:21:16-- https://www.opscode.com/chef/install.sh
172.25.10.170 Resolving www.opscode.com (www.opscode.com)... 184.106.28.91
172.25.10.170 Connecting to www.opscode.com (www.opscode.com)|184.106.28.91|:443... connected.
172.25.10.170 HTTP request sent, awaiting response... 200 OK
172.25.10.170 Length: 18736 (18K) [application/x-sh]
172.25.10.170 Saving to: ‘STDOUT’
172.25.10.170
100%[======================================>] 18,736 --.-K/s in 0s
172.25.10.170
172.25.10.170 2015-07-04 22:21:17 (200 MB/s) - written to stdout [18736/18736]
172.25.10.170
172.25.10.170 Downloading Chef 12 for ubuntu...
172.25.10.170 downloading https://www.opscode.com/chef/metadata?v=12&prerelease=false&nightlies=false&p=ubuntu&pv=14.04&m=x86_64
172.25.10.170 to file /tmp/install.sh.26024/metadata.txt
172.25.10.170 trying wget...

之后我们可以在knife节点列表下看到创建的新节点,它也会在新节点下创建新的客户端。

root@ubuntu-15-WKS:~# knife node list
mydns

类似地我们只要通过给上面的knife命令提供ssh证书,就可以在chef设施上创建多个节点。

总结

本篇我们学习了chef管理工具,并通过安装和配置设置基本了解了它的组件。我希望你在学习安装和配置Chef服务端以及它的工作站和客户端节点中获得乐趣。


via: http://linoxide.com/ubuntu-how-to/install-configure-chef-ubuntu-14-04-15-04/

作者:Kashif Siddique 译者:geekpi 校对:wxy

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

你在家里运行着一台 Linux 服务器,它放在一个 NAT 路由器或者限制性防火墙后面。现在你想在外出时用 SSH 登录到这台服务器。你如何才能做到呢?SSH 端口转发当然是一种选择。但是,如果你需要处理多级嵌套的 NAT 环境,端口转发可能会变得非常棘手。另外,在多种 ISP 特定条件下可能会受到干扰,例如阻塞转发端口的限制性 ISP 防火墙、或者在用户间共享 IPv4 地址的运营商级 NAT。

什么是反向 SSH 隧道?

SSH 端口转发的一种替代方案是 反向 SSH 隧道。反向 SSH 隧道的概念非常简单。使用这种方案,在你的受限的家庭网络之外你需要另一台主机(所谓的“中继主机”),你能从当前所在地通过 SSH 登录到它。你可以用有公网 IP 地址的 VPS 实例 配置一个中继主机。然后要做的就是从你的家庭网络服务器中建立一个到公网中继主机的永久 SSH 隧道。有了这个隧道,你就可以从中继主机中连接“回”家庭服务器(这就是为什么称之为 “反向” 隧道)。不管你在哪里、你的家庭网络中的 NAT 或 防火墙限制多么严格,只要你可以访问中继主机,你就可以连接到家庭服务器。

在 Linux 上设置反向 SSH 隧道

让我们来看看怎样创建和使用反向 SSH 隧道。我们做如下假设:我们会设置一个从家庭服务器(homeserver)到中继服务器(relayserver)的反向 SSH 隧道,然后我们可以通过中继服务器从客户端计算机(clientcomputer) SSH 登录到家庭服务器。本例中的中继服务器 的公网 IP 地址是 1.1.1.1。

在家庭服务器上,按照以下方式打开一个到中继服务器的 SSH 连接。

homeserver~$ ssh -fN -R 10022:localhost:22 [email protected]

这里端口 10022 是任何你可以使用的端口数字。只需要确保中继服务器上不会有其它程序使用这个端口。

“-R 10022:localhost:22” 选项定义了一个反向隧道。它转发中继服务器 10022 端口的流量到家庭服务器的 22 号端口。

用 “-fN” 选项,当你成功通过 SSH 服务器验证时 SSH 会进入后台运行。当你不想在远程 SSH 服务器执行任何命令,就像我们的例子中只想转发端口的时候非常有用。

运行上面的命令之后,你就会回到家庭主机的命令行提示框中。

登录到中继服务器,确认其 127.0.0.1:10022 绑定到了 sshd。如果是的话就表示已经正确设置了反向隧道。

relayserver~$ sudo netstat -nap | grep 10022

tcp      0    0 127.0.0.1:10022          0.0.0.0:*               LISTEN      8493/sshd           

现在就可以从任何其它计算机(客户端计算机)登录到中继服务器,然后按照下面的方法访问家庭服务器。

relayserver~$ ssh -p 10022 homeserver_user@localhost

需要注意的一点是你在上面为localhost输入的 SSH 登录/密码应该是家庭服务器的,而不是中继服务器的,因为你是通过隧道的本地端点登录到家庭服务器,因此不要错误输入中继服务器的登录/密码。成功登录后,你就在家庭服务器上了。

通过反向 SSH 隧道直接连接到网络地址变换后的服务器

上面的方法允许你访问 NAT 后面的 家庭服务器,但你需要登录两次:首先登录到 中继服务器,然后再登录到家庭服务器。这是因为中继服务器上 SSH 隧道的端点绑定到了回环地址(127.0.0.1)。

事实上,有一种方法可以只需要登录到中继服务器就能直接访问NAT之后的家庭服务器。要做到这点,你需要让中继服务器上的 sshd 不仅转发回环地址上的端口,还要转发外部主机的端口。这通过指定中继服务器上运行的 sshd 的 GatewayPorts 实现。

打开中继服务器的 /etc/ssh/sshd\_config 并添加下面的行。

relayserver~$ vi /etc/ssh/sshd_config

GatewayPorts clientspecified

重启 sshd。

基于 Debian 的系统:

relayserver~$ sudo /etc/init.d/ssh restart

基于红帽的系统:

relayserver~$ sudo systemctl restart sshd

现在在家庭服务器中按照下面方式初始化一个反向 SSH 隧道。

homeserver~$ ssh -fN -R 1.1.1.1:10022:localhost:22 [email protected]

登录到中继服务器然后用 netstat 命令确认成功建立的一个反向 SSH 隧道。

relayserver~$ sudo netstat -nap | grep 10022

tcp      0      0 1.1.1.1:10022     0.0.0.0:*           LISTEN      1538/sshd: dev  

不像之前的情况,现在隧道的端点是 1.1.1.1:10022(中继服务器的公网 IP 地址),而不是 127.0.0.1:10022。这就意味着从外部主机可以访问隧道的另一端。

现在在任何其它计算机(客户端计算机),输入以下命令访问网络地址变换之后的家庭服务器。

clientcomputer~$ ssh -p 10022 [email protected]

在上面的命令中,1.1.1.1 是中继服务器的公共 IP 地址,homeserver\_user必须是家庭服务器上的用户账户。这是因为你真正登录到的主机是家庭服务器,而不是中继服务器。后者只是中继你的 SSH 流量到家庭服务器。

在 Linux 上设置一个永久反向 SSH 隧道

现在你已经明白了怎样创建一个反向 SSH 隧道,然后把隧道设置为 “永久”,这样隧道启动后就会一直运行(不管临时的网络拥塞、SSH 超时、中继主机重启,等等)。毕竟,如果隧道不是一直有效,你就不能可靠的登录到你的家庭服务器。

对于永久隧道,我打算使用一个叫 autossh 的工具。正如名字暗示的,这个程序可以让你的 SSH 会话无论因为什么原因中断都会自动重连。因此对于保持一个反向 SSH 隧道非常有用。

第一步,我们要设置从家庭服务器到中继服务器的无密码 SSH 登录。这样的话,autossh 可以不需要用户干预就能重启一个损坏的反向 SSH 隧道。

下一步,在建立隧道的家庭服务器上安装 autossh

在家庭服务器上,用下面的参数运行 autossh 来创建一个连接到中继服务器的永久 SSH 隧道。

homeserver~$ autossh -M 10900 -fN -o "PubkeyAuthentication=yes" -o "StrictHostKeyChecking=false" -o "PasswordAuthentication=no" -o "ServerAliveInterval 60" -o "ServerAliveCountMax 3" -R 1.1.1.1:10022:localhost:22 [email protected]

“-M 10900” 选项指定中继服务器上的监视端口,用于交换监视 SSH 会话的测试数据。中继服务器上的其它程序不能使用这个端口。

“-fN” 选项传递给 ssh 命令,让 SSH 隧道在后台运行。

“-o XXXX” 选项让 ssh:

  • 使用密钥验证,而不是密码验证。
  • 自动接受(未知)SSH 主机密钥。
  • 每 60 秒交换 keep-alive 消息。
  • 没有收到任何响应时最多发送 3 条 keep-alive 消息。

其余 SSH 隧道相关的选项和之前介绍的一样。

如果你想系统启动时自动运行 SSH 隧道,你可以将上面的 autossh 命令添加到 /etc/rc.local。

总结

在这篇博文中,我介绍了你如何能从外部通过反向 SSH 隧道访问限制性防火墙或 NAT 网关之后的 Linux 服务器。这里我介绍了家庭网络中的一个使用事例,但在企业网络中使用时你尤其要小心。这样的一个隧道可能被视为违反公司政策,因为它绕过了企业的防火墙并把企业网络暴露给外部攻击。这很可能被误用或者滥用。因此在使用之前一定要记住它的作用。


via: http://xmodulo.com/access-linux-server-behind-nat-reverse-ssh-tunnel.html

作者:Dan Nanni 译者:ictlyh 校对: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中国 荣誉推出