收到告警消息后,如何快速定位问题
- 关联版本发布:如果是新版本发布后新产生的告警,就首先考虑告警与发布的内容之间的关系,如果不能快速解决,就需要回滚版本
- 收集多组告警:收集一起出现的所有错误错误消息或错误日志,分析什么原因可能导致一组错误。 比如:
Unable to send PING command over channel: [id: 0xaabc5c3c, L:/9.165.34.233:57438 - R:10.62.15.30/10.62.15.30:6380]
Exception: Command execution timeout for command: (PING), params: [], Redis client: [addr=redis://10.62.15.30:6380]
代码语言:javascript复制Redis server response timeout (3000 ms) occured after 3 retry attempts. Increase nettyThreads and/or timeout settings. Try to define pingConnectionInterval setting. Command: (ZRANGEBYSCORE)
上面两个错误是突然出现的,如果只看第一个错误,就可能以为是redisson的bug(https://github.com/redisson/redisson/issues/3273)。实际上是因为命令ZRANGEBYSCORE在大key上执行,耗时太长,引发其他请求也超时
- 尽早定位:收到告警消息,需要尽早定位问题,防止错误扩散
有一次发布后,收到一个"订单不存在"的告警消息,因为看起来问题不大,也没有影响用户下单,就没有第一时间去定位,等第二次出现"结算单不存在"时,才觉得有新的问题,原来是自定义多数据源时,漏了自定义事务管理器,导致数据不一致
- 快速跳转:告警消息中需要携带关键信息,特别是调用链的traceId,并且可以点击跳转
- 减少无用告警:防止错误消息被无效消息淹没