监控
监控指标的建设，一般按照业务维度进行搭建，尽量实现一个页面上，能够展示这个业务的服务状况。比如，消息和会话就可以作为一个业务维度，或者分开也行。
接口维度
1.相关业务整体接口指标【qps，延迟，成功率】【反应系统的整体状态】
2.接口单维度指标【qps，延时，成功率，错误码分类】【反应单个接口的状态，出错时，根据错误码快速定位】
3.接口上游指标【qps，延时，成功率】【区分上游，当接口流量暴增时，可以快速定位是那个上游的流量，从而快速进行处理】
3.接口下游指标【qps，延时，成功率】【区分下游，当接口成功率下降时，可以快速定位是哪个下游的服务，从而快速进行处理】
补充：接口的metric监控，主要依靠rpc框架来做，需要rpc框架在设计的时候考虑好以上几个问题
实例维度
1.cpu,内存，io，带宽
2.gc次数，gc时长，goroutine数量
中间件监控
1.mysql读写qps
2.mysql慢查询
3.redis缓存命中率
4.redis内存使用率
5.kafka队列延迟【从投递到消费端】
6.kafka消费耗时【从消费到，到消费完成】
7.kafka消息堆积(log)，按照消费组来区分
中间件本身的基础监控：比如，mysql实例的cpu，io，带宽，内存，kafka的内存，磁盘等等
业务监控
业务强相关的监控，比如，设置缓存以后，要监控缓存的命中率。
IM业务，要监控消息的到达率，到达延迟
长连业务，如果做了补推机制，也要监控补推的比例等等
模块监控
一个模块所有的业务指标，比如数据库qps，成功率，延时。
redis的qps，成功率，延时。
kafka的qps，延时，成功率。
效果图如下：
日志
日志除了记录系统的运行信息，一个重要的作用就是用来做告警，所以日志级别就显的格外重要了，实际使用中，一般有以下几个日志级别
debug【一般不带到master】
info【打印请求和返回，方便定位问题】
warn【配置固定的阈值，根据业务情况，达到一定水位线以后告警】
error 【一旦出现一条，必须告警】
基于以上几个规则，在实际使用中，有以下几个注意点
1.业务错误只打warn，不打error，比如，用户往一个不存在的群里面发消息
2.error是真正的系统错误才打，比如，接口超时等等
【重点：一定要想办法区分开系统错误和业务错误，否则，后面很多事情将变的非常难做】
3.错误的第一现场打印日志，出错的时候，要把错误方法的所有入参都打出来，敏感信息除外，比如token或者secret。方便复现，排查。
4.不要直接打印pb结构的内容，否则如果某个pb结构中加了敏感信息，也会被打印出来。要打印的结构体最好自己定义，并且自己实现string方法。
5.不用通过日志来调试，最好直接本级注册到注册中心，然后单步调试。
6.任何日志级别都不能打印token和secret等敏感信息，因为日志级别是可以动态调整的，本身不能够保证安全。
错误码的区分
grpc的接口中，上游返回的错误，需要明确区分出是系统错误还是业务错误，如果是预期内的业务错误，则打warn级别的日志，否则，打error级别的日志
var ErrBiz =errors.New("biz err")
errors.Is(err,ErrBiz) //可以用这个api来进行判断
