报警平台的设计与实现

报警平台

整个平台依赖于es进行日志存储，客户端通过文件保存日志，并推送到es中。服务器端从es拉取日志进行解析并报警。

1.业务报警日志格式的设计

一个优雅的日志格式设计，能够有效的改善内存使用，硬盘存储，网络资源占用等问题。这里通过借鉴别人的一些经验高性能的智能日志,来设计一个合适的日志格式。

2.报警日志SDK

sdk必须要满足的几点：
1.异步保存日志（降低引入sdk对系统带来的影响）

sdk内维护一个存储报警日志的list。每次有报警日志时，只用添加到list中就行。

2.定时写入日志文件（通过队列的形式，定时写入本地文件，降低对文件的频繁写入，当然可以根据日志的级别来确定）.初版需要先写入本地文件，后期需要加上直接写入es或者kibana等的方式，这样，不用落盘直接将数据送出去。
3.定义日志文件需要的一些基础信息：项目枚举，level枚举
4.针对不同项目提供不同的方法接口

3.上报报警日志

在docker环境下，可以通过阿里开源的log-pilot来进行日志上报。如果没有在docker环境下，可以通过logstash将文件上报到es中。上报这里，针对不同的并发情况进行调优，等实战的时候再更优化的细节。

4.报警日志的分析与报警

其实有了报警日志之后，最重要的是，如何优雅把这条报警信息及时的推送给对的人。以及在通知过之后，该条报警信息时候已经被处理，被谁处理了。所以这里，大概梳理了几个功能点：
1.定时从es拉取报警信息

    通过定时任务来实现的拉取报警信息，开始我想的是定义一个时间差，每隔几秒去读取es某个时间段的数据，要保证所有时间段都是相接的。
但是这样有个问题就是，es在存储数据的时候是有一定的延迟的，数据创建完成到完全存储肯定是要在数据创建之后的时间发生的。这个时间
差由中间的网络传输以及磁盘消耗导致的。所以这时按时间段去拉数据，会因为延迟的问题，导致数据丢失。
    所以，我们采用了确认更新的策略，通过对所有已读的数据进行标记，来确认我们消费过的数据不会被重复消费，同样每次也只获取到未消费的数据。

2.根据报警信息，推送（钉钉，微信，邮件）给指定用户组内的所有用户。用户确认接收报警信息。
3.统计分析时间段的报警信息。

5.系统监控的报警日志