工具范围：平台自带服务质量监控、堆分析工具、线程分析工具、arthas、visualvm、zabbix监控等。分析内存问题（OOM、GC）首先要建立JVM内存知识结构。
系统交付客户使用时，需要给客户同步相关运维知识，尤其是监控和告警机制。随着时间推移，数据库数量增大、业务应用增多后，可能出现意想不到的问题。需要相应的监控巡检和告警机制，提前对系统进行人工干预或者排查问题。
SLA是用同进程Java统计运行情况，当JVM运行压力小时，可有效统计，运行压力大时，可供参考。
巡检关注1：>3秒的线程，此处太慢轻则影响用户体验，严重累积则导致系统不可用/宕机。
点击时间按钮打开堆栈，分析慢的原因。可能是慢sql、请求外部接口、处理大量数据等。
线程卡住之后，只能重启平台解决，无法kill掉线程。（强行kill可能导致资源泄露或其他不可控问题，java已废弃线程的stop方法）
巡检关注1：heap使用率。app server默认在heap达到配置的75%时进行FullGC（受参数-XX:CMSInitiatingOccupancyFraction控制），如果heap使用率连续若干分钟均处于75%以上运行，则需要导出heap dump进行分析，此时可能有内存泄露。
巡检关注2：GC时间，GC过慢会影响系统运行。
数据库监控工具有多种，蓝鲸或zabbix使用居多，或者用自带命令分析log文件，每家客户的手段不太一样。
巡检关注1：返回条数>1W的数据，思路同SLA中的SQL返回条数告警，需要配合使用，区别：
优点：不受Java服务器宕机影响，理论上可记录所有事故SQL
缺点：只能记录SQL，无法准确判断AWS的调用代码位置，需要根据经验去排查平台。
