如果你所在的公司/团队还 没有应用监控基础设施 ,如何让系统在上线后及时知道发生了问题? 其中一个非常简单的方案就是对日志进行实时扫描监控.
怎么做?
不管你用的是什么框架,你的日志库应该可以设置日志级别.将日志级别打印在日志行的最开始.
例如:
[ERROR] xxx
[WARN] xxx
[INFO] xxx
[DEBUG] xxx
这样,你在应用中添加一个固定频率的调度任务,这个任务会扫描新增的日志数据,通过判断行数据的开始几个字符来确定你是否要进行告警,例如发邮件,发短信.这样你接受到通知后去查看日志发生了什么.
小技巧: 设置一个标记位,记住你上次扫描到了文件的哪个位置,避免重复处理. 标记位如果是基于内存的,扫描前先判断下是否为0,如果为0就只记下当前的文件尾部位置,不扫描处理.因为通常情况下系统重启后的日志是追加到当前日志文件后面的.这样做就可以从系统启动后的日志位置开始扫描.
实施
ERROR级别日志每10秒扫描一次日志,统计次数后告警.
WARN级别日志每小时扫描一次日志,汇总统计次数后告警
进一步
告警的方式可以是邮件,短信,微信消息.所以这一块你可能需要做成一个服务接口,接受告警数据后触发某种告警通知.成熟的工具有Zabbix , Nagios 等或者简单点(可靠性考虑)再编写个服务接口(考虑到升级维护,功能性,扩展性,还是用开源的专业系统比较好)
你还需要查看日志发生了什么事情,如果系统甚少,你可以直接上服务器查看日志文件检查问题.如果是大规模服务集群,为了快速定位问题,你需要一个分布式的日志收集系统.开源流行的解决方案有 EFK 日志采集 .
思考本质
告警不能解决你的问题,而系统中又必然出现问题.所以在设计系统时,尽量能"恢复".
解决方案:
- 连续的大量任务逻辑,拆分成多个的小任务
- 操作幂等.做一次和做N次结果相同
- 事件驱动.一次一小步