Bendi新闻
>
服务器资源监控告警处理方案总结

服务器资源监控告警处理方案总结

7月前

服务器监控指标

服务器日常监控巡检时,总会遇到不同服务器的不同告警,使用不同的监控工具,监控的指标有所不同,但最基础的服务器资源指标,基本都支持,比如zabbix + ,Prometheus + Grafana。

本文只针对服务器资源的相关告警,总结常用的处理方案,其他业务性指标(尤其与业务系统相关),需要针对具体业务再分析,不过处理方案的思想是相通的。

 

CPU告警

通过 top 命令,查看所有进程运行情况,在结果界面,通过 shift + p 切换视图,按照CPU使用率倒序排列,找出CPU使用率最高的进程依次分析(查看 %CPU 列)

特别关注:top命令显示的 CPU 使用率是按照单核计算的,即100%代表使用了单核的满负荷,如果服务器为4核,则理论最大为400%

[root@localhost ~]# topTasks: 197 total,   1 running, 196 sleeping,   0 stopped,   0 zombie%Cpu(s):  1.2 us,  1.3 sy,  0.0 ni, 97.3 id,  0.2 wa,  0.0 hi,  0.1 si,  0.0 stKiB Mem :  8008984 total,  1046216 free,  4712336 used,  2250432 buff/cacheKiB Swap:  7208956 total,  4409068 free,  2799888 used.  2373196 avail Mem 
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1456 root 20 0 10.5g 361648 242164 S 3.0 4.5 12461:08 clickhouse-server --config-file=/etc/clickhouse-+ 1089 root 20 0 5755452 238580 2644 S 1.7 3.0 4330:47 java -jar V2XRealtimeServer.jar 1086 root 20 0 5822324 319628 3028 S 1.3 4.0 4161:58 java -jar V2XRawDataServer.jar 10174 root 20 0 5819584 963512 4420 S 1.3 12.0 3619:07 java -jar V2XWebSocketServer.jar 2105 mysql 20 0 3205688 907124 7584 S 0.7 11.3 1462:50 /usr/sbin/mysqld --daemonize --pid-file=/var/run+ 1090 root 20 0 148952 4648 780 S 0.3 0.1 420:01.32 /usr/local/redis/bin/redis-server 0.0.0.0:7379 [+17013 root 20 0 162128 2344 1600 R 0.3 0.0 0:00.04 top 1 root 20 0 125516 2636 1492 S 0.0 0.0 133:31.76 /usr/lib/systemd/systemd --switched-root --syste+

 

根据不同进程的情况,可能会有以下现象

  1. CPU持续告警,一般为计算型应用程序,如数据清洗、转换、计算等,即该应用运行时本就会使用更多CPU资源

  2. 偶然告警,只要告警不超过CPU总资源的70%,不引起系统卡顿,原则上可以暂时不用处理

  3. 偶然告警,但告警频率逐渐增高,可能由于应用程序bug、漏洞引起

  4. 特定时间段告警,一般跟业务关联性较高,比如流量高峰

常用处理方案

  1. 根据实际业务需要,可以限制单应用的运行性能(如集群部署时,可以适当降低单节点性能),则调整应用相关配置,限制线程数、并发量等

  2. 如果公共组件该版本有相关漏洞缺陷,则根据官方指示,修补漏洞,或者升级版本

  3. 解决业务流量高的问题,使流量更均衡,如集群部署,消息缓存,负载均衡,定时任务调整等

  4. 扩容服务器资源,如增加CPU资源,或者将应用服务迁移至资源性能更高的服务器

内存告警

通过 top 命令,查看所有进程运行情况,在结果界面,通过 shift + M 切换视图,按照 内存 使用量倒序排列,找出内存使用量最高的进程依次分析(查看 RES 和 %MEM 列)

[root@localhost ~]# topTasks: 195 total,   1 running, 194 sleeping,   0 stopped,   0 zombie%Cpu(s):  1.3 us,  1.1 sy,  0.0 ni, 97.7 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 stKiB Mem :  8008984 total,   969272 free,  4721960 used,  2317752 buff/cacheKiB Swap:  7208956 total,  4409068 free,  2799888 used.  2363556 avail Mem 
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 10174 root 20 0 5819584 963512 4420 S 1.3 12.0 3619:52 java -jar V2XWebSocketServer.jar 10166 root 20 0 5768092 921932 4252 S 0.0 11.5 364:51.16 java -jar V2XStatisticsServer.jar 2105 mysql 20 0 3205688 907124 7584 S 0.0 11.3 1463:03 /usr/sbin/mysqld --daemonize --pid-file=/var/run+ 1087 root 20 0 5809328 449920 2736 S 0.0 5.6 226:25.74 java -jar V2XApiServer.jar 1456 root 20 0 10.5g 369520 242164 S 3.0 4.6 12463:01 clickhouse-server --config-file=/etc/clickhouse-+ 1086 root 20 0 5822324 319628 3028 S 1.3 4.0 4162:45 java -jar V2XRawDataServer.jar 1064 root 20 0 5702928 286440 2272 S 0.3 3.6 721:06.60 java -jar msbus.jar 1089 root 20 0 5755452 238580 2644 S 1.7 3.0 4331:30 java -jar V2XRealtimeServer.jar 27891 root 20 0 1111052 25192 2324 S 0.0 0.3 4:21.71 /usr/bin/dockerd -H fd:// --containerd=/run/cont+


 

常用处理方案

  1. 调整应用服务相关参数,限制内存占用、缓存空间大小、缓存队列长度、缓存保留时间、内存管理参数等

  2. 扩容服务器内存资源,或将应用服务迁移至高性能服务器

 

磁盘空间容量告警

通过 df -h 命令,查看磁盘各分区占用量(查看 Use% 和 Mounted on 列),然后使用 du -sh 命令逐级查找分区内磁盘使用量最高的目录

[root@ecs-fb36-0002 ~]# df -hFilesystem                                    Size  Used Avail Use% Mounted ondevtmpfs                                       16G     0   16G   0% /devtmpfs                                          16G  832K   16G   1% /dev/shmtmpfs                                          16G  1.7G   14G  11% /runtmpfs                                          16G     0   16G   0% /sys/fs/cgroup/dev/mapper/klas_host--10--169--183--49-root   95G  9.6G   86G  11% /tmpfs                                          16G  3.5M   16G   1% /tmp/dev/vda2                                    1014M  217M  798M  22% /boot/dev/vda1                                     200M  5.8M  195M   3% /boot/efi/dev/mapper/vgdata-lvdata                     100G   56G   45G  56% /datatmpfs                                         3.1G     0  3.1G   0% /run/user/993tmpfs                                         3.1G     0  3.1G   0% /run/user/1000
#分析 /data 目录,然后继续分析 /data/jnpf 目录[root@ecs-fb36-0002 ~]# du -sh /data/*4.6M /data/h540M /data/ioc-guanai242M /data/jdk54G /data/jnpf5.2M /data/redis952M /data/soft


 

常用解决方案

  1. 占用磁盘高的为日志文件,则可以参考 Linux日志管理经验总结(crontab+logrotate)

  2. 数据盘磁盘占用高(独立挂载磁盘的分区,如 /data),包括安装程序、数据文件等,则根据实际业务场景,调整相关参数,限制数据保存时间、数据压缩等

  3. 系统盘磁盘占用高(/ 根分区),则考虑将相关应用程序迁移至数据盘,如果应用程序支持,可以将安装目录整体迁移(如 修改Docker镜像存储目录,减轻系统盘负担,即配置到数据盘后,将现有数据迁移到数据盘,重启服务),否则调整相关参数,可以将数据存储目录、日志目录迁移至数据盘

  4. 扩容服务器磁盘资源,而且只能扩容数据盘,或者增加独立挂载磁盘,然后将相关业务迁移至新磁盘

 

磁盘IO告警

使用 iotop 命令(Linux系统默认没有集成,需要单独安装,CentOS可以使用 yum,也可以 官网下载安装包),查看磁盘IO最高的进程,其中 SWAPIN 列为swap交换百分比,IO> 列为IO等待所占用的百分比。

iotop使用可以参考 Iotop – Monitor Linux Disk I/O Activity and Usage Per-Process Basis 或 iotop 命令

[root@localhost ~]# iotop -oTotal DISK READ :    0.00 B/s | Total DISK WRITE :     388.00 K/sActual DISK READ:    0.00 B/s | Actual DISK WRITE:     633.68 K/s  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND                                                  518 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.16 % [xfsaild/dm-0]20271 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.00 % [kworker/3:2] 2178 be/4 root        0.00 B/s  407.08 B/s  0.00 %  0.00 % java -jar V2XRawDataServer.jar 2229 be/4 root        0.00 B/s  407.08 B/s  0.00 %  0.00 % java -jar V2XRawDataServer.jar 2286 be/4 root        0.00 B/s   30.61 K/s  0.00 %  0.00 % java -jar msbus.jar 1801 be/4 root        0.00 B/s  407.08 B/s  0.00 %  0.00 % clickhouse-server --config-f~khouse-server.pid [BgSchPool]23520 be/4 root        0.00 B/s  407.08 B/s  0.00 %  0.00 % clickhouse-server --config-f~khouse-server.pid [Collector] 1253 be/4 root        0.00 B/s  407.08 B/s  0.00 %  0.00 % java -jar V2XRealtimeServer.jar 1254 be/4 root        0.00 B/s  814.17 B/s  0.00 %  0.00 % java -jar msbus.jar10253 be/4 root        0.00 B/s  407.08 B/s  0.00 %  0.00 % java -jar V2XStatisticsServer.jar 1698 be/4 root        0.00 B/s  142.72 K/s  0.00 %  0.00 % clickhouse-server --config-f~khouse-server.pid [Formatter] 1700 be/4 root        0.00 B/s  407.08 B/s  0.00 %  0.00 % clickhouse-server --config-f~khouse-server.pid [BgSchPool]

 

与 CPU告警场景类似,根据不同进程的情况,可能会有以下现象

  1. 磁盘IO持续告警,一般为存储型应用程序,如文件系统,数据库等,即该应用运行时本就会使用更多磁盘IO

  2. 偶然告警,只要告警不超过70%,不引起系统卡顿,原则上可以暂时不用处理qq

  3. 偶然告警,但告警频率逐渐增高,可能由于应用程序bug、漏洞引起

  4. 特定时间段告警,一般跟业务关联性较高,比如流量高峰

常用处理方案

  1. 根据实际业务需要,可以限制单应用的运行性能(如集群部署时,可以适当降低单节点性能),则调整应用相关配置,限制线程数、并发量、缓存参数等

  2. 如果公共组件该版本有相关漏洞缺陷,则根据官方指示,修补漏洞,或者升级版本

  3. 解决业务流量高的问题,使流量更均衡,如集群部署,消息缓存,负载均衡,定时任务调整等

  4. 提升服务器磁盘性能,如使用SSD磁盘,或者将应用服务迁移至资源性能更高的服务器

 

TCP连接告警

通过 netstat 命令,查看和统计不同状态的TCP连接数量,以及相应的应用程序。

TCP连接状态告警,一般只存在两种:ESTABLISHED(已连接状态)、TIME_WAIT(主动关闭端的最后状态,等待操作系统回收,其中,主动关闭可以是服务端,也可以是客户端),其他TCP连接的状态,几乎不会出现数量太多,本文将不考虑。

  1. ESTABLISHED,不管是服务端应用程序还是客户端应用程序,该状态的TCP连接过多,说明该应用服务的业务量已经不是单体服务可以处理的,所以需要扩展应用服务

  2. TIME_WAIT,服务端应用程序和客户端应用程序都可能会出现,而且这是TCP连接的最后一个状态,接下来只有等待操作系统回收(回收周期根据不同操作系统,可能为30秒 - 2分钟),但是,在被回收前,该连接仍然会占用操作系统一个套接字资源,如果短时间内出现过多TIME_WAIT,可能是因为高并发且持续的短连接业务场景,最终可能会逐步将操作系统套接字资源耗尽,从而无法再创建 TCP连接

 

常用解决方案

  1. ESTABLISHED,服服务端的应用程序,可以考虑多节点部署,搭建集群或搭建负载均衡,或者将单服务拆分为多服务,分别部署到不同的服务器实现负载均衡

  2. ESTABLISHED,客户端的应用程序,可以考虑使用连接池,避免所有请求都建立新的连接,也可以考虑多节点部署客户端,或者将客户端业务拆分为多个客户端,然后分别部署到不同的服务器

  3. TIME_WAIT,可以考虑使用TCP长连接;如果是http服务端出现告警,可以考虑在客户端连接时将 connection 设置为 keep-alive,避免服务端主动断开连接;也可以从操作系统层调整相关参数,一方面开启套接字复用,一方面使操作系统更快的回收,调整方案如下

#vim /etc/sysctl.conf,增加或修改以下参数net.ipv4.tcp_tw_reuse=1net.ipv4.tcp_tw_recycle=1net.ipv4.tcp_fin_timeout=30
#调整后刷新生效sysctl -p

 

附录:TCP相关统计命令

1.使用netstat 统计不同状态TCP连接数量

特别关注:脚本中NR>2由于netstat命令前2行输出为描述信息

[root@localhost ~]# netstat -antpActive Internet connections (servers and established)Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    tcp        0      0 0.0.0.0:33071           0.0.0.0:*               LISTEN      2105/mysqld         tcp        0      0 0.0.0.0:7379            0.0.0.0:*               LISTEN      1090/redis-server 0 tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1244/sshd           
[root@localhost ~]# netstat -antp | awk -F '[ /]+' 'NR>2 {count[$6]++} END {for(state in count) print state,"\t\t",count[state] }'LISTEN 16CLOSE_WAIT 2ESTABLISHED 273FIN_WAIT2 1TIME_WAIT 1


 

2.使用netstat统计指定状态TCP连接不同进程数量


[root@localhost ~]# netstat -antp | grep -i established | awk -F '[ /]+' '{count[$8]++} END {for(app in count) print app,"\t\t",count[app] }'java          124
mysqld 109clickhouse-ser 6sshd: 1redis-server 31

链接:https://www.cnblogs.com/xiaoyaozhe/p/17671281.html

(版权归原作者所有,侵删)

微信扫码关注该文公众号作者

来源:马哥Linux运维

相关新闻

打造人力资源一站式服务解决方案,SmartDeer助力医健企业出海多人同时导出 Excel 干崩服务器!新来的大佬给出的解决方案太优雅了!“分文未付,造成很大损失”!上市公司把一地城管局告了,涉及近3年垃圾处理服务费上千万元!1 亿大单、100 台 GPU 服务器5278 万大单:678 台服务器、339 套操作系统京东发行稳定币;AI服务器大厂豪气分红115.2亿;小米二期工厂附近挖出古墓?王化:假的|AI周报4000 万大单:服务器、业务系统、网络安全设备、数字孪生等4.1 亿大单、4841 台服务器1277 万大单:服务器 89 台、集中存储 1 台、交换机 16 台、路由器 1 台、操作系统 1 套想跑千亿大模型?算力厂商放大招!CPU通用服务器成为新选择GPU训Llama 3.1疯狂崩溃,竟有大厂用CPU服务器跑千亿参数大模型?如何“榨干”本地服务器or数据中心如何在 Linux 上轻松设置 OpenVPN 服务器和客户端:完整教程与实用技巧1.8 亿、海光服务器大单Node.js 22:服务器端 JavaScript 的未来开源新动力:FreeBSD的近亲“MidnightBSD 3.2”发布;DNS 服务器“BIND 9.20”发布老黄再出奇招!首推「特供版」GB20服务器,或将明年上市3.8 亿大单、5000 台 GPU 服务器印度IT工程师被解雇后删了前东家180台服务器、造成几百万损失服务器变革:PCB层数、材质等技术升级2024年CPU行业概览:信创带动服务器CPU国产化一个CentOS“倒下去”,更多开源创新服务器操作系统站起来SpaceX 估值望达 2100 亿美元;百度:超千万高考生用 AI 报志愿;《魔兽》国服回归首日服务器崩溃 | 极客早知道前端最新趋势:JS正在向服务器端转移、开发者最爱Vue技术栈、Bun越来越受关注
logo
联系我们隐私协议©2024 bendi.news
Bendi新闻
Bendi.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Bendi.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。