监控指标的常见异常规则
我们收集各种层级的数据, 包括: 硬件层, hypervisor层, VM OS 层, JVM 层, 应用框架层, 应用层 或者基于 Docker 的 Node 数据, Pod 数据, Container 数据. 收集这么多数据大多数是为了出错时做分析, 不出错时做优化用. 把数据都转为时序数据后, 就可以对它们做异常检测和提前预知.
常见的异常检测是基于时间周期的, 比如每周的数据基本模式都是一样, 每天的数据模式也大致相同, 对比去年或前年的数据基本也可以用. 影响这些异常检测效果的一般有下面几种情况:
- 有些国家的冬令时和夏令时之间的转换;
- 有较大影响力的体育,政治事件, 比如美国超级碗会影响在线销售订单, 英国王室婴儿出生新闻会影响英国在线销售订单;
- 某些时间点的较大规模促销, 抢购会影响异常检测;
- 过年, 过节会影响, 这里有很大程度是因为无法发货, 或者发货也到不了导致的不购买;
最近几年, 除了使用对比历史数据(前几分钟, 昨天, 上周同时, 上月同时, 去年同时), 更多人想使用大数据+人工智能去检测和推测异常, 整体还没有看到有比较好效果的算法;
除了使用对比历史数据, 人工智能的方法, 还有很多通过简单的计算对比就能找出的异常, 比如下面这些:
- JVM 可用堆内存稳定状态下持续减少
通常情况下, JVM 可用堆内存都是呈现锯齿状, 每次老年代回收都会导致可用更多, 然后持续减少, 直到下次回收. 但是如果每次回收后的可用量还是在持续减少, 那么一般情况下就发生了内存泄漏. - Tomcat 的忙碌线程数持续增加
稳定状态下, tomcat 的忙碌线程数会随着流量的大小变化, 不够一旦流量减少, 忙碌线程数会降下来. 若流量基本稳定,则忙碌线程数也基本稳定. 如果发现忙碌线程数长时间来看是持续增加的, 那么很有可能某些线程已经卡死, 不能继续服务了. 常见的比如: 某些线程进入了死循环, 不能退出; 某些线程 block 在某些永远拿不到的资源上面; 某些线程在访问外部服务, 设置的 socket read timeout 为0; - 同一 LB 后面的相同服务的忙绿线程数不一致
一般同一个 LB 后面的相同服务分配的流量基本一致, 所以他们的 tomcat 忙碌线程数也应该基本一致, 若出现较大差别(直接的方差比较大), 那很有可能是某些线程卡住了. - 平均忙碌线程数 不等于 tps 乘以 平均transaction time
假如一个服务的平均的 transaction time 是100ms, tps 是10个每秒, 那么它基本只需要一个忙绿线程数, 即: appServerBusyThreads = tps * transactionTime. 如果这2个数值差别比较大, 那么很有可能出现了问题.