因为之前出了一个线上部署了404链接的小事故，组内决定在原有的定时监控上加一个“每10分钟检测一次线上404次数”的告警。
因为监控的数据都是通过clickhouse存储，所以数据的采集需要写clickhouse的SQL脚本，这次写还get了获取clickhouse日期的方法，之前都是通过js手动获取当天日期，然后插到sql中去查询。其实clickhouse的SQL语句已经内置了时间相关的函数，具体可以看这里（感谢翻译大佬的贡献，不过想微微吐槽一下翻译把API也给翻译成了中文，导致看半天发现怎么没发现对应的api，建议中英文结合查看）
言归正传，说回这个告警脚本，这个告警的原理是每10分钟查一次数据，看看线上404的告警会不会超过阈值，如果超出则告警到企业微信群。
一开始写的时候就想到了一旦数据超出，那么每10分钟就会收到一条告警，这样工作群里就会充斥告警信息，污染了工作群的聊天记录。所以还需要开发一个告警屏蔽功能，打开屏蔽功能后即使超出阈值，告警也不会继续发送。
屏蔽功能简单的实现就是在告警程序上加一个/close接口，只要调用接口并传入对应的定时脚本名称，指定的定时脚本就会停止告警。再写一个/open接口允许定时脚本继续运行。
/close传入的脚本名称就需要保存在一个地方，这样每次告警脚本运行的时候都判断一次，是否要执行当前的告警脚本。那么，存在哪里合适呢？
说到存储，最先想到的就是数据库了，使用数据库存取数据。但是一个数组大小的数据，用数据库就有点小题大做了。
第二种方法是脚本生成一个JSON文件，通过读写JSON文件里的配置，控制定时脚本的运行。这是个好办法，但是程序手动读写文件总是给我一种“万一读写出错了怎么办”的不安全感。于是我使用了第三种方法。
因为定时脚本是Egg.js写的，Egg程序可以读写config这个属性，那么我只要把需要屏蔽的脚本名保存为config里的一个属性就可以了。于是，我在config里配置了一个disableSchedule属性：
// config.default.js
export default = appInfo => {
const userConfig = {
// 关闭的告警
disableSchedule: [],
};
}
然后通过/close和/open读写disableSchedule数组，岂不是大功告成？而且本地测试的时候也是没问题的。于是写完后，第二天就上线了。
多进程部署导致的读取配置不一致
部署的时候，使用了egg默认的npm run start让程序成功运行了起来，功能上线的第一天晚上，404告警就出现了，但是个问题不大的404页面，机智的我马上开启了告警屏蔽功能，没想到10分钟后，告警又出现了！再过10分钟又一条！很显然，保存在config里的配置并没有成功生效，无奈只好手动先把定时脚本停止了再看问题出在哪。
调用/close 的时候，明显配置是成功添加了，但是读配置的时候，读到的配置却是空的，可以猜测到脚本可能是读了一份“不一样”的配置。一番检查后发现，有多个相同的脚本进程在机器上运行，难道的egg默认开启了多进程部署？查了一下文档发现还真是：
启动命令
$ egg-scripts start --port=7001 --daemon --title=egg-server-showcase
如上示例，支持以下参数：
--workers=2 框架 worker 线程数，默认会创建和 CPU 核数相当的 app worker 数，可以充分的利用 CPU 资源。
egg 默认创建和 CPU 核数相当的 app worker 数，这样在调用接口改写配置的时候，可能修改的是 worker1 的config，定时任务读config的时候，读到的却是 worker2 的配置，导致修改的配置无效，除非统一把所有线程上的 config 都修改了。或者，将线程改为只启动一个，修改配置：
// package.json
"scripts": {
"start": "egg-scripts start --daemon --workers=1 --title=egg-server-failUrl-schedule"
}
增加参数workers=1，将进程设为1个，这样定时任务就会只读取 worker1 的配置，不会出现设置无效的问题了。