压测过程中，需要关注的监控指标

1、服务端监控
（1）业务指标监控无异常
（2）慢查询、慢调用量无明显增加

【慢查询指的是数据库查询的响应时间过长，一般而言应该在数毫秒内完成，否则将影响系统的性能。而慢调用量是指系统中某些特定接口或者函数的调用耗时过长的情况。】
（3）服务报警异常量无明显波动
2、服务器监控
（1）cpu相关

• load.1minPerCPU [单cpu的平均load值] <0.70

【load指的是系统的负载，是指单位时间内系统处于可运行状态和不可中断状态的平均进程数，也可以理解为系统的工作负荷。而1minPerCPU则是指在过去1分钟内每个CPU所处理的平均进程数。load.1minPerCPU常用来衡量系统的负载情况。一般而言，如果load.1minPerCPU超过1，则表示系统处于高负载状态，需要优化系统资源或增加硬件配置等措施以提高系统的性能。如果load.1minPerCPU在1左右，则表示系统的负载较为平稳。】

• cpu.busy

（2）磁盘相关

• df.bytes.free.percent/mount 磁盘空间：> 15%【其中，df表示查看磁盘剩余空间的命令，bytes.free表示磁盘剩余空间的字节数，percent表示磁盘剩余空间的百分比，而mount表示磁盘挂载的路径。因此，df.bytes.free.percent/mount表示查看指定路径磁盘的剩余空间百分比。通常情况下，保持磁盘空间在一定的范围内可以避免系统因空间不足而出现故障，df命令用来获取盘符路径磁盘的使用情况，可以及时监控文件系统空间，避免因磁盘使用过量引起的程序崩溃等问题。】

• disk.io.util/device=max：<90%

【disk.io.util/device=max是一种计算机系统性能监控指标，用于评估某个磁盘设备（这里指的是设备名为"max"的磁盘）的I/O利用率。磁盘I/O利用率是指磁盘输入输出操作的占用时间与总时间的比例，是评估磁盘性能和负载的一个重要指标。

通常情况下，磁盘I/O利用率低于50%表示该磁盘还具有一定的性能储备；而高于80%则会对磁盘的性能产生负面影响，甚至会导致磁盘故障或系统崩溃等问题。对于需要高负载磁盘进行数据处理的计算机系统，可以使用磁盘I/O利用率指标来判断是否需要对磁盘进行优化或增加磁盘数量等措施来提高系统的整体性能。】
（3）内存相关

• mem.swapused.percent：< 80%
  【其中，mem表示内存，swap指的是交换空间（Swap Space），是指磁盘上预留出一块空间，当内存不足时，可以借用该空间作为虚拟内存使用；used表示已使用的部分，percent表示使用的百分比。

  因此，mem.swapused.percent表示计算机中交换空间已使用的百分比，它是衡量计算机内存使用情况的一个重要指标。当内存不足时，操作系统可能会使用交换空间来维护已经过期的内存页面，因此，交换空间的空间利用率反映了系统内存使用的紧密程度。如果交换空间已经接近满了，就说明内存极度紧缺，这会严重影响系统的性能。因此，对mem.swapused.percent进行监控可以及时发现内存使用情况的问题，做好相应的优化措施。】

• mem.memfree.percent表示计算机内存中空闲的百分比

 (4)网络相关（网络错误率，连接数等）

• net.if.in.percent 网卡入流量使用率：<80%【其中，net表示网络，if.in指的是网络数据流入（或接收）的部分，percent表示其占总量的百分比。

  因此，net.if.in.percent是一个用来衡量计算机网络接收数据占总流量的一个百分比指标。网络通常由多个接口组成，每个接口都有流入和流出的数据，该指标主要针对网络接收的数据流量所在的接口进行监控，以便检测网络接收性能是否正常。一般来说，如果接口接受的数据流量占总数据流量比例很高，那么可能说明网络使用不当或存在瓶颈问题，需要进行优化。因此，使用net.if.in.percent指标进行监控可以及时发现网络接收性能问题，帮助管理员及时调整网络配置以优化网络性能。】

• net.if.out.percent [网卡出流量使用率] <80%

• ss.closewait [CLOSE_WAIT连接数过多] 持续3分钟大于2000，需要关注，大于10000时就应中止压测 进行问题排查【其中，ss是一个Linux系统网络工具Socket Statistics的命令，用于显示已经建立的socket信息，而closewait则是其中的一种socket状态。

  具体来说，ss.closewait是一个用于监测Linux系统中处于关闭等待(CLOSE-WAIT)状态的socket数量的指标。在TCP协议中，CLOSE-WAIT状态是指一个TCP连接的一端已经发出了FIN分节，并等待对方回答确认信号，但是有可能由于对方未能及时作出回应，或者网络连接故障等原因，导致TCP连接未能正常关闭。

  当有大量的socket处于CLOSE-WAIT状态时，可能会影响系统的网络性能和稳定性，甚至可能导致网络出现问题。因此，监测ss.closewait指标可以帮助管理员及时发现和处理Linux系统中关闭等待状态的socket问题，对网络连接和数据传输进行优化和改善，提高系统的可靠性和性能。

  需要注意的是，ss.closewait只是Socket Statistics命令提供的一个指标，仅能反映当前系统中处于CLOSE-WAIT状态的socket数量，不能直接反映系统的网络连接和数据传输质量。因此，需要结合具体环境和使用场景来分析这个指标的含义和默认值。】

• TcpExt.TCPLoss [tcp有丢包] 持续3分钟>80,说明有丢包现象，应该中止压测

• icmp.ping.loss [ping丢包率] 不大于10%

（5）JVM指标

• jvm.fullgc.count 持续5分钟大于5次，应该中止压测，进行问题排查【其中，jvm表示Java虚拟机，fullgc指的是完整的垃圾回收(即Full GC)，count表示垃圾回收的次数。

  具体来说，jvm.fullgc.count是一个用于监测Java虚拟机进行Full GC垃圾回收次数的指标。垃圾回收是一项重要的Java虚拟机服务，负责清除在应用程序运行过程中已经没有被使用的内存空间，以便保障虚拟机运行的稳定和性能。Full GC是指全面的垃圾收集，它会触发Java虚拟机收集所有垃圾的运行机制，因此，Full GC的操作通常会消耗较多的资源和时间。若Full GC的次数过于频繁，会导致系统在垃圾回收时占用过多的资源和时间，进而影响应用程序的正常执行。

  因此，检测jvm.fullgc.count指标可以帮助开发人员或系统管理员了解Java虚拟机的垃圾回收情况，并在垃圾回收次数较高时采取应对措施，如适当调整虚拟机的参数配置，预估虚拟机的垃圾回收时间和处理内存泄漏等问题。】

• jvm.memory.oldgen.used.percent.after.fullgc 持续1分钟大于 60%，应该中止压测，进行问题排查【jvm.memory.oldgen.used.percent.after.fullgc是一个用于监测Java虚拟机老年代内存使用的一个指标，它是在Full GC之后检测老年代中已使用内存占比的一个指标。老年代是Java虚拟机内存中用于存放长期存活的对象的区域，随着应用程序运行时间的增长，老年代内存中已存放的对象数量不断增加，在Full GC之后，一定会发现老年代中已使用的内存占比增高，导致内存使用情况较为敏感。

  因此，监测jvm.memory.oldgen.used.percent.after.fullgc指标能够了解Java虚拟机在经过Full GC之后老年代内存的使用情况，当内存使用占比达到高峰时，就应该开始考虑优化虚拟机的调度和内存使用方案，以尽可能减少Full GC的频率，以最大化系统的稳定性和性能。】

• jvm.memory.perm.used.percent [持久区使用比例]， <90%【jvm.memory.perm.used.percent是一个用于监测Java虚拟机中永久代内存使用情况的一个指标。永久代是Java虚拟机中的一块内存区域，被用于存储静态的类信息和字符串常量等，由于其使用场景特殊，其内存的分配和释放频率较低。

  因此，监测jvm.memory.perm.used.percent这个指标可以及时观测Java虚拟机中永久代的内存使用情况，当永久代的内存使用达到一定比例的时候，可能会出现应用程序启动缓慢、系统内存紧张等问题。管理员需要及时的了解和调整永久代的内存大小，以提升应用程序的启动速度和系统的稳定性。】

• jvm.thread.blocked.count, <10【jvm.thread.blocked.count是一个用于监测Java虚拟机中被阻塞的线程数量的指标。在多线程应用程序运行过程中，有些线程可能会因为某些原因(如等待某个资源、I/O操作等)，需要暂时阻塞，直到满足某种条件之后才能继续执行。当出现大量的被阻塞的线程时，会导致系统的性能下降，甚至出现线程死锁的情况。

  因此，检测jvm.thread.blocked.count指标可以帮助管理员了解Java虚拟机中正在阻塞的线程数量，及时诊断和调整系统中线程问题，并优化线程管理策略，以确保多线程应用程序的正常运行。】

• jvm.thread.deadlock.count, =0【jvm.thread.deadlock.count是一个用于监测Java虚拟机中出现死锁的次数的指标。在多线程应用程序中，如果其中的线程互相占用对方所需要的资源，就可能会导致死锁的问题，使得应用程序无法正常执行，出现卡死等问题。

  因此，监测jvm.thread.deadlock.count指标可以帮助管理员及时发现和处理Java虚拟机中出现的死锁问题，避免线程的互相等待而导致的性能损失。管理员可以通过优化线程的调度和资源分配方式，以尽可能避免和减少死锁问题的出现，提升多线程应用程序的稳定性和性能。】

• jvm.younggc.count, 3分钟内不大于 150次

• jvm.younggc.meantime，不大于 500ms【meantime表示平均时间】