如果你所在的公司/团队还 没有应用监控基础设施 ,如何让系统在上线后及时知道发生了问题? 其中一个非常简单的方案就是对日志进行实时扫描监控.

怎么做?

不管你用的是什么框架,你的日志库应该可以设置日志级别.将日志级别打印在日志行的最开始.
例如:

    [ERROR] xxx
    [WARN] xxx
    [INFO] xxx
    [DEBUG] xxx

这样,你在应用中添加一个固定频率的调度任务,这个任务会扫描新增的日志数据,通过判断行数据的开始几个字符来确定你是否要进行告警,例如发邮件,发短信.这样你接受到通知后去查看日志发生了什么.

小技巧: 设置一个标记位,记住你上次扫描到了文件的哪个位置,避免重复处理. 标记位如果是基于内存的,扫描前先判断下是否为0,如果为0就只记下当前的文件尾部位置,不扫描处理.因为通常情况下系统重启后的日志是追加到当前日志文件后面的.这样做就可以从系统启动后的日志位置开始扫描.

实施

ERROR级别日志每10秒扫描一次日志,统计次数后告警.
WARN级别日志每小时扫描一次日志,汇总统计次数后告警

进一步

告警的方式可以是邮件,短信,微信消息.所以这一块你可能需要做成一个服务接口,接受告警数据后触发某种告警通知.成熟的工具有Zabbix , Nagios 等或者简单点(可靠性考虑)再编写个服务接口(考虑到升级维护,功能性,扩展性,还是用开源的专业系统比较好)

你还需要查看日志发生了什么事情,如果系统甚少,你可以直接上服务器查看日志文件检查问题.如果是大规模服务集群,为了快速定位问题,你需要一个分布式的日志收集系统.开源流行的解决方案有 EFK 日志采集 .

思考本质

告警不能解决你的问题,而系统中又必然出现问题.所以在设计系统时,尽量能"恢复".
解决方案:

• 连续的大量任务逻辑,拆分成多个的小任务
• 操作幂等.做一次和做N次结果相同
• 事件驱动.一次一小步