大家好，我是架构摆渡人。这是流量治理系列的第8篇文章，如果有收获，还请分享给更多的朋友。

限流是一种自我保护的方式，虽然保护了系统的稳定性，但是对用户体验是有影响的，那么在触发的时候我们能不能够知道影响范围有多大呢？

这就需要有完整的监控体系来帮助我们去了解限流的一些信息，今天跟大家聊一聊需要经常关注的指标。如果你要构建限流的监控大盘，那么这些指标或许对你有参考意义。

有没有触发流控？

首先我们要关注的重点就是到底有没有触发限流，一旦触发了限流，也就意味着流量的突然上涨，是正常的活动导致，还是被爬虫了，还是什么原因。

上图展示了最基本的指标数据，一眼就能看出是否有流控，流控的力度有多大。当然我这只是一个示意图，真正的监控都是有很多图表，曲线之类的，会更直观更精美。

哪些接口被流控了？

通过监控大盘，能够很直观的看到当前被流控了。这个时候你肯定想知道，怎么会流控这么多量，到底是哪些接口被流控了，所以第二个指标就是更细粒度的接口级别。

除了接口级别的流控我们需要直观的展示出来，其实还有很多更细粒度的流控指标。比如MQ消费的流控，Mysql Sql级别的流控等。

流控时的资源利用率

流控时需要关注的还有依赖的资源利用率，比如当前机器的CPU, 内存等是否过高。数据库的性能是否有下降，如果其他很多指标都比较正常，那么可以提高限流的门槛，也就是不需要限制这么低的水位了，稍微放高点。

所以，在监控大盘中还要有这些基础设施的指标信息。当然有写接口可能不是直接走数据的，有可能是一个聚合接口，能力都是下游提供的，那么这种接口需要关注的就是下游服务调用的RT,如果下游RT正常，那么也可以提高限流阀值。

流控预警

前面讲的都是已经触发了流控，我们需要通过哪些指标哪判断当前的情况如何，能否提高限流阀值。其实一旦发生限流，也就意味着用户体验受到了影响，那么能否有一些措施可以提前让我们准备起来，这就是流控预警。

举例说明：你的限流阀值是1WQPS, 当前QPS正在缓慢上升，到底6000QPS的时候，监控提前进行预警，电话或者短信都可以，这样你就知道有流量突发情况，而且即将达到限流的阀值，这个时候你就去看监控大盘，再根据我们之前说过的那些指标去判断，是否要提高一下阀值，减少用户的影响。