㈠ elk如何做到端到端100%完全傳輸日誌在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服務進行採集到的日誌索引操作。
,