标签：server 切换 时间差 业务 key 报警 pki 接受 磁盘
1. 观察线上耗时统计,发现间歇性耗时抖动?
2. 更甚至直接导致oom
* 报警信息分类:
* 耗时抖动报警
* 流量抖动报警
* io 超量报警
* 异常码 error 报警
* 点
接口维度: 流量大小,耗时,次数. 且要有流量入口 type,这个最好有前缀是app_入口_app 名_接口名[].
zipkin 时间轴,能够很快的识别出 网络耗时, 内部执行耗时,外部 io 耗时 这些都是关键的 耗时 key. [所以一定要把 mysql, dubbo, 文件操作都监控起来. 不然有些耗时 key 可能是混合了 内存执行+外部io执行]
内部的内存耗时如何统计?
通过 zipkin 的sr (server 接受) 和 cs(客户端发送)的时间差来定义. cs-cr (两个流量中间)这个需要有框架来完成. 特别是内部出现多线程的情况.
一个大系统由 N 个小业务系统组成, 虽然大系统找原因,拆解到各个小业务系统上. 雪崩时定位出各个系统的初始异常原因. 然后切换到下游系统或者面原因定位. ( 所以不如整体定位, 不对粗粒度的分析.)
优点: 以往只有系统级的监控(), 有了接口级的以后就好定位很多. 但是内存操作怎么定位?
* 面
外部网络, 内部gc ,磁盘问题,网络
* 另外一种是达到耗时边界, 耗时可能只增加了20ms,但是已经超过1s 中. 导致 error 报警.这种需要平时稳定性治理,耗时从高到低排查问题.耗时到底在哪里?
* 时间点刚好是定时任务执行点
排查代码,看是否有优化空间
* 规律性不明显
查看是否 gc 导致? gc 耗时过长原因是 swap
可视化 gc 和耗时时间轴.
效果 :
1. jmap -histo 46454 | head -n 20
标签：server 切换 时间差 业务 key 报警 pki 接受 磁盘
原文地址：http://www.cnblogs.com/fei33423/p/7805186.html
