報(bào)警平臺(tái)

整個(gè)平臺(tái)依賴(lài)于es進(jìn)行日志存儲(chǔ)，客戶(hù)端通過(guò)文件保存日志，并推送到es中。服務(wù)器端從es拉取日志進(jìn)行解析并報(bào)警。

1.業(yè)務(wù)報(bào)警日志格式的設(shè)計(jì)

一個(gè)優(yōu)雅的日志格式設(shè)計(jì)，能夠有效的改善內(nèi)存使用，硬盤(pán)存儲(chǔ)，網(wǎng)絡(luò)資源占用等問(wèn)題。這里通過(guò)借鑒別人的一些經(jīng)驗(yàn)高性能的智能日志,來(lái)設(shè)計(jì)一個(gè)合適的日志格式。

2.報(bào)警日志SDK

sdk必須要滿(mǎn)足的幾點(diǎn)：
1.異步保存日志（降低引入sdk對(duì)系統(tǒng)帶來(lái)的影響）

sdk內(nèi)維護(hù)一個(gè)存儲(chǔ)報(bào)警日志的list。每次有報(bào)警日志時(shí)，只用添加到list中就行。

2.定時(shí)寫(xiě)入日志文件（通過(guò)隊(duì)列的形式，定時(shí)寫(xiě)入本地文件，降低對(duì)文件的頻繁寫(xiě)入，當(dāng)然可以根據(jù)日志的級(jí)別來(lái)確定）.初版需要先寫(xiě)入本地文件，后期需要加上直接寫(xiě)入es或者kibana等的方式，這樣，不用落盤(pán)直接將數(shù)據(jù)送出去。
3.定義日志文件需要的一些基礎(chǔ)信息：項(xiàng)目枚舉，level枚舉
4.針對(duì)不同項(xiàng)目提供不同的方法接口

3.上報(bào)報(bào)警日志

在docker環(huán)境下，可以通過(guò)阿里開(kāi)源的log-pilot來(lái)進(jìn)行日志上報(bào)。如果沒(méi)有在docker環(huán)境下，可以通過(guò)logstash將文件上報(bào)到es中。上報(bào)這里，針對(duì)不同的并發(fā)情況進(jìn)行調(diào)優(yōu)，等實(shí)戰(zhàn)的時(shí)候再更優(yōu)化的細(xì)節(jié)。

4.報(bào)警日志的分析與報(bào)警

其實(shí)有了報(bào)警日志之后，最重要的是，如何優(yōu)雅把這條報(bào)警信息及時(shí)的推送給對(duì)的人。以及在通知過(guò)之后，該條報(bào)警信息時(shí)候已經(jīng)被處理，被誰(shuí)處理了。所以這里，大概梳理了幾個(gè)功能點(diǎn)：
1.定時(shí)從es拉取報(bào)警信息

    通過(guò)定時(shí)任務(wù)來(lái)實(shí)現(xiàn)的拉取報(bào)警信息，開(kāi)始我想的是定義一個(gè)時(shí)間差，每隔幾秒去讀取es某個(gè)時(shí)間段的數(shù)據(jù)，要保證所有時(shí)間段都是相接的。
但是這樣有個(gè)問(wèn)題就是，es在存儲(chǔ)數(shù)據(jù)的時(shí)候是有一定的延遲的，數(shù)據(jù)創(chuàng)建完成到完全存儲(chǔ)肯定是要在數(shù)據(jù)創(chuàng)建之后的時(shí)間發(fā)生的。這個(gè)時(shí)間
差由中間的網(wǎng)絡(luò)傳輸以及磁盤(pán)消耗導(dǎo)致的。所以這時(shí)按時(shí)間段去拉數(shù)據(jù)，會(huì)因?yàn)檠舆t的問(wèn)題，導(dǎo)致數(shù)據(jù)丟失。
    所以，我們采用了確認(rèn)更新的策略，通過(guò)對(duì)所有已讀的數(shù)據(jù)進(jìn)行標(biāo)記，來(lái)確認(rèn)我們消費(fèi)過(guò)的數(shù)據(jù)不會(huì)被重復(fù)消費(fèi)，同樣每次也只獲取到未消費(fèi)的數(shù)據(jù)。

2.根據(jù)報(bào)警信息，推送（釘釘，微信，郵件）給指定用戶(hù)組內(nèi)的所有用戶(hù)。用戶(hù)確認(rèn)接收?qǐng)?bào)警信息。
3.統(tǒng)計(jì)分析時(shí)間段的報(bào)警信息。

5.系統(tǒng)監(jiān)控的報(bào)警日志