服务器监控指标

服务器日常监控巡检时，总会遇到不同服务器的不同告警，使用不同的监控工具，监控的指标有所不同，但最基础的服务器资源指标，基本都支持，比如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 20010.5g 361648242164 S 3.04.512461:08 clickhouse-server--config-file=/etc/clickhouse-+1089 root 20057554522385802644 S 1.73.04330:47java -jar V2XRealtimeServer.jar 1086 root 20058223243196283028 S 1.34.04161:58java -jar V2XRawDataServer.jar 10174 root 20058195849635124420 S 1.312.03619:07java -jar V2XWebSocketServer.jar 2105 mysql 20032056889071247584 S 0.711.31462:50 /usr/sbin/mysqld --daemonize --pid-file=/var/run+1090 root 2001489524648780 S 0.30.1420:01.32 /usr/local/redis/bin/redis-server0.0.0.0:7379 [+17013 root 20016212823441600 R 0.30.00:00.04 top 1 root 20012551626361492 S 0.00.0133: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 20058195849635124420 S 1.312.03619:52java -jar V2XWebSocketServer.jar 10166 root 20057680929219324252 S 0.011.5364:51.16java -jar V2XStatisticsServer.jar 2105 mysql 20032056889071247584 S 0.011.31463:03 /usr/sbin/mysqld --daemonize --pid-file=/var/run+1087 root 20058093284499202736 S 0.05.6226:25.74java -jar V2XApiServer.jar 1456 root 20010.5g 369520242164 S 3.04.612463:01 clickhouse-server--config-file=/etc/clickhouse-+1086 root 20058223243196283028 S 1.34.04162:45java -jar V2XRawDataServer.jar 1064 root 20057029282864402272 S 0.33.6721:06.60java -jar msbus.jar 1089 root 20057554522385802644 S 1.73.04331:30java -jar V2XRealtimeServer.jar 27891 root 2001111052251922324 S 0.00.34: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 016G 0% /devtmpfs 16G 832K 16G 1% /dev/shmtmpfs 16G 1.7G 14G 11% /runtmpfs 16G 016G 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 03.1G 0% /run/user/993tmpfs 3.1G 03.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 -oTotalDISK READ : 0.00 B/s | Total DISK WRITE : 388.00 K/sActualDISK READ: 0.00 B/s | Actual DISK WRITE: 633.68 K/sTIDPRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND 518be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.16 % [xfsaild/dm-0]20271be/4 root 0.00 B/s 0.00 B/s 0.00 % 0.00 % [kworker/3:2]2178be/4 root 0.00 B/s 407.08 B/s 0.00 % 0.00 % java -jar V2XRawDataServer.jar2229be/4 root 0.00 B/s 407.08 B/s 0.00 % 0.00 % java -jar V2XRawDataServer.jar2286be/4 root 0.00 B/s 30.61 K/s 0.00 % 0.00 % java -jar msbus.jar1801be/4 root 0.00 B/s 407.08 B/s 0.00 % 0.00 % clickhouse-server --config-f~khouse-server.pid [BgSchPool]23520be/4 root 0.00 B/s 407.08 B/s 0.00 % 0.00 % clickhouse-server --config-f~khouse-server.pid [Collector]1253be/4 root 0.00 B/s 407.08 B/s 0.00 % 0.00 % java -jar V2XRealtimeServer.jar1254be/4 root 0.00 B/s 814.17 B/s 0.00 % 0.00 % java -jar msbus.jar10253be/4 root 0.00 B/s 407.08 B/s 0.00 % 0.00 % java -jar V2XStatisticsServer.jar1698be/4 root 0.00 B/s 142.72 K/s 0.00 % 0.00 % clickhouse-server --config-f~khouse-server.pid [Formatter]1700be/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 -antpActiveInternet connections (servers and established)ProtoRecv-Q Send-Q Local Address Foreign Address State PID/Program name tcp0 0 0.0.0.0:33071 0.0.0.0:* LISTEN 2105/mysqld tcp0 0 0.0.0.0:7379 0.0.0.0:* LISTEN 1090/redis-server 0 tcp0 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] }'LISTEN16CLOSE_WAIT2ESTABLISHED273FIN_WAIT21TIME_WAIT1
2.使用netstat统计指定状态TCP连接不同进程数量
[root@localhost ~]# netstat -antp | grep -i established | awk -F '[ /]+' '{count[$8]++} END {for(app incount) print app,"\t\t",count[app] }'java 124mysqld 109clickhouse-ser 6sshd: 1redis-server 31
链接：https://www.cnblogs.com/xiaoyaozhe/p/17671281.html
（版权归原作者所有，侵删）
继续阅读
阅读原文
关键词
命令
内存
进程
负载均衡
缓存