NGINX 监控--您应该了解的最佳工具和关键指标

NGINX是一个流行的Web服务器，具有广泛的功能，包括反向代理、邮件代理、HTTP缓存和负载平衡。它提供TLS卸载和后端健康检查，支持gRPC、WebSocket和HTTP/2。简而言之，NGINX是一个一站式的解决方案，可以满足你的大部分网络服务器需求。

在使用NGINX时，监控它的指标对于处理问题至关重要。在这篇文章中，我将介绍你应该测量的关键NGINX指标，以及市场上可以帮助你提高Web服务器性能的最佳监控工具。

为什么要监控NGINX性能

有许多因素会导致NGINX的性能问题，比如请求的吞吐量增加，网络或磁盘IO增加，磁盘、CPU、内存和应用程序错误的饱和。由于NGINX作为应用程序的一个入口点，任何性能问题或错误它都会让它通过，可能会导致重大的收入损失或违反你的应用程序的SLI和SLO。

因此，NGINX监控是至关重要的。通过在问题出现时设置警报，你将能够调试或缓解问题。另外，在监控NGINX指标的同时，访问和错误日志将使你对你的系统有更好的可视性，使你能够采取预防措施并保护你的底线。

启用NGINX指标页面

如果你希望你的NGINX监控工具开始消耗指标，你首先需要启用NGINX stub_status模块。一旦你这样做了，NGINX就会暴露出一个指标的URL，然后可以被不同的监控方案所消耗。

在你的nginx.conf 文件中添加以下代码，以启用指标:

location /nginx_status {
        stub_status;
        allow 127.0.0.1;
        deny all;
}

如何监控NGINX

现在你已经启用了你的NGINX指标页面，让我们来谈谈如何实际监控NGINX。监控NGINX意味着观察你的NGINX响应和性能，以及你的系统和网络指标，以便对你的NGINX基础设施中发生的事情有一个全面的了解。

有许多NGINX指标是特别需要监控的。它们分为两类：系统指标和专门的NGINX指标。

系统指标

监控你的基本系统资源可以确保你的底层基础设施和操作系统在正常工作。它还可以帮助你跟踪系统性能，并确定NGINX错误是否是由这些资源的饱和度造成的。关键的系统指标包括平均负载、磁盘I/O、内存、存储和网络I/O。

负载平均数

负载平均值是你的系统正在运行的平均负载。它有三个值。1分钟、5分钟和15分钟的平均数。如果这些值中的任何一个的平均负载很高，你的CPU在那个时间段内就会被压制。

阈值:作为一般的经验法则，负载平均数应该小于核心数量的1.5-2倍。任何超过这个数值的情况都意味着利用率很高。如果你看到一个持续的负载~2，你可能需要增加你机器上的核心数量。

磁盘I/O

磁盘I/O包括从磁盘的读写操作。这基本上是数据在RAM和磁盘之间传输的速度。

阈值:如果你的I/O等待百分比大于1/CPU的数量，你的CPU正在等待很长的时间让你的磁盘跟上。

内存

内存指的是使用的RAM的数量，表明应用程序的运行是否有很高的内存要求。

阈值:内存使用率在100%左右将对你的系统产生负面影响。

存储器

存储是指系统中正在使用的磁盘数量，以及可以存储多少数据。

阈值:如 果你的磁盘消耗百分比很高（接近100%），要注意了。如果达到100%，你的系统可能会停止工作。警报一般设置在使用率的90%。

网络I/O

网络I/O是指系统传输和接收数据的速度。

阈值:这可能取决于你的系统带宽。网络I/O不应该达到你的机器支持的网络带宽的上限。

专用的NGINX指标

监控NGINX专用指标将使你能够捕捉和调试问题，同时确保你的基础设施运行顺畅，易于维护。有不少专门的NGINX指标是你应该监控的，包括。

每秒请求数

简而言之，每秒请求数（RPS）是NGINX服务器的吞吐量。

影响和补救措施：RPS的增加表明吞吐量的增加，意味着你可能要扩大你的NGINX实例的规模。

阈值:这将根据你的机器配置而变化，但如果你看到RPS突然增加，你应该研究一下原因。这可能是由于错误导致的吞吐量或重试的增加。

响应时间或请求处理时间

响应时间是指请求到达和响应之间的时间间隔--基本上，为每个请求提供服务需要多长时间。它也是衡量你的应用程序性能的一个关键指标。

影响和补救措施:响应时间的增加意味着你的应用程序或上游服务出现了问题，导致请求处理时间过长。这可能是一个变化或一个新的部署导致问题的迹象。

阈值:这将取决于你的应用性能。如果阈值在部署后增加，你可以假设新部署中的某些东西造成了问题。这就是响应时间指标在金丝雀部署中有用的原因之一。

活动连接

活动连接是指目前由NGINX实例提供的连接或请求的总数。在任何时候，都有一个最大的连接数可以活动。如果活动连接总数超过这个限制，连接将开始下降。

影响和补救措施: 达到最大连接数将导致连接进入积压，如果积压的连接被填满，就会下降。如果发生这种情况，你需要扩展你的NGINX机器。

阈值:这取决于你的机器的配置，你可以调整它来优化最大连接数的变量。

连接积压

连接积压是指排在队列中的连接请求，因为它们不能马上被服务。尽管NGINX接受连接的速度很快，但在一些高流量的情况下，它们可能会进入一个积压队列。这个队列的大小可以通过NGINX配置文件进行配置。一旦积压的数据填满，NGINX实例将不接受新的连接请求。

影响和补救措施:连接积压是一个迹象，表明你需要增加NGINX盒子的数量。

阈值:理 想情况下，这应该是零。你不希望你的连接进入积压队列，因为这将增加响应时间。

服务器错误

NGINX服务器错误是可以记录的服务器状态代码。它们代表错误分类，如服务器端错误、客户端错误、权限错误或重定向。5xx是内部服务器错误。4xx是客户端错误，意味着客户端在向服务器发送请求时发生了错误。

影响和补救措施：这告诉你由于客户端或服务器错误而失败的请求的数量。一些错误并不罕见，但突然增加可能表明来自应用程序或客户端的问题。

阈值：这 些通常是1%左右，但这取决于你的应用程序。如果阈值瞬间增加，几乎可以肯定你的应用程序有问题。

丢弃的连接

这些连接是由于满负荷积压和最大活动连接而被丢弃的。

影响和补救措施：如果你有丢弃的连接，你可能需要增加你的最大活动连接或连接积压，或者扩大你的NGINX机器的规模。

阈值：这 应该是零，因为你不希望你的连接被丢弃。

可用的上游

这表明在NGINX作为反向代理工作的情况下，可用来服务请求的上游服务器的数量。

影响和补救措施： 这告诉你你的上游服务器是否在工作。如果这些服务器瘫痪了，你的请求服务能力可能会因为上游服务器的损失而下降。

阈值：上 游数量的任何减少都表明你的上游服务器停机了。

活跃的上游连接

活跃的上游连接是指在反向代理的情况下与上游服务器的总活跃连接。

影响和补救措施：这里的变化表明，与上游服务器的连接数很高。这可能意味着你的连接没有得到正确的服务。由于增加了延迟，你也可能看到响应时间的增加。RPS的增加也意味着吞吐量增加了，你的NGINX服务器需要进行扩展。

阈值：这将取决于你的机器和上游服务器的数量。注意任何突然出现的峰值。

上游错误

如果NGINX是作为一个反向代理工作的，它会提醒你来自上游服务器的错误。

影响和补救措施：这个值的增加表明有来自上游服务器的错误，可能需要处理。

阈值：这 将取决于你的应用，就像服务器错误一样。

打开文件

NGINX为它处理的每个连接打开一个系统文件描述符。由于你在一个系统上能打开的文件数量是有限制的，所以一个NGINX实例能处理的同时连接数也有一个上限。这个设置是在操作系统的配置中。你可以用Linux中的ulimit命令来检查这个。

影响和补救措施：NGINX为每个新连接打开一个文件。连接数的增加可能会导致打开的文件数增加。

阈值：标准限制被设置为65,536，但如果你预期有大量的连接，你可以增加这个限制。

7个*的NGINX监控工具

有许多解决方案可用于NGINX指标的可视化。为了帮助你确定哪一个能提供最好的投资回报率并满足你的特定监控需求，我将比较市场上的一些*工具。

1.Sematext

Sematext Monitoring是一个基础设施监控工具，支持实时NGINX性能监控。它涵盖了NGINX和NGINX Plus的大部分指标，包括每秒请求数、对上游的响应信息、缓存和SSL卸载。

Sematext具有先进的功能，能够更快地进行故障排除，如警报、异常检测和日志关联。该解决方案非常容易与Kubernetes、容器化环境、云解决方案（如Amazon ECS）和警报解决方案（如PagerDuty）集成。它可以向Slack和电子邮件发送警报。通过Sematext，你还可以监控数据库、应用程序和服务器。如果你正在寻找一个一站式的基础设施监控工具，Sematext的监控和警报功能已经覆盖了你。

优点

• 自动发现大规模基础设施中的NGINX盒子
• 支持Elasticsearch API的日志和InfluxDB API的指标集成
• 以NGINX指标和日志为支撑的开箱即用的仪表盘

缺点

• 没有自我托管的解决方案
• 缺乏让人眼花缭乱的网络地图，无法看到所有的NGINX实例。

价格

指标收集的价格是每个容器主机每小时0.007美元。专业版的价格是每个容器主机每小时0.011美元。集成的标准定价是每台主机每个代理0.035美元，而专业级的价格是每台主机每个代理0.070美元。

2.2.New Relic

New Relic是一个应用程序性能管理工具，提供NGINX和NGINX Plus监控功能。在一个插件的帮助下，它可以收集一些指标，包括请求、响应、缓存和SSL指标。New Relic与Prometheus、主要的云供应商以及Docker和Kubernetes等容器化解决方案有良好的整合。它还支持向许多渠道发送警报，包括Slack、电子邮件、PagerDuty和Webhooks。

要启用NGINX指标，你需要在你的主机上安装一个New Relic代理。如果你在Amazon ECS或Kubernetes上运行NGINX，你将不得不遵循不同的整合程序。New Relic提供了两种类型的代理：一种用于APM，在许多语言中都有，另一种可用于基础设施监控（如NGINX、MySQL和Redis）。

优点

• 预先建好的仪表板来监控NGINX性能
• 自动发现NGINX盒子
• SSL握手的指标，如由于证书轮换而导致的失败问题。

缺点

• 没有自我托管的解决方案；必须依赖他们的用户界面，所以给更多的用户提供访问的成本更高
• 没有上游指标；如果你把NGINX作为反向代理运行，对上游服务器连接的可见性不确定。

价格

New Relic提供了一个分层的定价模型。免费、标准、专业和企业。免费层包括每月100GB的免费数据摄取，一个免费的完全访问用户，以及无限的免费基本用户。费用基于数据量，超过100GB的标准费率为每月每GB0.25美元。

3.3.Datadog

Datadog是一个基于SaaS的监控分析平台，你可以用它来实时监控NGINX。它支持180多个NGINX指标，以及异常检测和服务地图生成，这可以帮助追踪受影响的服务。通过Datadog，你可以获得所有NGINX实例的鸟瞰图，这有助于你看到整体总结。

Datadog支持与亚马逊ECS、Kubernetes和Docker等容器化解决方案集成。如果你想用它来监控你的NGINX ingress控制器或在容器中运行NGINX，这使它面向未来。Datadog还提供自定义警报和与NGINX日志的关联性，并促进更快的故障排除。它可以将通知事件发送到电子邮件、Slack、PagerDuty、Jira等。

优点

• 所有NGINX实例的高层视图；对于查看状态或通过预先建立的仪表板识别潜在热点很有用
• 可以将指标与NGINX日志联系起来，以便更好地排除故障
• 支持AWS Lambda

缺点

• 当你激活更多的功能时，代理资源消耗可能会增加；价格昂贵，自定义指标的数量有限
• 使用起来很复杂；新用户的学习曲线很陡峭

价格

Datadog提供14天的免费试用。其定价模式取决于每月的主机数量。专业级每个主机每月15美元。日志是根据摄取量收费的，每月每GB 0.10美元。

4.AppDynamics

AppDynamics是一个应用性能管理工具，适用于企业内部和云系统。它包括一个NGINX和NGINX Plus监控集成，并使用机器学习来识别系统中的异常情况。AppDynamics可以发出细粒度的警报，可以通过不同的渠道发送，包括电子邮件、PagerDuty和Webhook。它还可以与Elasticsearch API和AWS Lambda集成，以消耗指标。

优点

• 为NGINX预制了仪表盘，一旦安装了代理就可以使用。
• 异常检测有助于加快故障排除
• 移动应用程序可以在你移动时监控NGINX

缺点

• 对Kubernetes或Amazon ECS上的NGINX没有本地支持
• 没有围绕自动发现的文档；学习曲线很陡峭

价格

AppDynamics提供15天的免费试用。付费的定价模式是分层次的。基础设施监控（每CPU核心6美元），高级（每CPU核心60美元），和企业（每CPU核心90美元）。

5.SolarWinds Server & Application Monitor

SolarWinds Server & Application Monitor（SAM）帮助企业管理其网络、系统和IT基础设施。SolarWinds可监控NGINX和NGINX Plus，并呈现请求、上游、SSL和缓存信息等指标。每当它们超出限制范围，该工具就会通过一些通知渠道向您发出警报，包括电子邮件、PagerDuty、Slack、ServiceNow和SMS。

您可以使用SolarWinds来映射应用程序和依赖关系，以确定问题的原因和受影响的应用程序。它还具有帮助进行容量规划的功能。该工具的主要功能之一是通过远程控制进行软件库存管理，这有助于尽量减少漏洞。

优点

• 应用程序和依赖关系图，以加快故障排除
• 支持NGINX盒子的自动发现
• 预建的NGINX监控仪表板和模板

缺点

• 没有对Kubernetes或容器平台的本地支持；没有与Elasticsearch APIs集成
• 不支持异常情况检测

价格

没有现成的定价信息，但每个产品都有免费试用，时间从14-30天不等。

6.6.Dynatrace

Dynatrace是一个用于应用性能和基础设施监控的软件平台，具有识别系统异常的AI功能。它可以监控NGINX和NGINX Plus，并呈现请求信息、性能、请求区、缓存、上游和SSL细节等指标。该工具自动检测网络拓扑结构，并在仪表板上显示。

Dynatrace最大的特点之一是，它可以在企业内部托管。它的部署也相对容易。你通常可以在几分钟内让它运行，之后预建的NGINX监控仪表板将开始检索你的数据。Dynatrace通过PagerDuty、Slack、电子邮件、Webhook、ServiceNow等发送警报。

优点

• 只需要一个代理来收集NGINX和其他基础设施的指标
• 能够添加自定义的NGINX仪表盘和流程
• 能够通过API集成将Dynatrace数据发送到Elasticsearch。

缺点

• 没有SSL卸载指标
• 文档不清楚；很难找到如何启用自动发现和其他高级功能。

价格

Dynatrace提供15天的免费试用，以及按主机定价的模式。基础设施监控的费用是每台主机每月21美元，8GB的数据，而全栈监控的费用是每台主机每月69美元，8GB的数据。

7.普罗米修斯和Grafana

Prometheus和Grafana都是开源的解决方案，你可以用来监测NGINX和NGINX Plus的指标，如请求信息、上游和缓存。Prometheus是一个时间序列数据库，需要一个可视化工具，Grafana是最流行的。你也可以安装一个开源的NGINX输出器来暴露指标供Prometheus使用。Prometheus可以很容易地与各种各样的工具集成。

要从Prometheus生成NGINX问题的警报，可以设置一个自定义的仪表板并运行Alertmanager。你也可以使用Grafana来创建警报，并将其发送到不同的渠道。外面有很多开源的仪表盘供你导入和使用。

优点

• 用重词和其他选项自动发现NGINX
• 除了托管Prometheus和Grafana的费用外，是免费和开源的。
• 良好的查询语言和警报支持；可以使用PromQL编写自定义警报

缺点

• NGINX日志和指标之间没有关联性
• 多个组件需要自我管理（对小团队来说可能是个问题）；在其他工具的支持下，很难进行大规模的管理

价格

Prometheus和Grafana是免费的，除了用于托管它们的机器的费用之外。

将NGINX指标与日志联系起来，以便更容易排除故障

正如你所看到的，有很多监测NGINX指标的好办法。这让我们想到将NGINX指标与日志关联起来的重要性。当NGINX日志与指标相结合时，它们会给终端用户带来巨大的价值，因为你可以单独收集日志并使用它们来生成自定义指标。

NGINX有两种类型的日志：访问和错误。通过访问日志，你可以看到应用程序和上游服务器的延迟，而错误日志则向你显示应用程序中的错误。这两种类型的日志，加上指标，可以更全面地了解你的基础设施中正在发生的事情。

这篇文章中讨论的大多数工具都有能力导出和解析NGINX日志，以提高可视性。Sematext、AppDynamics和Datadog为NGINX日志解析、可见性和指标关联提供了更好的支持--Sematext在关联日志和指标以进行故障排除方面有卓越的支持。New Relic更复杂一些，它为日志和指标使用一个单独的仪表盘。

注意：你将需要为这些工具中的任何一个启用NGINX访问和错误日志，以便能够提取它们。

什么是适合你的NGINX监控解决方案？

选择正确的NGINX监控解决方案可能很棘手，因为本篇文章中涉及的解决方案之间有许多相似之处。例如，它们都受到基于你所使用的NGINX解决方案所能显示的指标数量的限制，尽管你在使用NGINX Plus时会得到更多的指标。

那么，你该从哪里着手呢？首先要考虑你的具体使用情况。Prometheus和Grafana对于那些拥有小型基础设施和监控较少机器的初学者来说是很好的。New Relic提供了良好的APM支持，而AppDynamics和Datadog则提供了对日志和指标的整体看法（尽管它们可能很贵）。

如果你想以合理的成本监控NGINX的性能和指标，Sematext是一个不错的选择，因为它具有以下功能：

• 对任何不需要的模式进行异常检测
• 相关的指标
• 本地容器和Kubernetes支持
• 自动发现NGINX盒子，并能够运行事件驱动的基础设施