如何基于ARMS快速实现一个基于Nginx的网站监控场景 – 操作篇

最新推荐文章于 2025-07-30 16:06:36 发布
转载 最新推荐文章于 2025-07-30 16:06:36 发布 · 236 阅读 · 0 ·
CC 4.0 BY-SA版权
原文链接：https://my.oschina.net/u/3568122/blog/1186579
文章标签：

#运维 #操作系统 #json

本文介绍如何利用ARMS实现Nginx监控，包括监控数据集设计、报警配置及交互大盘搭建。涵盖PV、UV统计，响应时间分析，报警阈值设定等内容。

原文链接

本文介绍ARMS如何实现Nginx的监控场景，对于ARMS本文主要解决的问题，还记得小明的老板给他布置的任务吗？需求回顾

1. ARMS的Nginx监控方案概述和准备

目前在监控领域上比较流行的数据处理方法有很多种，例如，搜索引擎，时间序列数据库，实时计算，甚至是大数据离线计算，等。

ARMS采用的是实时计算+列式存储。这种方案的优势是数据实时性高，而且对于固定的数据查询接口查询效率非常块。在Nginx的监控方案中，其架构概要如下所示, 蓝色部分为ARMS所集成的Nginx监控开箱即用的黑盒。

 

由于ARMS的分析是针对Nginx的accee.log日志，因此对Nginx日志有一定要求，需要用户在nginx.config中配置出打印内容，包括：“$upstream_response_time” “$request_time”等代表请求消耗时间的日志信息。如下例：

 log_format   main '$remote_addr - $remote_user [$time_local]  $status '
'"$request" $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"'
'"$upstream_response_time" "$request_time" "$ user_cookie_id"' ;

这样的话，打印出的日志，大致如下表所示。

58.211.119.29 144288 - [16/Mar/2017:21:47:07 +0800] "POST http://arms.console.aliyun.com/api/query.json?action=DataQueryAction&eventSubmitDoQueryData=1" 200 594 "https://arms.console.aliyun.com/" "127.0.0.1:8080" "Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.79 Safari/537.4" "0.144" "0.144" "EX866MB1-Y70JO57WM37ST3HWDVFK3-JWPNH30J-Z"
58.211.119.29 148219 - [16/Mar/2017:21:47:08 +0800] "POST http://arms.console.aliyun.com/api/query.json?action=DataQueryAction&eventSubmitDoQueryData=1" 200 583 "https://arms.console.aliyun.com/" "127.0.0.1:8080" "Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.79 Safari/537.4" "0.148" "0.148" "EX866MB1-Y70JO57WM37ST3HWDVFK3-JWPNH30J-Z"

查看详细要求

完成上述日志配置定制以后，即可开始在ARMS上进行配置。以下篇幅从ARMS数据集，报警，和交互大盘，三个部分进行配置概要描述。关于数据源如何添加到ARMS可参见文档，在此不赘述。

2. 基于ARMS的Nginx监控 数据集实现

在Nginx监控模板中，用户数据分为两类，一类是指标，相当于数据仓库中的Measure；一类是维度，相当于数据仓库中的Dimension。

对于Nginx监控，最常见的指标为以下几类指标:

页面的PV, UV

  • PV: 页面的PV通过对access.log中的每一条日志做count来统计，
  • UV: 通过日志中代表用户ID的对应的$cookie_id来做count distinct来统计。对应的cookie_id需要开发人员进行手动统计。

页面响应时间

  • 平均页面响应时间: 在ARMS中通过对$request_time做sum操作来统计出total_request_time，然后在通国际total_request_time / pv来得到某维度下的瓶平均响应时间。
  • 最大响应时间: 则对单条日志request_time进行max统计。

页面流量

  • 平均页面流量和最大页面流量：针对 $body_bytes_sent来进行统计。统计方式和页面响应时间类似，不赘述。

对于Nginx监控，最常见的维度有以下几类:

  • 页面URL: $request。用户可以针对特定URL进行访问统计，甚至可以在不同URL之间进行访问排行。
  • 页面返回状态：$status。用户可以针对不同的返回值维度进行统计，如仅统计200返回值的正常页面访问情况，或是非200返回值的错误页面访问情况。
  • 浏览器类型：根据 $http_user_agent 统计出的用户的浏览器客户端，如Chrome, Sofari, IE, Firefox, 甚至Curl命令，等。用户可以根据此类维度统计客户端的分布情况。
  • 用户ID：根据 $cook_id 统计出的用户的使用习惯，如哪一类页面被哪一些用户经常访问，等。

对于ARMS的数据集设计，其实就是针对用户感兴趣的Nginx监控结果，进行各类维度的排列组合。

  • 例如，以页面URL维度，统计UV, PV，页面响应时间，则可以统计出不同页面的各自的UV, PV和页面响应时间，甚至根据例如PV进行TopN排行。

下图是一个数据集配置的例子，该数据集配置出两个维度: URL和Status (支持由URL下钻到Status的查询方式)，分别统计两个指标：PV和UV。这样用户可以依次下钻页面路径和返回值来查询PV, UV情况。

 

下图是另个数据集配置的例子，该数据集配置出和上例相同但是顺序相反的两个维度: Status和URL (支持由Status下钻到URL的查询方式)，分别统计两个指标：PV，平均响应时间，最高响应时间 。其中，平均调用时间是复合指标，由 总体调用时间 / PV 间接得出。

 

3. 基于ARMS的Nginx监控 报警实现

常见的Nginx报警有以下几种:

  • 某类页面的响应时间过长。

  • 某类页面的错误率页面过高。
    使用ARMS的原生报警的一些特性天然支持Nginx监控报警的各种场景。以下举例。

  • 支持某类指标的维度下钻遍历
    例如检查(遍历)所有页面维度的响应时间是否超过100ms.

  • 支持不同指标之间的复合计算
    典型如错误码为5xx占总调用的占比，通过不同指标复合计算而得。

  • 支持各种其他报警高级报警配置
    包括最近N分钟同比，环比，最大，最小值比较，等。例如，最近5分钟同比PV下跌50%这种典型的场景。

以下例子结合以上三个特点，介绍了一种如何在ARMS定义”任意URL调用一分钟500返回占比超过10%”的报警定义例子，如下所示。

 

4. 基于ARMS的Nginx监控大盘配置

监控大盘一般有以下几个用途：

  • 挂在作战室，全面掌控运行状态。
  • 用于实时查看，并下钻分析每个具体用户或网页的网站实际使用情况。

针对Nginx监控，ARMS可以基于类似用户维度，页面维度，IP维度，甚至地域维度，展示不同的数据。以展示用户总体UV, PV为例，假设对应的数据集为”整站UV PV”，则配置如下：

 

集成各类UV, PV，响应时间等统计的最终交互式大盘效果图如下：

 

5. 马上快速上手

以上各类Nginx监控场景，目前在ARMS上已有成熟商业模板支持，用户只需要在ARMS首页点击 “新建标准模板监控”，并选择Nginx高级模板，即可。帮助文档

 

原文链接

转载于:https://my.oschina.net/u/3568122/blog/1186579

chipo1143
关注
腾讯云 vs 阿里云：2024年主流云平台全方位对比
AI天才研究院
06-21 1856
随着企业数字化转型的深入，云计算已成为核心基础设施。腾讯云与阿里云作为中国云市场的双雄，占据超过60%的市场份额（2024年IDC数据）。本文旨在通过技术架构、产品矩阵、行业适配性等12个核心维度的对比，帮助技术决策者、开发者和企业IT部门理解两者的差异，制定最优上云策略。全球基础设施布局与网络架构计算、存储、数据库等核心IaaS服务PaaS层开发工具与AI服务生态行业解决方案与安全合规能力成本模型与资源管理工具全文分为技术层对比、应用层分析、实战指导和趋势展望四大部分。
Nginx网络服务之监控模块
zhou641694375的博客
08-29 986
提示：以下是本篇文章正文内容，下面案例可供参考。
如何快速实现一个基于Nginx的网站监控场景 – 操作篇
weixin_34293141的博客
07-05 547
本文介绍ARMS如何实现Nginx的监控场景，对于ARMS本文主要解决的问题，还记得小明的老板给他布置的任务吗？需求回顾 1. ARMS的Nginx监控方案概述和准备 目前在监控领域上比较流行的数据处理方法有很多种，例如，搜索引擎，时间序列数据库，实时计算，甚至是大数据离线计算，等。 ARMS采用的是实时计算+列式存储。这种方案的优势是数据实时性高，...
如何快速实现一个基于Nginx网站的监控场景
weixin_34032827的博客
08-08 252
一切从应用服务监控说起 小明所在的一家小型互联网创业公司一直将应用运行在阿里云上。该应用采用通用的分布式 Nginx+App 架构为用户提供电商数据统计的 webservice 服务。应用运行至今除偶发各类 Bug，性能问题以外，情况还算良好。 undefined 最近，小明的老板给小明布置了一个任务，希望把应用服务监控起来，以提高应用运行质量。老...
Nginx--监控（基础监控、主要指标、收集、扩展分析）
恐龙让Lee的博客
08-22 3454
Nginx的基础监控、监控的主要指标：基本活跃指标、每秒请求数QPS、服务器错误率、请求处理时间；指标的收集：nginx Stub Status监控模块安装、nginx状态查看、Stub Status参参数说明、Request模块监控。补充：查看Web服务器TCP连接状态。
Nginx监控数据采集与分析
weixin_33895475的博客
07-02 855
简介 nginx和很多软件一样（php-fpm、docker、apache等）内建了一个状态页，对于nginx的状态查看以及监控提供了很大帮助。本文主要介绍通过日志服务logtail采集nginx status信息，并对采集的status信息进行查询、统计、搭建仪表盘、建立自定义报警，对您的nginx集群进行全方位的监控。 环境准备 开启nginx st...
阿里云服务器系统（linux）配置nginx
wlijun_0808的博客
10-27 2513
阿里云服务器配置linux
基于 OPLG 从 0 到 1 构建统一可观测平台实践
数据库技术
07-26 471
随着软件复杂度的不断提升，单体应用架构逐步向分布式和微服务的架构演进，整体的调用环境也越来越复杂，仅靠日志和指标渐渐难以快速定位复杂环境下的问题。对于全栈可观测的诉求也变得愈加强烈，Traces、Metrics 和 Logs 的连接也愈发紧密。...
服务器监控详细介绍
HWP18612324139的博客
07-30 926
服务器监控服务是保障IT系统稳定运行的 “神经中枢”，通过覆盖硬件、系统、应用、安全等多维度指标，实现 “异常早发现、故障快定位、资源优配置”。选择监控方案时，需结合服务器规模（单机 / 集群）、部署环境（物理机 / 云 / 混合）、团队技术能力（开源工具自主维护vs商业工具托管）等因素，平衡监控效果与成本。
云平台领域负载均衡器的部署实战技巧
AI天才研究院
06-28 807
随着云计算和微服务架构的普及，负载均衡器已成为分布式系统的核心组件。本文聚焦云平台负载均衡器的部署策略性能优化和故障处理，覆盖从基础概念到复杂场景的实战技巧，适用于AWS、阿里云、腾讯云等主流云厂商的负载均衡服务（如ALB/NLB、SLB、CLB）。核心概念：解析负载均衡技术原理与架构算法实现：通过Python代码实现主流负载均衡算法实战部署：基于多云平台的完整部署流程优化扩展：覆盖性能调优、高可用设计与前沿趋势负载均衡器（Load Balancer, LB）
nginx 流量控制以及访问控制的实现
09-29
主要介绍了nginx 流量控制以及访问控制的实现，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧
Nginx 性能调优与深度监控
2503_91100205的博客
05-30 921
在全球互联网流量激增的背景下，Nginx 作为核心反向代理与负载均衡工具，其性能直接决定了用户体验和业务连续性。对于运维工程师而言，通过精细化调优最大化硬件资源利用率，结合深度监控实现故障预测与快速响应，是保障系统稳定运行的核心能力。本文将从性能调优和深度监控两大维度，详细解析 Nginx 的实战优化策略。调优层面：通过编译参数优化、进程连接配置、缓存策略等提升资源利用率，降低延迟；监控层面：借助 GoAccess 和 VTS 模块实现日志实时分析与流量状态可视化，提前发现性能瓶颈。
nginx访问量监控
aixuner1002的博客
02-09 3179
location /setup { stub_status; #启用模块监控 #出于安全，可以引用nginx密码验证 auth_basic "login password"; auth_basic_user_file /apps/nginx/passwd/.htpasswd ; #也可以增加ip限制 allow IP; deny all; } 访问 http://ip:prot/setup Active connections：当前处于活动状态的客户端连
nginx配置监控
小轱辘
07-19 2130
      通过查看Nginx的并发连接，我们可以更清除的知道网站的负载情况。Nginx并发查看有两种方法（之所以这么说，是因为笔者只知道两种），一种是通过web界面，一种是通过命令，web查看要比命令查看显示的结果精确一些。下面介绍这两种查看方法； 1.通过浏览器查看   通过web界面查看时Nginx需要开启status模块，也就是安装Nginx时加上        –with-http...
如何监控Nginx（看完这篇就会了）
热门推荐
hanjinjuan的博客
08-16 2万+
一、简介 web 服务器 nginx 以其高性能与抗并发能力越来越多的被用户使用。Nginx 提供了 ngx_http_stub_status_module、ngx_http_reqstat_module模块，这两个模块提供了基本的监控功能。 进程监控 端口监控 注意： 这两个是必须要加在zabbix监控，加触发器有问题及时告警。 二、监控的主要指标 即主要监控对象： 1、基本活跃指标 名称 描述 指标类型 Accepts （接受） NGINX 所接受的客户端连接数 资源: 功能
如何快速实现一个基于Nginx的网站监控场景----需求篇
weixin_34347651的博客
03-14 301
一切从应用服务监控说起 小明所在的一家小型互联网创业公司一直将应用运行在国内某A云上。该应用采用通用的分布式Nginx+App架构为用户提供电商数据统计的webservice 服务。应用运行至今除偶发各类Bug, 性能问题以外，情况还算良好。 最近，小明的老板给小明布置了一个任务，希望把应用服务监控起来，以提高应用运行质量。老板的需求有三点：...
nginxtop实时监控nginx状态
huoyuanshen的博客
09-08 5769
http://www.ttlsa.com/nginx/nginx-modules-ngxtop-ttlsa/ nginx实时监视访问状态（ngxtop） ngxtop实时解析nginx访问日志，并且将处理结果输出到终端，功能类似于系统命令top，所以这个软件起名ngxtop。有了ngxtop，你可以实时了解到当前nginx的访问状况，再也不需要tai
如何监控 Nginx？
weixin_34321977的博客
01-20 296
2019独角兽企业重金招聘Python工程师标准>>> ...
zabbix监控nginx的pv和uv数据
【优快云官方推荐】
01-05 1052
1. 实验环境 1.1 服务器均为centos7操作系统 1.2 服务器ip地址 zabbix-server ip：192.168.153.183 zabbix-agent ip： 192.168.153.185 1.3 均关闭防火墙和selinux 关闭防火墙 systemctl stop firewalld 关闭selinux setenforce 0 2. zabbix-server端配置 2.1 安装并启动zabbix 安装链接： https://blog.youkuaiyun.com/m0_4667473
如何监控和诊断阿里云容器服务中 WebSocket 应用的连接状态和性能？
最新发布
08-27
<think>嗯，用户这次的问题是关于在阿里云容器服务中监控WebSocket应用，正好结合了之前讨论的WebSocket支持和引用中提到的监控工具。用户可能是个运维工程师或架构师，正在搭建实时通信系统，需要确保长连接的稳定性。 从引用内容看，用户提供的三个参考其实和WebSocket监控没有直接关系：[1]讲的是New Relic这种通用APM工具，[2]讨论BaaS平台的监控，[3]展示的是阿里云ARMS的安装示例。不过这些反而给了我提示——用户真正需要的可能是如何将通用监控方案适配到WebSocket场景。 用户上次问过阿里云容器对WebSocket的支持，这次自然延伸到监控，说明ta的项目可能进入落地阶段了。需要特别注意两点：一是WebSocket特有的长连接指标（比如连接时长、消息速率），二是阿里云生态工具的集成方案。用户没提编程语言，但引用[3]出现Java示例，可能后端是Java技术栈。 解决方案要分层设计：基础监控用阿里云自带的Prometheus+云监控，APM用ARMS或开源SkyWalking，日志用SLS。特别要强调WebSocket的四个黄金指标（连接数、错误率、消息量、延迟），这是云原生监控的标准思路。用户如果用了Ingress，还要提醒Nginx特有的WebSocket监控项。 突然想到个隐患：用户会不会混淆TCP和WebSocket监控？虽然底层都是TCP，但WebSocket有应用层协议要解析。在ARMS配置里必须开启HTTP分析才能看到Upgrade头，这个细节得写清楚。另外，用户如果追求零侵入，可能更倾向日志方案而非Agent方案。</think>在阿里云容器服务（ACK）中监控和诊断 WebSocket 应用的连接状态及性能，需结合**多维度监控工具**和**协议级分析策略**。以下是具体实施方案： --- ### 一、核心监控方案 #### 1. **阿里云 ARMS（应用实时监控服务）** - **协议级分析**： - 在 ARMS 中开启 **HTTP 协议解析**，配置过滤规则捕获 `Upgrade: websocket` 请求头[^1][^3]。 - 监控关键指标： - `WebSocket 连接数`（活跃/峰值） - `消息吞吐量`（上行/下行消息速率） - `连接错误率`（如 101 状态码异常） - **代码级追踪**： - 通过 Java Agent 注入（参考引用[^3]），在 WebSocket 服务端代码中埋点，追踪消息处理耗时和异常堆栈。 ```yaml # ARMS Agent 注入示例（Java 应用） spec: template: metadata: annotations: armsPilotAutoEnable: "on" # 自动注入 Agent ``` #### 2. **Prometheus + Grafana（自定义指标）** - **暴露 WebSocket 指标**： 在应用中集成 **Prometheus Client**，暴露自定义指标： ```python # Python 示例（使用 prometheus_client） from prometheus_client import Gauge websocket_connections = Gauge('websocket_active_connections', 'Current active WS connections') websocket_message_rate = Gauge('websocket_messages_per_second', 'Message throughput rate') ``` - **Grafana 看板**： 配置实时监控看板，重点关注： - 连接数变化趋势 - 消息延迟分布（P50/P90/P99） - 错误类型分布（如协议错误、超时断开） #### 3. **日志服务 SLS（诊断分析）** - **关键日志采集**： - 采集 WebSocket 握手日志（`HTTP 101 Switching Protocols`） - 捕获连接关闭原因（如 `1000`正常关闭、`1001`服务端终止） - **日志分析策略**： ```sql * | SELECT status, COUNT(*) as count WHERE url LIKE '%/ws%' GROUP BY status -- 按状态统计连接 * | SELECT histogram( duration ) WHERE status > 101 -- 异常连接持续时间分布 ``` --- ### 二、诊断工具链 #### 1. **网络层诊断** - **SLB 监控**： 检查阿里云 SLB 的 **4层 TCP 监控指标**： - `ActiveConnection`（活跃连接数） - `DropConnection`（异常断开数） - `PacketDropRate`（丢包率） - **连通性测试**： 使用 `telnet` 或 `websocat` 工具直接测试 SLB 端口： ```bash websocat ws://your-slb-address:port --ping-interval 10 # 测试连接稳定性 ``` #### 2. **应用层诊断** - **线程/协程分析**： 对于 Java 应用，通过 **ARMS 线程剖析** 检测 WebSocket 线程阻塞问题。 - **内存泄漏检测**： 监控 WebSocket 连接相关的内存对象（如 Session 池），通过 **Kubernetes 内存 OOMKilled 事件** 联动分析[^2]。 --- ### 三、最佳实践 1. **告警策略**（基于云监控） - 紧急告警：`WebSocket 错误率 > 5%` 或 `连接数暴跌 50%` - 预警：`平均消息延迟 > 500ms` 或 `活跃连接数接近 Pod 上限` 2. **性能优化方向** - **水平扩展**：根据连接数指标配置 HPA（自动扩缩容） - **会话保持**：若需粘性会话，在 SLB 7层监听器开启 **基于 Cookie 的会话保持** 3. **全链路追踪** 在微服务场景下（如引用[^3]），通过 **ARMS 分布式链路追踪** 将 WebSocket 消息与后端服务调用关联。 --- ### 四、配置流程图 ```mermaid graph TD A[WebSocket 应用] -->|暴露指标| B(Prometheus) A -->|输出日志| C(SLS) A -->|注入 Agent| D(ARMS) B --> E[Grafana 看板] C --> F[日志告警] D --> G[链路追踪] E --> H[性能优化] F --> I[故障诊断] G --> J[根因分析] ``` --- 通过以上方案，可实现对 WebSocket 应用的 **连接状态实时可视化**、**性能瓶颈快速定位** 及 **故障自愈能力构建**。重点在于结合协议特性（如握手过程、长连接生命周期）设计监控指标，而非仅依赖通用 HTTP 监控[^1][^2]。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值