此解决方案可帮助您使用 CloudWatch 代理为在 EC2 实例上运行的 NGINX 应用程序配置开箱即用的指标收集。有关所有 CloudWatch 可观测性解决方案的一般信息,请参阅 CloudWatch 可观测性解决方案。
要求
此解决方案适用于以下情况:
-
支持的版本:NGINX 版本 1.24
-
计算:Amazon EC2
-
在给定的 AWS 区域中跨所有 NGINX 工作负载支持最多 500 个 EC2 实例
-
最新版本的 CloudWatch 代理
-
Prometheus Exporter:nginxinc/nginx-prometheus-exporter(Apache 2.0 许可证)
-
EC2 实例上已安装 SSM 代理
注意
AWS Systems Manager(SSM Agent)预装在由 AWS 和受信任的第三方提供的一些亚马逊机器映像(AMI)上。如果未安装代理,您可以根据操作系统类型使用程序手动安装。
优势
该解决方案提供 NGINX 监测,为以下用例提供宝贵的见解:
-
查看连接指标以确定潜在的瓶颈、连接问题或意外使用情况。
-
分析 HTTP 请求量以了解 NGINX 上的总体流量负载。
以下是该解决方案的主要优点:
-
使用 CloudWatch 代理配置自动收集 NGINX 指标,无需手动检测。
-
为 NGINX 指标提供预配置的整合 CloudWatch 控制面板。控制面板将自动处理使用该解决方案配置的新 NGINX EC2 实例的指标,即使这些指标在您首次创建控制面板时不存在。
下图是此解决方案控制面板的示例。

成本
此解决方案在您的账户中创建和使用资源。您需要为标准使用量付费,包括以下各项:
-
CloudWatch 代理为此解决方案收集的所有指标都使用嵌入式指标格式(EMF)发布到 CloudWatch Logs。这些 CloudWatch 日志根据其数量和保留期收费。因此,对于此解决方案的任何 PutMetricData API 调用,您无需支付费用。从日志中提取和摄取的指标将作为自定义指标收费。此解决方案使用的指标数量取决于 EC2 主机的数量。
-
为该解决方案配置的每台 NGINX EC2 主机总共发布八个指标。
-
-
一个自定义控制面板。
有关 CloudWatch 定价的信息,请参阅 Amazon CloudWatch 定价
定价计算器可帮助您估算使用此解决方案的每月大致费用。
使用定价计算器估算每月解决方案成本
-
对于选择区域,选择要在其中部署解决方案的 AWS 区域。
-
在指标部分中,对于指标数量,输入
8 * number of EC2 instances configured for this solution
。 -
在日志部分,对于标准日志:提取的数据,输入 CloudWatch 代理跨所有 EC2 主机生成的估计每日日志量。例如,五个 EC2 实例每天产生少于 1000 字节的数据。设置完成后,您可以使用 CloudWatch Logs 提供的
IncomingBytes
指标检查字节使用情况。请务必选择相应的日志组。 -
在日志部分中,对于日志存储/存档(标准和公开发布的日志),选择
Yes to Store Logs: Assuming 1 month retention
。如果您决定对保留期进行自定义更改,请修改此值。 -
在控制面板和警报部分中,对控制面板数量输入
1
。 -
您可以在定价计算器底部查看每月估算成本。
此解决方案的 CloudWatch 代理配置
CloudWatch 代理是在您的服务器和容器化环境中持续自主运行的软件。它从您的基础设施和应用程序收集指标、日志和跟踪,并将其发送到 CloudWatch 和 X-Ray。
有关 CloudWatch 代理的更多信息,请参阅使用 CloudWatch 代理收集指标、日志和跟踪信息。
此解决方案中的代理配置收集一组指标,以帮助您开始监测和观察 NGINX 工作负载。可以将 CloudWatch 代理配置为收集比控制面板默认显示更多的 NGINX 指标。有关您可以收集的所有 NGINX 指标的列表,请参阅 Metrics for NGINX OSS
在配置 CloudWatch 代理之前,必须先配置 NGINX 以公开其指标。其次,您必须安装和配置第三方 Prometheus 指标导出器。
公开 NGINX 指标
注意
以下命令适用于 Linux。查看 NGINX for Windows 页面
首先您必须启用 stub_status
模块。在您的 NGINX 配置文件中添加一个新的位置块。在 nginx.conf
的 server
块中添加以下几行以启用 NGINX 的 stub_status
模块:
location /nginx_status {
stub_status on;
allow 127.0.0.1; # Allow only localhost to access
deny all; # Deny all other IPs
}
在重新加载 NGINX 之前,请验证您的 NGINX 配置:
sudo nginx -t
此验证命令有助于防止可能会导致网站崩溃任何不可预见的错误。以下示例展示成功的响应:
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
成功验证更新的配置后,重新加载 NGINX(预计不会有输出):
sudo systemctl reload nginx
此命令指示 NGINX 进程重新加载配置。与完全重启相比,重新加载更加顺畅。重新加载将使用新配置启动新的工作进程,并正常关闭旧的工作进程。
测试 NGINX 状态端点:
curl http://127.0.0.1/nginx_status
以下示例展示成功的响应:
Active connections: 1
server accepts handled requests
6 6 6
Reading: 0 Writing: 1 Waiting: 0
以下示例展示失败的响应(在继续操作之前,请查看前面的步骤):
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>The page is not found</title>
...
配置 Prometheus 指标导出器
从官方 GitHub 存储库
以下示例展示适用于 AMD64 的命令:
cd /tmp
wget https://github.com/nginxinc/nginx-prometheus-exporter/releases/download/v1.3.0/nginx-prometheus-exporter_1.3.0_linux_amd64.tar.gz
tar -xzvf nginx-prometheus-exporter_1.3.0_linux_amd64.tar.gz
sudo cp nginx-prometheus-exporter /usr/local/bin/
rm /tmp/nginx-prometheus-exporter*
运行 Prometheus 导出器并将其指向 NGINX 存根状态页面:
nohup /usr/local/bin/nginx-prometheus-exporter -nginx.scrape-uri http://127.0.0.1/nginx_status &>/dev/null &
以下示例展示响应(后台作业 ID 和 PID):
[1] 74699
测试 NGINX Prometheus 端点
验证 NGINX Prometheus 导出器是否已开始公开相关指标:
curl http://localhost:
port-number
/metrics
以下示例展示成功的响应:
# HELP go_gc_duration_seconds A summary of the pause duration of garbage collection cycles.
# TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile="0"} 0
go_gc_duration_seconds{quantile="0.25"} 0
...
# HELP nginx_connections_accepted Accepted client connections
# TYPE nginx_connections_accepted counter
nginx_connections_accepted 14
# HELP nginx_connections_active Active client connections
# TYPE nginx_connections_active gauge
nginx_connections_active 1
...
# TYPE promhttp_metric_handler_requests_total counter
promhttp_metric_handler_requests_total{code="200"} 1
promhttp_metric_handler_requests_total{code="500"} 0
promhttp_metric_handler_requests_total{code="503"} 0
此解决方案的代理配置
代理收集的指标在代理配置中定义。该解决方案提供代理配置,以收集建议的指标,并为解决方案的控制面板提供合适的维度。
稍后将在为您的解决方案部署代理中介绍部署解决方案的步骤。以下信息旨在帮助您了解如何针对环境自定义代理配置。
您必须根据环境自定义代理和 Prometheus 配置的某些部分,例如 Prometheus 导出器使用的端口号。
可以使用以下命令验证 Prometheus 导出器使用的端口:
sudo netstat -antp | grep nginx-prom
以下示例展示响应(显示端口值 9113):
tcp6 0 0 :::9113 :::* LISTEN 76398/nginx-prometh
NGINX 主机的代理配置
具有 Prometheus 监控功能的 CloudWatch 代理需要两种配置来抓取 Prometheus 指标。每个配置都将作为单独参数存储在 SSM 的 Parameter Store 中,稍后将在步骤 2:在 Systems Manager Parameter Store 中存储建议的 CloudWatch 代理配置文件中详细介绍。
第一个配置用于 Prometheus 导出器,如 Prometheus 的 scrape_config
Prometheus 配置
将 port-number
替换为您服务器的端口。
global: scrape_interval: 30s scrape_timeout: 10s scrape_configs: - job_name: 'nginx' metrics_path: /metrics static_configs: - targets: ['localhost:
port-number
'] ec2_sd_configs: - port:port-number
relabel_configs: - source_labels: ['__meta_ec2_instance_id'] target_label: InstanceId metric_relabel_configs: - source_labels: ['__name__'] regex: 'nginx_up|nginx_http_requests_total|nginx_connections_.*' action: keep
CloudWatch 代理配置
根据之前的 CloudWatch 代理配置,这些指标均使用嵌入式指标格式(EMF)通过 CloudWatch Logs 发布。这些日志配置为使用日志组 nginx
。您可以使用代表 CloudWatch 日志的不同名称自定义 log_group_name
。
如果您使用的是 Windows Server,请将以下配置中的 prometheus_config_path
设置为 C:\\ProgramData\\Amazon\\AmazonCloudWatchAgent\\prometheus.yaml
。
{
"agent": {
"metrics_collection_interval": 60
},
"logs": {
"metrics_collected": {
"prometheus": {
"log_group_name": "nginx",
"prometheus_config_path": "/opt/aws/amazon-cloudwatch-agent/etc/prometheus.yaml",
"emf_processor": {
"metric_declaration_dedup": true,
"metric_namespace": "CWAgent",
"metric_declaration":[
{
"source_labels":["InstanceId"],
"metric_selectors":["nginx_up", "nginx_http_requests_total", "nginx_connections*"],
"dimensions": [["InstanceId"]]
}
]
}
}
}
}
}
为您的解决方案部署代理
安装 CloudWatch 代理有几种方法,具体视用例而定。对于此解决方案,我们建议使用 Systems Manager。它提供了控制台体验,使在单个 AWS 账户中管理一组托管服务器变得更加简单。本节中的说明使用 Systems Manager,适用于没有使用现有配置运行 CloudWatch 代理的情况。您可以按照验证 CloudWatch 代理是否正在运行中的步骤检查 CloudWatch 代理是否正在运行。
如果您已经在部署工作负载的 EC2 主机上运行 CloudWatch 代理并管理代理配置,则可以跳过本节中的说明并按照现有部署机制更新配置。请务必将新的 CloudWatch 代理和 Prometheus 配置与现有的配置合并,然后部署合并的配置。如果您使用 Systems Manager 存储和管理 CloudWatch 代理的配置,则可以将配置合并到现有参数值。有关更多信息,请参阅 Managing CloudWatch agent configuration files。
注意
使用 Systems Manager 部署以下 CloudWatch 代理配置,将替换或覆盖 EC2 实例上任何现有的 CloudWatch 代理配置。您可以修改此配置以适应您独有的环境或用例。配置中定义的指标是提供解决方案的控制面板所需的最低要求。
部署过程包括以下步骤:
-
步骤 1:确保目标 EC2 实例具有所需的 IAM 权限。
-
步骤 2:在 Systems Manager Parameter Store 中存储建议的代理配置文件。
-
步骤 3:使用 AWS CloudFormation 堆栈在一个或多个 EC2 实例上安装 CloudWatch 代理。
-
步骤 4:验证代理设置是否正确配置。
步骤 1:确保目标 EC2 实例具有所需的 IAM 权限
您必须授予 Systems Manager 安装和配置 CloudWatch 代理的权限。您必须授予 CloudWatch 代理将遥测数据从 EC2 实例发布到 CloudWatch 的权限。您还必须授予 CloudWatch 代理 EC2 的读取访问权限。将 EC2 实例 ID 添加为指标维度需要 EC2 读取访问权限。如上所述,这一额外要求是由上 prometheus.yaml
驱动的,因为它通过 EC2 服务发现使用
__meta_ec2_instance_id
。
确保附加到实例的 IAM 角色已附加 CloudWatchAgentServerPolicy、AmazonSSMManagedInstanceCore 和 AmazonEC2ReadOnlyAccess IAM 策略。
-
创建角色后,将该角色附加到 EC2 实例。要将角色附加到 EC2 实例,请按照将 IAM 角色附加到实例中的步骤进行操作。
步骤 2:在 Systems Manager Parameter Store 中存储建议的 CloudWatch 代理配置文件
Parameter Store 通过安全地存储和管理配置参数,简化了 CloudWatch 代理在 EC2 实例上的安装,而无需硬编码值。这可确保更加安全灵活的部署过程,从而实现集中管理,并且可以更轻松地跨多个实例更新配置。
使用以下步骤将建议的 CloudWatch 代理配置文件作为参数存储在 Parameter Store 中。
创建 CloudWatch 代理配置文件作为参数
访问 https://console.aws.amazon.com/systems-manager/
,打开 AWS Systems Manager 控制台。 -
确认控制台上的所选区域是运行 NGINX 的区域。
-
从导航窗格中,依次选择应用程序管理、Parameter Store
-
按照以下步骤为配置创建新参数。
-
选择创建参数。
-
在名称框中,输入您将在后续步骤中用来引用 CloudWatch 代理配置文件的名称。例如,
AmazonCloudWatch-NGINX-CloudWatchAgent-Configuration
。 -
(可选)在描述框中,键入参数的描述。
-
对于参数层,选择标准。
-
对于类型,选择字符串。
-
对于数据类型,选择文本。
-
在值框中,粘贴 NGINX 主机的代理配置中列出的相应 JSON 块。请务必根据需要进行自定义。例如,相关的
log_group_name
。 -
选择创建参数。
-
创建 Prometheus 配置文件作为参数
访问 https://console.aws.amazon.com/systems-manager/
,打开 AWS Systems Manager 控制台。 -
从导航窗格中,依次选择应用程序管理、Parameter Store
-
按照以下步骤为配置创建新参数。
-
选择创建参数。
-
在名称框中,输入您将在后续步骤中用来引用配置文件的名称。例如,
AmazonCloudWatch-NGINX-Prometheus-Configuration
。 -
(可选)在描述框中,键入参数的描述。
-
对于参数层,选择标准。
-
对于类型,选择字符串。
-
对于数据类型,选择文本。
-
在值框中,粘贴 NGINX 主机的代理配置中列出的相应 YAML 块。请务必根据需要进行自定义。例如,根据
targets
的相关端口号。 -
选择创建参数。
-
步骤 3:安装 CloudWatch 代理并使用 AWS CloudFormation 模板应用配置
您可以使用 AWS CloudFormation 安装代理,并将其配置为使用您在前面步骤中创建的 CloudWatch 代理配置。
为此解决方案安装和配置 CloudWatch 代理
-
使用以下链接打开 AWS CloudFormation 快速创建堆栈向导:https://console.aws.amazon.com/cloudformation/home?#/stacks/quickcreate?templateURL=https://aws-observability-solutions.s3.amazonaws.com/CloudWatchAgent/CFN/v1.0.0/cw-agent-installation-template-with-prometheus-config-1.0.0.json
。 -
确认控制台上的所选区域是运行 NGINX 工作负载的区域。
-
对于堆栈名称,输入用于识别此堆栈的名称,如
CWAgentInstallationStack
。 -
在参数部分中,指定以下各项:
-
对于 CloudWatchAgentConfigSSM,请输入您之前创建的代理配置的 AWS Systems Manager 参数名称,例如
AmazonCloudWatch-NGINX-CloudWatchAgent-Configuration
。 -
对于 PrometheusConfigSSM,请输入您之前创建的代理配置的 AWS Systems Manager 参数名称,例如
AmazonCloudWatch-NGINX-Prometheus-Configuration
。 -
要选择目标实例,您有两种选择。
-
对于 InstanceIds,请指定一个以逗号分隔的实例 ID 列表,其中包含希望使用此配置安装 CloudWatch 代理的实例 ID。您可以列出一个或多个实例。
-
如果要大规模部署,则可以指定 TagKey 和相应的 TagValue,以将具有此标签和值的所有 EC2 实例作为目标。如果指定 TagKey,则必须指定相应的 TagValue。(对于自动扩缩组,为 TagKey 指定
aws:autoscaling:groupName
并为 TagValue 指定自动扩缩组名称,以部署到自动扩缩组内的所有实例。)
-
-
-
检查设置,然后选择创建堆栈。
如果要先编辑模板文件进行自定义,请选择创建堆栈向导下的上传模板文件选项,上传编辑后的模板。有关更多信息,请参阅在 AWS CloudFormation 控制台上创建堆栈。您可以使用以下链接下载模板:https://aws-observability-solutions.s3.amazonaws.com/CloudWatchAgent/CFN/v1.0.0/cw-agent-installation-template-with-prometheus-config-1.0.0.json
注意
完成此步骤后,此 Systems Manager 参数将与目标实例中运行的 CloudWatch 代理相关联。这意味着:
-
如果删除 Systems Manager 参数,代理将停止。
-
如果编辑了 Systems Manager 参数,则配置更改将按计划频率(默认为 30 天)自动应用到代理。
-
如果要立即应用对此 Systems Manager 参数的更改,则必须再次运行此步骤。有关关联的更多信息,请参阅在 Systems Manager 中使用关联。
步骤 4:验证代理设置是否正确配置
您可以按照验证 CloudWatch 代理是否正在运行中的步骤验证 CloudWatch 代理是否已安装。如果 CloudWatch 代理尚未安装和运行,请确保已正确设置所有内容。
-
请确保您已为 EC2 实例附加具有正确权限的角色,如步骤 1:确保目标 EC2 实例具有所需的 IAM 权限中所述。
-
请确保您已正确配置 Systems Manager 参数的 JSON。按照 对利用 AWS CloudFormation 的 CloudWatch 代理安装进行故障排除 中的步骤操作。
如果一切设置正确,那么您应该会看到 NGINX 指标发布到 CloudWatch。您可以查看 CloudWatch 控制台以验证这些指标是否已发布。
验证 NGINX 指标是否已发布到 CloudWatch
通过 https://console.aws.amazon.com/cloudwatch/
打开 CloudWatch 控制台。 -
选择指标、所有指标。
-
确保您已选择部署解决方案的区域,然后选择自定义命名空间、CWAgent。
-
搜索指标,例如
nginx_http_requests_total
。如果您看到这些指标的结果,则表明这些指标已发布到 CloudWatch。
创建 NGINX 解决方案控制面板
此解决方案提供的控制面板通过聚合和显示所有实例的指标,来显示 NGINX 工作负载指标。控制面板显示每个指标排名靠前的贡献者(每个指标的前 10 名小部件)明细。这可以帮助您快速识别对观测指标有显著影响的异常值或实例。
要创建控制面板的操作,可以使用以下选项:
使用 CloudWatch 控制台创建控制面板。
使用 AWS CloudFormation 控制台部署控制面板。
以 AWS CloudFormation 基础设施即代码,并将其作为持续集成(CI)自动化的一部分进行集成。
通过使用 CloudWatch 控制台创建控制面板,您可以在实际创建和收费之前预览控制面板。
注意
此解决方案中使用 AWS CloudFormation 创建的控制面板显示解决方案部署区域的指标。请务必在发布 NGINX 指标的区域创建 AWS CloudFormation 堆栈。
如果您在 CloudWatch 代理配置中指定了 CWAgent
以外的自定义命名空间,则必须更改控制面板的 CloudFormation 模板,将 CWAgent
替换为您使用的自定义命名空间。
使用 CloudWatch 控制台创建控制面板
-
使用以下链接打开 CloudWatch 控制台创建控制面板:https://console.aws.amazon.com/cloudwatch/home?#dashboards?dashboardTemplate=NginxOnEc2&referrer=os-catalog
。 -
确认控制台上的所选区域是运行 NGINX 工作负载的区域。
-
输入控制面板的名称,然后选择创建控制面板。
为了便于将此控制面板与其他区域的类似控制面板区分开来,我们建议在控制面板名称中包含区域名称,例如
NGINXDashboard-us-east-1
。 -
预览控制面板并选择保存以创建控制面板。
通过 AWS CloudFormation 创建控制面板
-
使用以下链接打开 AWS CloudFormation 快速创建堆栈向导:https://console.aws.amazon.com/cloudformation/home?#/stacks/quickcreate?templateURL=https://aws-observability-solutions.s3.amazonaws.com/NGINX_EC2/CloudWatch/CFN/v1.0.0/dashboard-template-1.0.0.json
。 -
确认控制台上的所选区域是运行 NGINX 工作负载的区域。
-
对于堆栈名称,输入用于识别此堆栈的名称,如
NGINXDashboardStack
。 -
在参数部分,在 DashboardName 参数下指定控制面板的名称。
-
为了便于将此控制面板与其他区域的类似控制面板区分开来,我们建议在控制面板名称中包含区域名称,例如
NGINXDashboard-us-east-1
。 -
在功能和转换下确认转换的访问功能。请注意,CloudFormation 不会添加任何 IAM 资源。
-
检查设置,然后选择创建堆栈。
-
堆栈状态为 CREATE_COM PLETE 后,选择创建的堆栈下的资源选项卡,然后选择物理 ID 下的链接转至控制面板。您也可以通过在控制台左侧导航窗格中选择控制面板,然后在自定义控制面板下找到控制面板名称,在 CloudWatch 控制台中访问控制面板。
如果要先编辑模板文件进行自定义,请选择创建堆栈向导下的上传模板文件选项,上传编辑后的模板。有关更多信息,请参阅在 AWS CloudFormation 控制台上创建堆栈。您可以使用以下链接下载模板:https://aws-observability-solutions.s3.amazonaws.com/NGINX_EC2/CloudWatch/CFN/v1.0.0/dashboard-template-1.0.0.json
开始使用 NGINX 控制面板
您可以使用新的 NGINX 控制面板尝试以下几项任务。这些任务允许您验证控制面板是否正常运行,并为您提供使用它来监测 NGINX 工作负载的一些实践经验。在尝试这些任务的过程中,您将熟悉如何浏览控制面板和解读可视化指标。
查看连接指标
在连接部分,您可以找到几个关键指标,这些指标能让您深入了解 NGINX 服务器的客户端连接处理情况。监测这些连接指标可以帮助您确定潜在的瓶颈、连接问题或意外的连接模式。
-
已接受的客户端连接
-
活跃的客户端连接
-
已处理的客户端连接
-
连接读取请求
-
空闲客户端连接
-
连接写入响应
分析 HTTP 请求量
HTTP 请求部分中的 request
指标显示 NGINX 服务器处理的 HTTP 请求总数。跟踪此指标随时间的变化可以帮助您了解 NGINX 基础架构上的总体流量负载,并相应地规划资源分配和扩展。