elk日志分析與挖掘深入分析
- 1 為什么要做日志采集？
- 2 挖財自己的日志采集和分析體系應該怎么建？
- 2.1 日志的采集
- 2.2 日志的匯總與過濾
- 2.3 日志的存儲
- 2.4 日志的分析與查詢
- 3 需要解決哪些技術問題？
- 3.1 logstash與kafka的對接
- 3.2 kafka到elastic search的數據鏈路對接
- 3.2.1 參考
- 3.3 日志報警功能與zabbix的集成
- 4 補充和小結
1 為什么要做日志采集？
日志， 對於不同團隊來說會有不同的使用目的：
- 對於數據倉庫團隊來說， 日志是他們要分析的信息數據來源之一；
- 對於安全團隊來說， 日志是他們構建安全防御與漏洞挖掘的一種特征來源和觸發信號源；
- 對於應用團隊來說， 日志是他們了解自己的系統運行狀態與排除錯誤的一種手段；
- etc.
在服務結點不多的情況下， 各個團隊怎么使用這些日志或許可以百花齊放，但在中大規模服務部署的情況下， 日志類別 * 技術方案 * 對接的系統等等這些因素的組合將極大加重系統研發和維護的負擔，所以， 我們需要一套分布式環境下集中采集，分析和管理日志的技術體系。
最原始的登錄服務器查看日志等操作，對於信息安全要求需要逐步加強的互聯網金融企業來講， 最終一定是要杜絕的，權限收縮並規范化管理我們將逐漸執行落地， 屆時， 所有的日志查看，分析等工作將只能通過我們的日志平台進行。
2 挖財自己的日志采集和分析體系應該怎么建？
一套日志的管理體系通常需要處理以下幾個階段的工作：
- 日志的采集
- 日志的匯總與過濾
- 日志的存儲
- 日志的分析與查詢
ELK技術棧(即Logstash + ElasticSearch + Kibana)屬於業界已經應用比較廣泛且成熟的開源方案，這套一站式解決方案基本上可以滿足大部分企業對日志管理體系的需求，但對於我們挖財來講， 需要更多的靈活性以處理遺留系統以及現有技術基礎設施的復用， 故此， 我們自己的日志管理技術體系我希望是如下的樣子：
2.1 日志的采集
靈活性是我們選擇日志采集方案更看重的因素，所以logstash屬於首先方案， 它可以兼顧多種不同系統和應用類型等因素的差異，從源頭上進行一些初步的日志預處理。
logstash唯一的小缺憾是它的不輕便， 因為它是使用jruby開發並跑在java虛擬機上的agent， 當然啦，同時也是優點，即各種平台上都可以用。
2.2 日志的匯總與過濾
kafka在我們挖財已經屬於核心的中間件服務， 所以， 日志的匯總自然而然會傾向於使用kafka。
日志的過濾和處理因為需求的多樣性，可以直接對接訂閱kafka， 然后根據各自的需求進行日志的定制處理， 比如過濾和監控應用日志的異常，即使通過zabbix進行預警； 或者數據倉庫方面在原始日志的基礎上進行清洗和轉換，然后加載到新的數據源中；
2.3 日志的存儲
原始的日志存儲我們采用ElasticSearch， 即ELK技術棧中E的原本用途，遵循ELK技術棧中各個方案之間的通用規范， 比如日志如索引采用logstash與kibana之間約定的index pattern。
日志的衍生數據則日志使用各方根據需求自行選擇。
2.4 日志的分析與查詢
ELK技術棧中的Kibana已經可以很好的滿足這一需求，這里我們不折騰。
3 需要解決哪些技術問題？
因為我們在ELK技術棧的處理鏈路上插入了一些擴展點，所以，有些問題需要解決和澄清...
3.1 logstash與kafka的對接
ELK技術棧中， Logstash和Elastic Search是通過logstash的elasticsearch或者elasticsearch_http這幾個output直接對接的， 為了讓logstash轉而對接kafka，我們有幾種選擇：
- logstash-kafka
- logstash-output-kafka
- logstash的
httpoutput
第一種和第二種方案都需要編譯打包相應的依賴到logstash，然后隨同logstash一起部署到服務結點， 雖然可以work， 但依賴重， 資源消耗多， 通用性不強；
個人更傾向於第三種方案，即使用logstash默認提供的http這個output， 因為http比較通用， 而且本身我們的kafka前面就有為了多系統對接而提供的http proxy方案部署。另外，依賴的管理和升級都在服務端維護，對每個服務結點是透明的。 當然， 唯一的弱點是效率可能不如基於長連接的消息傳遞高，只是暫時不是問題，即使將來成為瓶頸，也可以通過sharding的形式進行擴展。
3.2 kafka到elastic search的數據鏈路對接
kafka和es之間我們要加入一套日志過濾與處理系統， 這套系統是我們發揮整個體系最大威力的地方。 在整個系統的處理pipeline中，我們可以根據需求添加任意需要的Filter/Processor, 比如服務於應用報警的Filter/Processor，服務於數據倉庫ETL的Filter/Processor等等。 但不管前面做了多少事情， 日志最終是要接入到ES進行存儲的。
因為ELK技術棧中三者的對接遵循一些規范或者說規則， 而我們又需要繼續復用這個技術棧中的服務提供的特定功能， 所以，即使是我們在整個處理鏈路中插入了擴展點，但數據的存儲依然需要遵循ELK原來的規范和規則， 以便Kibana可以從ES中撈日志出來分析和展示的時候不需要任何改動。
logstash存入ES的日志，一般遵循如下的index pattern：
logstash-%{+YYYY.MM.dd}
使用日期進行索引（index）界定的好處是， 可以按照日期范圍定期進行清理。
NOTE
進一步深入說明一下， 針對不同的日志類別， index pattern也最好分類對應。
更多信息:
Each log line from the input file is associated with a logstash event. Each logstash event has fields associated with it. By default, "message", "@timestamp", "@version", "host", "path" are created. The "message" field, referenced in the conditional statement, contains all the original text of the log line.
日志處理系統可以使用ES的java客戶端或者直接通過ES的HTTP服務進行采集到的日志索引操作。
3.2.1 參考
- http://www.rsyslog.com/output-to-elasticsearch-in-logstash-format-kibana-friendly/
- https://sematext.atlassian.net/wiki/display/PUBLOGSENE/Index+Events+via+Elasticsearch+API
- http://stackoverflow.com/questions/27127326/is-logstash-a-mandatory-prefix-of-indices-in-kibana
3.3 日志報警功能與zabbix的集成
我們的監控平台選擇了使用zabbix， 所以各個系統如果有監控需求，最好都對接zabbix， 避免維護多套不必要的運維系統。
在應用日志處理過程中， 我們希望可以識別錯誤或者異常信號， 然后通過zabbix報警和通知相應devops人員， 為了達到這一目的，我們可以復用zabbix中的action/user/usergroup等實體配置， 並且配置相應的虛擬host/item/trigger等實體，然后由日志處理系統在需要的時候，直接通過active的方式上報數據， 具體操作方式為：
- 在日志處理系統中， 通過zabbix_sender或者根據zabbix_sender的通信協議，在合適的時機發送狀態數據；
- 在zabbix中， 配置相應的host/item/trigger， item為zabbix trapper類型，key與zabbix_sender發送的key相對應；
- 其它配置根據需要配套即可（找zabbix管理者提需求即可 - @多寶）。
TIPS
zabbix_sender協議參考https://www.zabbix.org/wiki/Docs/protocols/zabbix_sender/2.0
4 補充和小結
雖然我在架構圖中從具體的服務器結點通過虛線的形式引入了一條直接到ElasticSearch和Kibana的鏈路，但並不推薦這種方案， 原因可能是（但不限於）:
- 本身我們的日志管理體系中對日志的處理/過濾需求是不可避免的， 所以， 日志的存儲入庫可以通過一條鏈路直接完成， 只維護一套規范即可；
- 在每個結點開兩個口子， 本身會對網絡IO造成雙倍壓力；
所以， 以上架構規范中所有推薦的做法是綜合考慮后最完善的方案。