杂谈

监控运维系统已经运行一年有余, 已经是开发和运维人员不可或缺的工具了, 几乎所有人上班的第一件事就是打开监控系统, 查看服务器状态. 即使出门在外, 也用可以用手机访问. 经过大量使用之后, 很多问题暴漏出来了, 该改的改, 改优化的优化, 这里说一下这一年的优化动作.

微信报警优化

如果服务器发生状况, 发送微信到用户, 可是如果处理不好, 就会产生微信轰炸, 所以后面定义了几个规则, 保证不产生信息轰炸.

• 分组订阅, 每个人只关心负责的服务器分组
• 单机报警限制, 如果一个服务, 在2.5分钟之内发生连续报警, 只触发第一次微信报警
• 单用户报警限制, 单个用户2.5分钟之内, 同一组服务器, 只接受一次报警

这样可以有效的避免微信轰炸.

监控点自定义

不同的人, 关心的指标不一样, 尽量把左右的监控点, 对所有的用户都自定义, 包括但是不限于

• 自定义显示名称
• 自定义是否显示

流量优化

最开始的时候, 数据是全量推送, 所有服务的相关数据, 都会推送的客户端. 当服务器数量小的时候, 用户少的时候, 这样是没有问题的. 一旦服务器多了, 数据量膨大, 整个服务端都没法抗住这个流量.

• 注册原则, 客户端往服务端注册多少数据, 服务端推送多少数据(所见即所得)

命令记录

经常会有同事误操作, 发错命令, 导致服务瘫痪, 追查责任的时候, 没法知道是谁发送的命令. 所以一定要加入命令记录的功能. 追责的时候, 好拉出来打. 🙁

后续

优化是不断的在进行的, 随着时间的推进, 大家对监控运维的要求会越来越高(越来越难伺候), 里面还是有些问题, 比如angularjs的性能不够高, 偶尔出现数据卡顿的现象. 而且页面开久了, 数据累积, 也会让页面变得卡顿. 经常chrome动不动就上G的内存, 后面估计会请专业的前端来优化页面.

总计

自由, 一定要对用户够自由, 不要写死太多东西, 否则一定会吃亏!