1.总体统计网络调用的应用负载是否过大
netstat -tuanlp | grep pid

如果接收队列数较大，说明本应用负载过大， 需要优化处理速度或扩容；
如果发送队列数较大，说明对端应用负载过大。
使用网络状态跟踪方法，可以分析出应用、中间件、数据库等的各类 TCP 调用的负载情况。

2.线程栈分析
通过命令： jstack -l pid 分析， 可以看出线上的应用阻塞或死锁的代码位置，然后针对性的进行优化。
如果发现大量线程阻塞， 会导致线程池满而无法生成新的线程，此时可调整线程池大小。
通常表现在单个请求时本来应用响应缓慢， 当请求人数较多时，很多时候会出现请求超时异常(客户端设置的超时 等待时间已经超过了服务的响应时间)，这种情况如果程序不便于做优化，通常需要调整线程池大小，同时部署实例数 相应增加。
查看 tomcat 工作线程数：jstack pid | grep exec

3.GC分析

FGC 一列如果数值较大 (通常超过 10 以上) ，通常都是因为内存不足， 引起了 FULL GC。
S0C 和S1C：幸存区容量
S0U 和 S1U：幸存区已使用量
EC 和 EU：伊甸区容量和使用量
OC 和 OU：老年代容量和使用量
FGC：full GC 的次数
FGCT：full GC 耗费时间 (单位：秒)
以上几个是比较重要的指标， 通常 EU 接近 EC 时(即-gcutil 中， E 接近 100 时)，说明伊甸区太小，容易导致 YGC； OU 接近 OC 时(即-gcutil 中， O 接近 100 时)，说明老年代太小，容易导致 FGC。以上两种情况， 通常都是需要增加 JVM 内存大小(Xmx)的。

4.访问日志分析

从以上能看出来服务请求路径、响应状态码、服务耗时 、响应的数据量等，如果客户端慢则可以根据这些信息分 析是服务响应慢还是网络慢，或者数据量大造成的传输耗时长。
实时过滤耗时大于 1 秒的请求：
tail -fn 1000 localhost_access_log.2020 -08-28.txt| awk -F ' ' '{if($16>1000)print $0}'

有些 spring boot 应用使用 JAR 包的方式启动的应用，其访问日志的位置可以查看其 properties 配置文件： #内嵌 tomcat 日志
logging.path=/data/logs/app
server.tomcat.accesslog.buffered=true
server.tomcat.accesslog.directory=${logging.path}
server.tomcat.accesslog.enabled=true

每天保存一个

server.tomcat.accesslog.file-date-format=yyyy-MM-dd
server.tomcat.accesslog.pattern=%h %l %D %t %r %s %b %{Referer}i %{User -Agent}i
server.tomcat.accesslog.prefix=access_log
server.tomcat.accesslog.rename -on-rotate=false
server.tomcat.accesslog.request -attributes -enabled=false
server.tomcat.accesslog.rotate=true
server.tomcat.accesslog.suffix=.log
从以上得知其访问日志的位置为/data/logs/app

以上的配置， 实时查看耗时大于 1 秒的请求：
tail -fn 10000 /data/logs/app/access_log2021-01-08.log | awk -F ' ' '{if($3>1000)print $0}'

5.OOM分析
1.设置内存参数：
如果应用的内存设置如下：

则，设置 JVM 内存参数如下：
-Xms256m -Xmx256m -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/
( -Xmx 不能超过应用内存最大值，否则 jvm OOM 时，容器会被 croup oomkiller 杀掉，而导致无法进行dump)

模拟 OOM 场景：测试地址：
http://iuap-boot-train.dev.app.yyuap.com/test

JVM OOM 时，会自动 dump 出 heap 文件到/tmp/目录下。
将 dump 文件从容器中拷到宿主机，再拷到本地机器。

2.堆文件分析：
使用 JDK 自带工具 jvisualvm 进行分析。

从以上概要信息可以看出导致 OOM 的线程，点击可以显示线程栈详情

以上可以看出导致 OOM 的类和方法，以及本地变量，点击本地变量，并点击计算保留大小：

此时，可以看出来每个对象占用的内存大小，空间占用比较大的通常就是内存溢出的原因。

6.监控分析
1.资源池主机总资源分配和剩余量，主要涉及 CPU、Memory、磁盘分区的使用率指标。

2.单台资源池主机的监控资源
点击资源池工具箱中---> 查看监控页面

可在选择主机的选择框中选择对应的主机，查看单台主机的资源分配，主要指标有 CPU 总数和负载、内存的总量和使用率、根分区和磁盘分区的总使用量、tcp 连接数、以及网卡的流入流出带宽。

3.容器资源监控
对于容器的资源监控，我们可以在应用管理中的“监控与报警”页面查看

在容器监控面板中， 我们应常关注的资源为CPU 和内存在范围时间内的负载情况， 在cpu 方面需要关注资源的峰值是否有到达100%的情况，内存方面需要关注峰值是否达到分配的最大内存资源中。

4.中间件资源监控
对于技术中台自身的中间件，我们可以通过admin/admin123 账户登陆运维后台页面，在监控管理中查看对应中间件的监控指标：
例如 mysql 中的已启动时间、QPS(每秒查询率) 指标、InnoDB 的缓冲池大小等。