这是一个在优化前端异常上报时出现的问题
❝山月人肉盯着异常报了半个小时,但是在 Sentry 中仍然没有收到一条报错,郁闷不已,反复踌躇徘徊。喝一杯水后顿悟,然后发现了那条 http 状态码为 429 的异常上报请求。❞
刚开始碰到 Sentry 中未收到报错 (Event) 时,一直在尝试去找 Sentry 服务器端的 Inbound Filter
设置以及 Sentry 客户端的 beforeSend
设置,这两个均与 Event
的过滤有关。以致于耽搁了半个小时。
「日志是排查问题时最重要的线索!!!」
后来回过神来,在控制台网络中找到了 http 429 的这条请求,而 429 的描述语为 Too Many Requests
。出现了 429,往往代表着 API 被限流了。
在 Sentry 上对于异常上报设置了 Rate Limit
,每小时最多只能上报 1000 个 Event,导致许多异常被丢弃。
Rate Limit By Org
Rate Limit By Project
「图中红色的部分是丢弃的 Event,可以看出丢弃的比捕捉到的更要多!」
基于以往上报及丢弃的 Event 数量,往大调整 Rate Limit
Rate Limit By Org
devtools -> network
来查询日志,如果本次是后端上报异常的话,就会较难调试,可能得用上一天时间关于异常监控系统,很多开发同学往往只注重如何去上报,但这远远不够!因为只注重如何去上报只是异常上报链路中的一个生产侧,不谋全局者不足谋一域。此时开发更应该在更高的角度去思考:
这里拓展一些关于异常上报的注意点,关于 Sentry 异常上报信息有三大关键字段及两大核心概念
三大关键字段指:
Tags
,也可以认为是 Index
,作为索引,方便查询。如 userId,errorCode 前端还会涉及到浏览器及一些业务相关要素。Stack
,异常堆栈,方便在异常系统直接定位代码Context
,相关上下文信息,如发请求的 url
及 body
,执行数据库查询的 sql
等两大核心概念:
Event
,报一次错就是一个 Event
Issue
,如一个 Bug 导致了 N 次 Event,则会聚合为一个 Issue
,关于聚合算法,会根据 fingerprint
来辨别如果以上这些做好了,无论采用 ElaticSearch
还是 Sentry
做异常上报都是无关紧要的。
❝好吧,其实还是有很大不一样的,比如 Sentry 作为专一的异常上报系统,则会有更好的 Alert,而 ES 做 Alert 就很难了。且 Sentry 对 User Feedback,Event Group,Bug workflow 及与 jira,gitlab 的集成更好。 ❞
关于 Node
服务端的异常上报可以参考我以前的文章:
[1]Node 异常结构化与上报: https://shanyue.tech/node/error.html