賽克藍德日誌分析軟件(SeciLog)15年總結

    需求

    隨着現代化企業的發展，企業對信息化的依賴程度愈來愈高，企業爲了保障業務正常運行，須要部署大量的設備和軟件系統：包括防火牆、入侵檢測、掃描器、堡壘機、監控、OA、ERP、業務系統等；根據每家企業的狀況不同，部署的產品也會不同，有用商業軟件的，也有用免費軟件的，甚至是開源軟件的，可謂五花八門。在部署這麼多系統後，會帶來不少新的問題，常見的問題有以下幾條：

•  每一個系統都會有本身的界面，都有本身的告警，都有本身的報表，面對這麼多的系統，對運維管理帶來很大的挑戰。

• 每一個系統都是從本身的視角來看待問題，功能上相對獨立，缺乏融會貫通的能力，每當遇到問題的時候，須要從一臺臺設備中去登陸，而後查看相關日誌，效率低下。

• 每一個系統中的日誌格式都是不同的，各有各的表達方式，就算同一件事情，表達的內容也是不同的，這就給人員帶來很大的困惑和學習成本。

• 每一個系統中天天會產生大量的告警，企業中的運維人員相對較少，這就使不少的日誌沒有時間去查看，給系統的運行帶來很大的隱患。

• 當一件事情發生的時候，在不少的系統中都有體現，但每一個系統又相對對立，致使大量的重複告警，沒法進行跨產品的事故分析。

• 每一個系統的磁盤都是相對固定的，每當磁盤空間不夠的時候，不少運維人員想到的第一件事就是刪除日誌，這就致使日誌的丟失，萬一發生問題，對過後的追溯和取證帶來很大的困難。

• 企業中有不一樣崗位的人員，包括開發人員，運維人員，管理人員等等，每種人員對日誌的要求是不同的，開發人員更多的時候關注開發中遇到的異常日誌，運維人員關注的是系統的告警日誌，管理人員更多的是關注的業務日誌。面對這麼多的需求，現有的這種堆積木的方式很難知足。

    設計思想

        面對企業中這多問題的時候，咱們就在思考如何解決這些問題。對於軟件的使用，咱們提出了極簡原則，就是要讓產品儘可能的簡單，包括安裝簡單，配置簡單，使用簡單，最好都是傻瓜式的，簡單配置甚至不須要配置就可使用的，但功能還要必須強大的。因而咱們提出了兩個集中，四個統一的設計思想。

• 集中收集：集中收集個系統中時時產生的海量日誌；

• 集中存儲：集中存儲在一個可管理的分佈式系統中；

• 統一查詢：對各類日誌提供統一的查詢入口和規則；

• 統一分析：對收集上來的日誌進行統一的分析；

• 統一預警：對日誌進行時時關聯分析，統一進行預警；

• 統一展現：對全部日誌提供統一的展現方式。

    架構

    爲了支撐咱們的設計思想，咱們對技術選型作了大量的研究。

    開發語言的選擇，這塊沒有好壞之分，只是我從事了十幾年的java開發，比較熟悉，因此選擇java做爲開發的語言。其次是技術的框架的選擇，如今的產品開發不少時候不須要從頭開發，要站在巨人的肩膀上作事情。

    框架的選擇：java語言可選擇的框架比較多，目前在日誌領域最經常使用的流派有兩組，一個是elasticsearch +logstash +kibana簡稱elk，一個是flume+kafka+storm。這兩個選擇都有大量的用戶使用，也有各自的有點，在此不作過多的評價。但我我的認爲這兩種組合都有一個共同的缺點就是複雜，首先都是有幾個組件，每一個組件相對對立，經過不一樣的配置進行整合，須要通過屢次下載、配置、整合、測試、使用，根據我的能力不一樣，少則一兩天多多則一兩週才能把環境搭建好，但這僅僅是第一步，後面的學習、使用、維護、開發都須要花費大量的時間和精力。根據咱們自身的積累咱們最終只選擇了elasticsearch做爲咱們存儲和搜索的核心組件。對日誌採集分析和展現部分，咱們本身進行了開發。

    最終的架構是咱們本身的collect+elasticsearch+web，做爲咱們本身的主要技術架構組合，從最終的產品使用效果來看，咱們的產品對大多數有必定經驗的運維人員半個小時能夠把環境搭建好，並可使用。

    日誌處理過程，系統先通過不一樣的協議收集，而後都日誌進行格式化處理，接着是入庫，最後是對日誌進行關聯分析，產生告警。

    主要功能

• 日誌採集：系統可以支持多種協議進行日誌採集，系統內置Syslog server、SNMP Trap server、FTP server、SSH client、Sftp client、ftp client、Oracle client、Mysql client、web upload。這些全部的能力來源於java豐富的庫。

• 日誌的格式化：這一部分是產品的核心功能，既要簡單又要好用，因此抽象出了不少的維度，目前咱們抽象出來的維度高達五十多個維度。 對經常使用日誌格式的咱們作的大量的適配工做，目前支持經常使用的標準日誌，包括Linux、Windows、Ftp/Sftp、Nginx等中間件的標準日誌、IIS的日誌；咱們還經過插件支持性能採集、Sniffer Mysql、Sniffer Http協議，Inotify文件修改的審計。對這些日誌咱們都作了很好的匹配，作到了開箱即食的效果，因此你不用關注這些是怎麼實現的，極大的簡化了產品的使用。

• 日誌的分析：咱們對預警的模型做了不少的抽象，咱們能夠分析單條事件的行爲，多條事件的行爲，前後事件的行爲；咱們還即將支持基於統計的日誌分析和基於智能學習的日誌分析。經過這些大量的模型，咱們能夠很好的支持業務、運維和安全的關聯分析。再次咱們舉個例子來講明咱們關聯分析的效果。在作運維的都知道，cpu利用率是個很經常使用的指標，但這個指標比較敏感又和業務有必定的關係。那我如何來判斷cpu利用率太高呢，咱們但願的告警規則以下：在早上七點到九點之間，在連續的5分鐘內cpu利用率超過80%5次以上，在其餘時間，在連續的5分鐘內cpu利用率超過60%5次以上進行告警。這是一個很實用的告警規則，但據我所知，能完成這種告警的產品很少，主要集中在幾個大的siem品牌中，但他們的產品價格很高。

• 日誌存儲：咱們基於比較新版本的elasticsearch進行開發，在使用到的api中咱們基本上使用了最新的接口，這些接口在elasticsearch最新的2.1版本中繼續支持，杜絕了產品廢棄的接口，這些接口在官方的手冊中明確提出在2.X版本後將廢棄。這樣咱們的產品就很容易的升級到最新的版本中。

• 日誌搜索：因爲採用了elasticsearch，咱們對日誌搜索支持全文搜索，這些就像搜索引擎搜索同樣方便。同時只是不一樣維度的精準搜索，都經常使用搜索能夠保存起來進行下次的快速搜索。支持在搜索中直接查看IP的地區。對不一樣的維度能夠自定義在列表中是否顯示，極大的方便個性化的查看。

• 內置報表：系統內置經常使用的不少報表，包括WEB報表，防火牆報表，會話審計、登陸報表等，對這些報表都支持二級甚至三級鑽取功能，系統同時還支持自定義報表，基本知足大多數的需求。

    展望

    日誌分析產品咱們從15年4月份第一個版本上線到16年一月中旬，系統共升級了22個版本。極大的豐富了產品的內容，但因爲時間比較短，不少地方作的不夠精緻，因此16年會對產品的友好性，穩定性方面繼續增強。同時對產品的功能繼續增長，包括基線檢查、配置管理、單點登陸這些運維中經常使用的功能進行擴充。同時會增長智能分析學習的能力。這樣就更加增長產品統一管理的能力。