1.ELK是Elasticsearch、Logstash、Kibana的簡稱，這三者是核心套件，但並不是所有。後文的四種基本架構中將逐一介紹應用到的其它套件。
- Elasticsearch是實時全文搜索和分析引擎，提供蒐集、分析、存儲數據三大功能；是一套開放REST和JAVA API等結構提供高效搜索功能，可擴展的分佈式系統。它構建於Apache Lucene搜索引擎庫之上。
- Logstash是一個用來蒐集、分析、過濾日誌的工具。它支持幾乎任何類型的日誌，包括系統日誌、錯誤日誌和自定義應用程序日誌。它能夠從許多來源接收日誌，這些來源包括 syslog、消息傳遞（例如 RabbitMQ）和JMX，它可以以多種方式輸出數據，包括電子郵件、websockets和Elasticsearch。
- Kibana是一個基於Web的圖形界面，用於搜索、分析和可視化存儲在 Elasticsearch指標中的日誌數據。它利用Elasticsearch的REST接口來檢索數據，不只容許用戶建立他們本身的數據的定製儀表板視圖，
- 還容許他們以特殊的方式查詢和過濾數據。
2.這是最簡單的一種ELK架構方式。優勢是搭建簡單，易於上手。缺點是Logstash耗資源較大，運行佔用CPU和內存高。另外沒有消息隊列緩存，存在數據丟失隱患。建議供學習者和小規模集羣使用。
此架構首先由Logstash分佈於各個節點上搜集相關日誌、數據，並通過分析、過濾後發送給遠端服務器上的Elasticsearch進行存儲。Elasticsearch將數據以分片的形式壓縮存儲並提供多種API供用戶查詢，操做。用戶亦能夠更直觀的經過配置Kibana Web Portal方便的對日誌查詢，並根據數據生成報表
3.難點以及處理方法
一、ElasticSearch 分佈式集羣，在企業真實環境中防火牆須要關閉嗎？
在實際工做中，ElasticSearch集羣只開放對應的端口，不會直接關閉防火牆。
二、將公司的核心流量數據導入ELK平臺的過程當中，使用Logstash採集數據，那麼Logstash能承受多大的數據壓力呢？
一個logstash節點，每秒鐘能收集個一兩萬條日誌數據(普通的頁面瀏覽日誌)，若是單條日誌比較大，或者在logstash中filter邏輯複雜，處理能力會再小一點。另外須要補充說明：一條普通日誌大概6~8K的大小，轉換成流量的話大體是105000KB/S。
三、在ELK的項目中，公司的日誌如何動態產生？動態日誌又改如何採集？
若是日誌只輸出到一個文件，好比access.log，那麼Logstash直須要監控這個日誌文件便可。
若是日誌名稱按照時間或者大小滾動，那麼在Logstash配置文件名的時候使用通配符便可。
四、好比我天天的日誌有1g或者10g或者100g，ELK系統架構中，應該須要多少臺es，須要多少redis 須要多少logstash等。
能夠根據數據量的大小以及每一個組件數據處理能力合理規劃。
filebeat：每秒鐘收集能力大體在3W條左右
redis：每秒鐘讀取或者寫入數據能力在10W條左右
logstash：每秒鐘處理能力在1~2w左右
ELasticSearch：處理能力能夠很容易水平擴展，單臺服務器測試的指標大體在1.5W左右 配置：2核CPU、 16G內存
上述指標是指普通的access訪問日誌，每條日誌大小大體在6~8KB若是單條日誌過大或者太小，則指標會有上下浮動。
五、如今個人es集羣每次full gc以後, 年老代佔用的內存都會上升, 而後full gc會愈來愈頻繁. 基本5天以後集羣就得重啓了，有沒辦法不重啓強制清理年老代內存。
能夠經過參數進行配置，參數配置：
index.cache.field.max_size: 100000
index.cache.field.expire: 60m
index.cache.field.type: soft
若是發現這個效果不明顯，能夠嘗試修改一下JVM內存中年輕代和老年代的佔比，把年輕代的內存調大一點，這樣能夠減小年輕代GC的次數，就不會有不少數據進入到老年代中。
6.logstash正在給es發送數據，無任何外部操做狀況下，忽然es沒了~！：
(。因而翻看個人過往操做，沒有發現能夠致使相似結果的命令，es的日誌在當時的時間點下並無報告任何信息。後來想到了syslog的功能，因而查看syslog的日誌，在/var/log/messages（確認一下路徑）中按時間查找到es故障那會兒，找到了報錯故障。簡單說就是內存嚴重不足，linux系統前後殺死了個人兩個服務：mysqld和es。這兩個可都是後臺處理數據的呀，如此重要確也能被如此只能的OOM Killer機制選中並殺掉！