@聶奎甲 長春長信華天 項目經理：

要選擇開源的日志監(jiān)控軟件可以看下圖：

要選擇商業(yè)日志監(jiān)控軟件可以看一下日志易,、啟明和七牛的日志軟件等,。

通常傳統(tǒng)的解決方案如下：

第一，使用 grep 等腳本工具,。很大的問題是低效,、易出錯，更大的問題是不安全,。

第二,，使用 MySQL 匯聚數(shù)據。使用方便,，但是能力有限,。

第三，使用 NoSQL,。大問題是不支持交叉查詢與全文檢索,，使用負擔相對大。

第四,，使用 Hadoop / Spark / Storm,。使用起來比較繁雜，不支持全文檢索,。

第五,，使用 ELK。產品層面做的比較不足,，超大數(shù)據量下穩(wěn)定性存在挑戰(zhàn),。

商業(yè)軟件可以更好的解決上面這些軟件的不足，使運維工作更簡單一些,。

@nansingnansing AiB 系統(tǒng)架構師：

廠商：國內可以參考日志易（優(yōu)特捷）,，國外的splunk。

自研或一般廠商,，目前比較多的是基于ELK做平臺封裝,，增加kfk、權限管理,、spl查詢,、監(jiān)控設置等可維護性、可管理的功能,。其他方案上一位已經回答的比較全了,。

以下經驗主要基于ELK平臺，使用的有日志易產品,，也有自研平臺,。

選型上，要評估自身的日志量和投入成本,，低量級對廠商產品沒有什么大的依賴,，高量級就會涉及到es的調優(yōu)能力和部署架構。

另一個會影響性能的,，就是解析規(guī)則,，大量的解析規(guī)則會導致性能消耗加劇，入庫慢會導致監(jiān)控失真,。

其他可參考的,，配置簡易性、支持解析規(guī)則的設置能力,、SPL支持能力,、報表可視化、歷史數(shù)據歸檔策略等,。

1,、可由運維人員自定義關鍵字

——日志平臺的監(jiān)控，一般條件都是周期性范圍內出現(xiàn)關鍵字的次數(shù),，例如5分鐘內出現(xiàn)ERROR數(shù)10次,。基本上產品都是支持的

——為了支持更復雜的監(jiān)控,，一般會對一些字段做提取,，比如通過正則表達式，提取出一些業(yè)務字段,，可以做加減乘除,、<>=等二次加工的條件 

2、能適應不規(guī)則新生成的日志文件

——對于日志文件,，可以對目錄進行動態(tài)發(fā)現(xiàn),；但一般還是配置具體文件路徑的比較多,，例如/log/abc.YYYYMMDD，但也可以監(jiān)控/log目錄下的所有新日志

——對于日志內容,，至少要設置換行條件,，例如起始字符或結束/n，設置起始字符,，可以將exception的輸出合并在一條日志里,，但對日志規(guī)范有些要求

@anonym 某銀行 運維工程師：

ELK 或 EFK 都是不錯的技術選型，目前在國內很多廠家都落地了各種 ES 的架構方案,，開源生態(tài)也穩(wěn)定發(fā)展,，各項配套組件都能很容易對接。

在主流的現(xiàn)有選型中,，關系型數(shù)據庫因為索引壓力和對全文檢索的支持薄弱,，不因該作為考慮，即便是使用高性能的緩存或者消息隊列沒有性價比可言,。NoSQL 數(shù)據庫也沒有先天的對日志的存儲優(yōu)勢,，雖然寬松的范式限制能夠靈活地處理信息文檔，現(xiàn)在大部分日志是 JSON 形式可以輸入至 MongoDB 等,，但是在日志場景的使用案例還是不夠,。ES 能夠使用倒排索引、分片,、復制等完全契合日志及文本處理需求,，很容易成為選型過程中的首選。

日志的存儲可以對接流計算等外部模塊,，能將日志的價值榨取充分,。

@顧黃亮 蘇寧消費金融有限公司 技術總監(jiān)：

對題主的問題進行分解，對日志關鍵字的監(jiān)控與告警,。1.可由運維人員自定義關鍵字2.能適應不規(guī)則新生成的日志文件,。

1、自定義關鍵字,，應該是日志中出現(xiàn)某個關鍵字進行告警,，或者不出現(xiàn)某個關鍵字進行告警，其中包括String類型與Number類型

2,、 適應不規(guī)則新生成的日志文件,，適配所有日志文件，對日志具備初步清洗的功能

目前開源監(jiān)控中較為常見的是ZABBIX或ELK（也可是EFK）

zabbix完全可以實現(xiàn)題主的需求,，主要通過匹配關鍵字實現(xiàn)告警,，舉個例子，新建項目,， 選擇類型為zabbix客戶端（主動式）,，鍵值為 xx_log.log 為日志的絕對路徑 ,，connectException 為關鍵字 ，此處的關鍵字需根據自己需要定義,，如下列配置：

DIA3222E日志 log[{#DB2LOGDIR},DIA3222E,,100,skip,] 　 主機{HOST.NAME}{#DB2LOGDIR}日志產生DIA3222E信息 nodata(5m)=0

這種監(jiān)控方式較為機械,，不夠靈活，如類型的轉換,，上下文關聯(lián)不能夠實現(xiàn),，收到告警后需要人工介入進行二次分析,，優(yōu)點是配置簡單,，技術掌握較為單一，且侵入性較小,。

elk在監(jiān)控能力方面較為全面,，logstash的grok語法 可以直接使用或應用預定義的表達式名稱，并支持把預定義的 grok 表達式 寫入到文件中,，同樣滿足題主的需求,，相比zabbix來說，更容易實現(xiàn)對關鍵字進行抓取和搜索,，并可以對關鍵字的類型進行轉化和計算,。

二者都可以 適配所有日志文件，不同的是,，elk可以對日志進行預清洗,，而zabbix不可以。

還有一種思路可以提供參考,，可以通過 logstash-output-zabbix插件,，讓logstash來對日志進行初步的清洗來達到日志的標準化，同樣可以對關鍵字在某種特殊場景下的類型轉換和二次計算來讓監(jiān)控指標更加合理,， 通過這個插件將Logstash與zabbix進行整合,，也就是將Logstash收集到的數(shù)據進行過濾，將有錯誤標識的日志輸出到zabbix中,，最后通過zabbix的告警機制進行觸發(fā),、告警，這種方式將zabbix和logstash的優(yōu)點進行整合,，在技術棧在可控范圍內進行收窄的同時,，更靈活的進行關鍵字的配置和告警，同時zabbix還可以實現(xiàn)告警后的處理,，如重啟應用,、執(zhí)行腳本來達到初步的自愈功能。

@Zabbix大叔_樂維  研發(fā)工程師：

前面已經有人分析的很好了,，日志易經過深度優(yōu)化形成了自己的搜索引擎,，其他兩家基于elk為底層做的上層應用,，sp是集大成者，基于日志在運維和安全都做的很好,，缺點就是外企大廠的通病,，易用性差。在日志運維這塊國內日志易做的比較好,，其次是七牛,，樂維也有日志監(jiān)控。安全這塊,，傳統(tǒng)的安全廠商日志產品都是基于滿足審計需求的盒子,，真正做了一點場景的是瀚思，但是被360收了,。

針對ES日志監(jiān)控，ES本身在X-pack中有集成的工具包,，但是收費的,。故開源免費的ElastAlert是比較好的替代品。

Elastalert的定義：

ElastAlert是一個用Python編寫的框架,，用于實時監(jiān)控ES中數(shù)據中的異常,，極值或其他感興趣的模式。它結合了兩種類型的組件：規(guī)則類型和警報,。

ElastAlert定時輪詢ES,，并將查詢數(shù)據傳遞到規(guī)則類型。規(guī)則類型定義了匹配的時間和觸發(fā)告警的條件,。此過程由一組規(guī)則配置,，其中每個規(guī)則限定了一個查詢，一個規(guī)則類型和一組警報,。

官網介紹了一些Elastalert的特性：

--可靠性：ElastAlert依靠ES將自身狀態(tài)的信息回寫到約定的索引上,。這樣可以事后回顧和調試ElastAlert的操作，并避免在ElastAlert重新啟動或崩潰時丟失數(shù)據,。一旦崩潰,，ElastAlert也能靠持久化下來的信息，恢復到先前處理的位置,。

--高度模塊化：ElastAlert的主要組件是規(guī)則類型和警報,。它們可以作為模塊導入或定制。

--易于配置：只需設置全局配置文件和一組規(guī)則,，即可輕松設置和配置ElastAlert,。

值得一提的是，如果采用docker部署ElastAlert，可以通過K8S來彌補ElastAlert目前不能做到高可用HA的缺點,，同時,，Github上也能下載插件，與kibana進行集成,，實現(xiàn)頁面對規(guī)則的管理,。