Nginx作为反向代理和Web服务器，其健康状态不仅取决于自身配置，还受操作系统资源制约。要完整掌握Nginx运行状况，需要从业务指标和系统指标两个层面同时采集。Telegraf的插件化架构让这件事变得简单，它可以在同一个采集代理中同时运行Nginx插件和系统插件，把两类数据统一写入时序数据库。接下来将以Linux环境为例，说明如何开启Nginx状态接口、配置Telegraf以及验证采集结果。
为什么需要同时采集Nginx业务指标与系统资源指标
Nginx本身通过stub_status模块暴露少量运行时数据，包括当前活动连接数、累计接受连接数、累计处理连接数、累计请求数以及读写等待状态的连接数。这些数据反映的是请求层健康度，但无法回答“为什么请求变慢”这类问题。当一个Nginx节点响应延迟升高时，可能的原因包括CPU饱和、内存换页、磁盘IO阻塞或网络中断，而这些必须从操作系统层获取。如果只配置Nginx状态采集，监控数据会缺失关键上下文。
Telegraf的插件生态允许在一个采集代理中同时运行多个输入插件。inputs.nginx负责读取Nginx状态地址，inputs.system则采集CPU、内存、磁盘、网络等系统指标。两个插件共享同一个输出配置，数据会以相同的时间戳写入时序数据库。这样在Grafana中可以把Nginx请求数与CPU使用率放在同一时间轴上进行关联分析，快速判断是流量上涨导致资源紧张，还是资源问题导致Nginx处理能力下降。
实际生产环境中，仅靠top或sar命令观察资源是离散且难以回溯的。Telegraf默认每10秒采集一次，能形成连续的时间序列。Nginx的访问日志虽然详细，但分析成本高，也不适合做实时告警。因此将两种指标统一采集，是构建Nginx可观测性体系的基础一步。
开启Nginx状态接口并验证数据
要让Telegraf读取Nginx指标，首先需要确认Nginx编译时包含http_stub_status_module模块。可以使用nginx -V 2>&1 | grep stub_status检查。如果没有该模块，需要重新编译或使用发行版自带的包。多数官方包和主流Linux发行版都已默认启用，Ubuntu、Debian、CentOS的Nginx包通常带该模块。
在Nginx的server配置块中添加一个受保护的location，只允许本机访问。示例配置如下：
server {
listen 127.0.0.1:80;
server_name localhost;
location /nginx_status {
stub_status;
allow 127.0.0.1;
deny all;
}
}
保存配置后执行nginx -t测试语法，再执行systemctl reload nginx使其生效。使用curl http://127.0.0.1/nginx_status验证，正常会输出类似Active connections: 3、server accepts handled requests以及Reading: 0 Writing: 1 Waiting: 2的文本。
其中Active connections表示当前活动连接数；accepts、handled、requests是累计值，handled通常略小于accepts，两者差值代表连接建立后未被处理的数量；Reading、Writing、Waiting对应Nginx连接状态，Waiting通常出现在keep-alive场景。这些数据便是inputs.nginx插件将要解析的内容。
安装Telegraf并配置Nginx与系统插件
以Ubuntu或Debian为例，添加InfluxData官方仓库或直接下载deb包安装。CentOS或RHEL可以使用yum仓库。安装完成后主配置文件位于/etc/telegraf/telegraf.conf。Telegraf使用TOML格式，默认已包含许多注释掉的插件配置。需要找到outputs.influxdb和inputs相关部分并取消注释。
配置输出到InfluxDB，并根据实际地址修改。核心配置如下：
[agent] interval = "10s" flush_interval = "10s" [[outputs.influxdb]] urls = ["http://127.0.0.1:8086"] database = "telegraf" username = "admin" password = "secret" [[inputs.system]] [[inputs.nginx]] urls = ["http://127.0.0.1/nginx_status"] response_timeout = "5s"
其中inputs.system使用默认参数即可，它会采集CPU、内存、磁盘、网络、内核等指标。inputs.nginx通过HTTP GET请求状态地址，将返回的文本解析为测量数据。如果Nginx监听在非80端口或使用HTTPS，可以在urls中指定完整地址。多个Nginx实例可以配置多个urls，也可以为每个实例添加标签区分来源。
配置完成后执行telegraf --config /etc/telegraf/telegraf.conf --test可以输出采集到的数据样本，看到nginx相关字段和system相关字段。确认无误后启动服务systemctl enable --now telegraf。如果使用非systemd系统，可手动运行二进制。此时Telegraf会每10秒采集一次并写入InfluxDB。
验证采集结果与对接Grafana
Telegraf将数据写入InfluxDB后，可以通过InfluxQL查询。例如查询最近5分钟Nginx请求速率，可以使用如下语句：
SELECT derivative("requests", 1s) FROM "nginx" WHERE time > now() - 5m
这里derivative函数计算每秒请求速率。如果使用Flux语言，则用类似from(bucket: "telegraf") |> range(start: -5m)的表达式。不同InfluxDB版本的查询语法有差异，需要在Grafana中根据数据源类型选择对应的查询方式。
Grafana添加InfluxDB数据源时，输入地址、数据库名和认证信息。创建面板时，用两个查询分别获取Nginx请求速率和系统CPU使用率，再将它们叠加显示。例如系统CPU测量为system，字段usage_user和usage_system。通过双轴展示，可以直观看到流量峰值与CPU峰值是否同步，从而快速判断性能瓶颈来源。
还可以配置告警规则，例如当Nginx活动连接数超过阈值或CPU使用率持续高于90%时发送通知。这样整套监控链路从采集、存储到展示和告警就完整了。
常见问题与调优建议
最常见的问题是Telegraf无法访问Nginx状态地址。需要确认Nginx配置中allow和deny规则是否允许Telegraf所在IP访问，如果Telegraf与Nginx不同主机，要把allow改为Telegraf的IP。另外防火墙需放行端口，或直接使用Unix socket方式。Telegraf的inputs.nginx插件也支持通过Unix socket访问，但配置略有不同。
采集频率不宜过高，默认10秒已经足够大多数场景。过短会增加Nginx和InfluxDB压力。如果监控多台Nginx，建议为每个实例打上标签，可以在inputs.nginx中使用[inputs.nginx.tags]添加host或instance标识。示例如下：
[[inputs.nginx]]
urls = ["http://127.0.0.1/nginx_status"]
[inputs.nginx.tags]
role = "frontend"
这样在Grafana中可以按标签过滤，区分不同节点的数据。系统指标方面，inputs.system默认会采集大量字段，如果磁盘数量多或不需要某些指标，可以通过fielddrop或tagexclude精简，减少存储占用。Telegraf本身也提供了global_tags和metric_buffer_limit等参数，适合较大规模部署时进行调优。定期检查InfluxDB的保留策略，防止监控数据无限增长。