一、ELK簡介
ELK Stack是軟件集合Elasticsearch、Logstash、Kibana的簡稱，由這三個軟件及其相關的組件可以打造大規模日志實時處理系統。
Elasticsearch 是一個基於 Lucene 的、支持全文索引的分布式存儲和索引引擎，主要負責將日志索引並存儲起來，方便業務方檢索查詢。
Logstash是一個日志收集、過濾、轉發的中間件，主要負責將各條業務線的各類日志統一收集、過濾后，轉發給 Elasticsearch 進行下一步處理。
Kibana是一個可視化工具，主要負責查詢 Elasticsearch 的數據並以可視化的方式展現給業務方，比如各類餅圖、直方圖、區域圖等。
所謂“大規模”，指的是 ELK Stack 組成的系統以一種水平擴展的方式支持每天收集、過濾、索引和存儲TB規模以上的各類日志。通常，各類文本形式的日志都在處理范圍，包括但不限於 Web 訪問日志，如 Nginx/Apache Access Log 。
基於對日志的實時分析，可以隨時掌握服務的運行狀況、統計 PV/UV、發現異常流量、分析用戶行為、查看熱門站內搜索關鍵詞等。
二、ELK架構分析及應用場景
架構一：
首先由Logstash分布於各個節點上搜集相關日志、數據，並經過分析、過濾后發送給遠端服務器上的Elasticsearch進行存儲。Elasticsearch將數據以分片的形式壓縮存儲並提供多種API供用戶查詢，操作。用戶也可以更直觀的通過配置Kibana Web Portal方便的對日志查詢，並根據數據生成報表。
優點：搭建簡單，易於上手。
缺點：logstash消耗資源大，運行占用cpu和內存高，另外沒有消息隊列緩存，存在數據丟失隱患。
應用場景：適合小規模集群使用。
ELK架構介紹：http://blog.sina.com.cn/s/blog_87113ac20102wasl.html
架構二：
第二種架構引入了消息隊列機制，位於各個節點上的Logstash Agent先將數據/日志傳遞給Kafka（或者Redis），並將隊列中消息或數據間接傳遞給Logstash，Logstash過濾、分析后將數據傳遞給Elasticsearch存儲。最后由Kibana將日志和數據呈現給用戶。因為引入了Kafka（或者Redis）,所以即使遠端Logstash server因故障停止運行，數據將會先被存儲下來，從而避免數據丟失
優點：引入了消息隊列機制，均衡了網絡傳輸，從而降低了網絡閉塞尤其是丟失數據的可能性。
缺點：依然存在Logstash占用系統資源過多的問題。
應用場景：適合較大集群方案。
ELK架構介紹：http://blog.csdn.net/wenlixing110/article/details/56277603
架構三：
第三種架構引入了Logstash-forwarder。首先，Logstash-forwarder將日志數據搜集並統一發送給主節點上的Logstash，Logstash分析、過濾日志數據后發送至Elasticsearch存儲，並由Kibana最終將數據呈現給用戶。
優點：
1、解決了logstash占用系統資源較高的問題。
2、Logstash-forwarder和Logstash間的通信是通過SSL加密傳輸，起到了安全保障。
小結：如果是較大集群，用戶亦可以如結構三那樣配置logstash集群和Elasticsearch集群，引入High Available機制，提高數據傳輸和存儲安全。更主要的配置多個Elasticsearch服務，有助於搜索和數據存儲效率。
缺點：Logstash-forwarder和Logstash間通信必須由SSL加密傳輸，這樣便有了一定的限制性。
應用場景：適合較大集群。
架構四：
第四種架構將Logstash-forwarder替換為Beats。經測試，Beats滿負荷狀態所耗系統資源和Logstash-forwarder相當，但其擴展性和靈活性有很大提高。Beats platform目前包含有Packagebeat、Topbeat和Filebeat三個產品，均為Apache 2.0 License。同時用戶可根據需要進行二次開發。
這種架構原理基於第三種架構，但是更靈活，擴展性更強。同時可配置Logstash 和Elasticsearch 集群用於支持大集群系統的運維日志數據監控和查詢。
總結：不管采用上面哪種ELK架構，都包含了其核心組件，即：Logstash、Elasticsearch 和Kibana。當然這三個組件並非不能被替換，只是就性能和功能性而言，這三個組件已經配合的很完美，是密不可分的。在系統運維中究竟該采用哪種架構，可根據現實情況和架構優劣而定。
三、ELK功能模塊介紹
ELK組件各個功能模塊如下圖所示，它運行於分布式系統之上，通過搜集、過濾、傳輸、儲存，對海量系統和組件日志進行集中管理和准實時搜索、分析，使用搜索、監控、事件消息和報表等簡單易用的功能，幫助運維人員進行線上業務的准實時監控、業務異常時及時定位原因、排除故障、程序研發時跟蹤分析Bug、業務趨勢分析、安全與合規審計，深度挖掘日志的大數據價值。同時Elasticsearch提供多種API（REST JAVA PYTHON等API）供用戶擴展開發，以滿足其不同需求。
四、ELK在大數據運維中作用
1、日志查詢，問題排查，上線檢查。
2、服務器監控，應用監控，錯誤報警，bug管理。
3、性能分析，用戶行為分析，安全漏洞分析，時間管理。
小結：ELK組件在大數據運維中的應用是一套不可少的且方便、易用的開源解決方案。
http://blog.csdn.net/wenlixing110/article/details/56277603
- 前言
日志，對於任何系統來說都是及其重要的組成部分。在計算機系統里面，更是如此。但是由於現在的計算機系統大多比較復雜，很多系統都不是在一個地方，甚至都是跨國界的；即使是在一個地方的系統，也有不同的來源，比如，操作系統，應用服務，業務邏輯等等。他們都在不停產生各種各樣的日志數據。根據不完全統計，我們全球每天大約要產生2EB的數據。1EB=1024PB 1PB=1024TB
面對如此海量的數據，又是分布在各個不同地方，如果我們需要去查找一些重要的信息，難道還是使用傳統的方法，去登陸到一台台機器上查看？看來傳統的工具和方法已經顯得非常笨拙和低效了。於是，一些聰明人就提出了建立一套集中式的方法，把不同來源的數據集中整合到一個地方。
一個完整的集中式日志系統，是離不開以下幾個主要特點的:
- 收集－能夠采集多種來源的日志數據
- 傳輸－能夠穩定的把日志數據傳輸到中央系統
- 存儲－如何存儲日志數據
- 分析－可以支持 UI 分析
- 警告－能夠提供錯誤報告，監控機制
開源實時日志分析ELK平台能夠完美的解決我們上述的問題，ELK由ElasticSearch、Logstash和Kibana三個開源工具組成。
ElasticSearch：是個開源分布式搜索引擎，它的特點有：分布式，零配置，自動發現，索引自動分片，索引副本機制，restful風格接口，多數據源，自動搜索負載等。
Logstash： 是一個完全開源的工具，他可以對你的日志進行收集、分析，並將其存儲供以后使用。
Kibana：也是一個開源和免費的工具，Kibana可以為 Logstash
和 ElasticSearch 提供的日志分析友好的 Web 界面，可以幫助匯總、分析和搜索重要數據日志。
ELK 其實並不是一款軟件，而是一整套解決方案，是三個軟件產品的首字母縮寫，Elasticsearch，Logstash 和 Kibana。這三款軟件都是開源軟件，通常是配合使用，而且又先后歸於 Elastic.co 公司名下，故被簡稱為ELK協議棧。
在需要收集日志的所有服務上部署logstash，Logstash收集AppServer產生的Log，將日志收集在一起交給全文搜索服務ElasticSearch，而Kibana則從ES集群中查詢數據生成圖表，再返回給客戶端Browser。
3.1、什么是ElasticSearch ES
ElasticSearch是一個基於Lucene的搜索服務器。它提供了一個分布式多用戶能力的全文搜索引擎，基於RESTful web接口。Elasticsearch是用Java開發的，並作為Apache許可條款下的開放源碼發布，是當前流行的企業級搜索引擎。設計用於雲計算中，能夠達到實時搜索，穩定，可靠，快速，安裝使用方便。
Elasticsearch是一個實時分布式搜索和分析引擎。與數據庫對比來說：現在大部分數據庫在提取可用知識方面顯得異常無能。的確，它們能夠通過時間戳或者精確匹配做過濾查詢，但是它們不能夠進行全文搜索，不能處理同義詞，以及根據相關性給文檔打分。而Elasticsearch能根據同一份數據生成分析和聚合的結果，最重要的是，它們在沒有大量工作進程（線程）的情況下能做到對數據的實時處理。
3.2、ElasticSearch的主要應用場景
互聯網的時代，建立一個網站或應用程序，要添加搜索功能，實現站內搜索和站外搜索，但是想要完成搜索工作並保證運行的功能和性能是非常困難的。我們希望搜索解決方案要運行速度快，我們希望能有一個零配置和一個完全免費的搜索模式，我們希望能夠簡單地使用JSON通過HTTP來索引數據，我們希望我們的搜索服務器始終可用，我們希望能夠從一台開始並擴展到數百台應用，我們要實時搜索，我們要簡單的多租戶，我們希望建立一個雲的解決方案。因此我們利用Elasticsearch來解決所有這些問題以及可能出現的更多其它問題。
3.3、ElasticSearch的安裝部署入門
參考文檔
ELK官網：https://www.elastic.co/
ELK官網文檔：https://www.elastic.co/guide/index.html
ELK中文手冊：https://www.elastic.co/guide/cn/elasticsearch/guide/current/index.html
ELK中文社區：https://elasticsearch.cn/
ELK-API :https://www.elastic.co/guide/en/elasticsearch/client/java-api/current/transport-client.html
進入到es安裝目錄下的config文件夾中，修改elasticsearch.yml 文件
擴展：
YML文件格式是YAML (YAML Aint Markup Language)編寫的文件格式，YAML是一種直觀的能夠被電腦識別的的數據數據序列化格式，並且容易被人類閱讀，容易和腳本語言交互的。
它的基本語法規則如下。
# 表示注釋，從這個字符一直到行尾，都會被解析器忽略
|
修改的主要內容：
| #配置es的集群名稱，默認是elasticsearch，es會自動發現在同一網段下的es，如果在同一網段下有多個集群，就可以用這個屬性來區分不同的集群。 cluster.name: my-es #節點名稱 node.name: node1 #設置索引數據的存儲路徑 path.data: /export/servers/data #設置日志的存儲路徑 path.logs: /export/servers/logs #設置當前的ip地址,通過指定相同網段的其他節點會加入該集群中 network.host: 192.168.200.100 #設置對外服務的http端口 http.port: 9200 #設置集群中master節點的初始列表，可以通過這些節點來自動發現新加入集群的節點 discovery.zen.ping.unicast.hosts: ["node1"] |
3.4、解決啟動時報錯
(1)、在root用戶下啟動時報錯
因為安全問題elasticsearch 不讓用root用戶直接運行，所以要創建新用戶。
| 具體操作如下： useradd es -m passwd es chown -R es:es /export/servers/elasticsearch |
然后使用es用戶啟動
切換es用戶命令：su es
啟動集群命令：bin/elasticsearch
(2)、在es用戶下啟動時報錯
原因：Centos6不支持SecComp，而ES默認bootstrap.system_call_filter為true進行檢測，所以導致檢測失敗，失敗后直接導致ES不能啟動。
詳見 ：https://github.com/elastic/elasticsearch/issues/22899
解決方案：
在elasticsearch.yml中新增配置bootstrap.system_call_filter，設為false。
bootstrap.system_call_filter: false
(3)、在es用戶下啟動繼續報錯
第一個問題的原因：
| 原因：無法創建本地文件問題,用戶最大可創建文件數太小 解決方案：切換到root用戶，編輯limits.conf配置文件， 添加類似如下內容： vi /etc/security/limits.conf 添加如下內容: 注意*不要去掉了 * soft nofile 65536 * hard nofile 131072 備注：* 代表Linux所有用戶名稱（比如 hadoop） 需要保存、退出、重新登錄才可生效。 |
第二個錯誤的原因：
| 原因：無法創建本地線程問題,用戶最大可創建線程數太小 解決方案：切換到root用戶，進入limits.d目錄下，修改90-nproc.conf 配置文件。 vi /etc/security/limits.d/90-nproc.conf 找到如下內容： * soft nproc 1024 #修改為 * soft nproc 4096 |
第三個錯誤的原因：
| 原因：最大虛擬內存太小 每次啟動機器都手動執行下。 root用戶執行命令： 執行命令：sysctl -w vm.max_map_count=262144 查看修改結果命令：sysctl -a|grep vm.max_map_count 看是否已經修改
永久性修改策略： echo "vm.max_map_count=262144" >> /etc/sysctl.conf |
3.5、ES基礎概念
Elasticsearch有幾個核心概念。從一開始理解這些概念會對整個學習過程有莫大的幫助。
接近實時（NRT）
Elasticsearch是一個接近實時的搜索平台。這意味着，從索引一個文檔直到這個文檔能夠被搜索到有一個輕微的延遲（通常是1秒）。
集群（cluster）
一個集群就是由一個或多個節點組織在一起，它們共同持有你整個的數據，並一起提供索引和搜索功能。一個集群由一個唯一的名字標識，這個名字默認就是 “elasticsearch”。這個名字是重要的，因為一個節點只能通過指定某個集群的名字，來加入這個集群。在產品環境中顯式地設定這個名字是一個好習慣，但是使用默認值來進行測試/開發也是不錯的。
節點（node）
一個節點是你集群中的一個服務器，作為集群的一部分，它存儲你的數據，參與集群的索引和搜索功能。和集群類似，一個節點也是由一個名字來標識的，默認情況下，這個名字是一個隨機的漫威漫畫角色的名字，這個名字會在啟動的時候賦予節點。這個名字對於管理工作來說挺重要的，因為在這個管理過程中，你會去確定網絡中的哪些服務器對應於Elasticsearch集群中的哪些節點。
一個節點可以通過配置集群名稱的方式來加入一個指定的集群。默認情況下，每個節點都會被安排加入到一個叫做“elasticsearch”的集群中，這意味着，如果你在你的網絡中啟動了若干個節點，並假定它們能夠相互發現彼此，它們將會自動地形成並加入到一個叫做“elasticsearch”的集群中。
在一個集群里，只要你想，可以擁有任意多個節點。而且，如果當前你的網絡中沒有運行任何Elasticsearch節點，這時啟動一個節點，會默認創建並加入一個叫做“elasticsearch”的集群。
索引（index）
一個索引就是一個擁有幾分相似特征的文檔的集合。比如說，你可以有一個客戶數據的索引，另一個產品目錄的索引，還有一個訂單數據的索引。一個索引由一個名字來標識（必須全部是小寫字母的），並且當我們要對對應於這個索引中的文檔進行索引、搜索、更新和刪除的時候，都要使用到這個名字。在一個集群中，如果你想，可以定義任意多的索引。
類型（type）
在一個索引中，你可以定義一種或多種類型。一個類型是你的索引的一個邏輯上的分類/分區，其語義完全由你來定。通常，會為具有一組共同字段的文檔定義一個類型。比如說，我們假設你運營一個博客平台並且將你所有的數據存儲到一個索引中。在這個索引中，你可以為用戶數據定義一個類型，為博客數據定義另一個類型，當然，也可以為評論數據定義另一個類型。
文檔（document）
一個文檔是一個可被索引的基礎信息單元。比如，你可以擁有某一個客戶的文檔，某一個產品的一個文檔，當然，也可以擁有某個訂單的一個文檔。文檔以 JSON（Javascript Object Notation）格式來表示，而JSON是一個到處存在的互聯網數據交互格式。
在一個index/type里面，只要你想，你可以存儲任意多的文檔。注意，盡管一個文檔，物理上存在於一個索引之中，文檔必須被索引/賦予一個索引的type。
分片和復制（shards & replicas）
一個索引可以存儲超出單個結點硬件限制的大量數據。比如，一個具有10億文檔的索引占據1TB的磁盤空間，而任一節點都沒有這樣大的磁盤空間；或者單個節點處理搜索請求，響應太慢。
為了解決這個問題，Elasticsearch提供了將索引划分成多份的能力，這些份就叫做分片。當你創建一個索引的時候，你可以指定你想要的分片的數量。每個分片本身也是一個功能完善並且獨立的“索引”，這個“索引”可以被放置到集群中的任何節點上。
分片之所以重要，主要有兩方面的原因：
- 允許你水平分割/擴展你的內容容量
- 允許你在分片（潛在地，位於多個節點上）之上進行分布式的、並行的操作，進而提高性能/吞吐量
至於一個分片怎樣分布，它的文檔怎樣聚合回搜索請求，是完全由Elasticsearch管理的，對於作為用戶的你來說，這些都是透明的。
默認一個索引有5個分片，每個分片都1個副本。
3.6、訪問ES
在Google Chrome瀏覽器中，訪問以下地址：http://node1:9200?pretty
注意：在任意的查詢字符串中增加pretty參數，會讓Elasticsearch美化輸出(pretty-print)JSON響應以便更加容易閱讀。
4、Kibana 基礎入門
4.1 什么是kibana
Kibana 是一個開源的分析和可視化平台，旨在與 Elasticsearch 合作。Kibana 提供搜索、查看和與存儲在 Elasticsearch 索引中的數據進行交互的功能。開發者或運維人員可以輕松地執行高級數據分析，並在各種圖表、表格和地圖中可視化數據。
4.2 kibana安裝部署
下載安裝包
訪問elasticSearch官網地址 https://www.elastic.co/
進入到kibana安裝目錄下的config文件夾中，修改kibana.yml 文件
| server.host: "node1" elasticsearch.url: "http://node1:9200" chown -R es:es /export/servers/kibana |
后台運行：
nohup /export/servers/kibana/bin/kibana >/dev/null 2>&1 &
ps -ef|grep kibana 查看kibana進程
訪問kibana界面
具體操作可參照：
https://blog.csdn.net/ming_311/article/details/50619859
批量加載數據方式：
curl -XPOST 'http://node4:9200/bank/account/_bulk?pretty' --data-binary @accounts.json
添加參數：
url -XPOST 'node3:9200/bank100/account/_bulk?pretty' --data-binary @accounts.json -H 'Content-Type:application/json'
5、Logstash基礎入門
5.1 什么是Logstash
Logstash 是一個開源的數據收集引擎，它具有備實時數據傳輸能力。它可以統一過濾來自不同源的數據，並按照開發者的制定的規范輸出到目的地。
顧名思義，Logstash 收集數據對象就是日志文件。由於日志文件來源多（如：系統日志、服務器日志等），且內容雜亂，不便於人類進行觀察。因此，我們可以使用 Logstash 對日志文件進行收集和統一過濾，變成可讀性高的內容，方便開發者或運維人員觀察，從而有效的分析系統/項目運行的性能，做好監控和預警的准備工作等。
5.2 Logstash的組成結構
Logstash 通過管道進行運作，管道有兩個必需的元素，輸入（input）和輸出(output)，還有一個可選的元素-過濾器(filter)。輸入插件從數據源獲取數據，過濾器插件根據用戶指定的數據格式修改數據，輸出插件則將數據寫入到目的地。如下圖：
5.3 Logstash安裝部署
下載安裝包
訪問elasticSearch官網地址 https://www.elastic.co/
5.4 logstash入門案例
Logstash 提供了一個 shell 腳本叫 logstash 方便快速運行，-e意指執行
| bin/logstash -e 'input { stdin { } } output { stdout {} }' |
Hello World（輸入）經過 Logstash 管道（過濾）變成：
2018-03-16T13:14:19.342Z node2 Hello World （輸出）。
5.5 Logstash的插件介紹
在生產環境中，Logstash 的管道要復雜很多，可能需要配置多個輸入、過濾器和輸出插件。因此，需要一個配置文件管理輸入、過濾器和輸出相關的配置。配置文件內容格式如下：
| # 輸入 input { ... } # 過濾器 filter { ... } # 輸出 output { ... } |
根據自己的需求在對應的位置配置輸入插件、過濾器插件、輸出插件和編碼解碼插件即可。
在使用插件之前，我們先了解一個概念：事件。Logstash 每讀取一次數據的行為叫做事件。在 Logstach 目錄中創建一個配置文件，名為 logstash.conf（名字任意）。
5.5.1 輸入插件
輸入插件允許一個特定的事件源可以讀取到 Logstash 管道中，配置在 input {} 中，且可以設置多個。
修改配置文件：vi demo1.conf
| input { # 從文件讀取日志信息 file { # 文件路徑 path => "/root/access.log" start_position => "beginning" } } # filter { # # } output { # 標准輸出 stdout { codec => rubydebug } } |
執行：bin/logstash -f config/demo1.conf
Codec 是 logstash 從 1.3.0 版開始新引入的概念(Codec 來自 Coder/decoder 兩個單詞的首字母縮寫)。
在此之前，logstash 只支持純文本形式輸入，然后以過濾器處理它。
但現在，我們可以在輸入 期處理不同類型的數據，這全是因為有了 codec 設置。所以，這里需要糾正之前的一個概念。Logstash 不只是一個 input | filter | output 的數據流，而是一個 input | decode |filter | encode | output 的數據流！codec 就是用來 decode、encode 事件的。codec 的引入，使得 logstash 可以更好更方便的與其他有自定義數據格式的運維產品共存，。事實上，我們在第一個 "hello world" 用例中就已經用過 codec 了 —— rubydebug 就是一種 codec！雖然它一般只會用在stdout 插件中，作為配置測試或者調試的工具。
5.5.2 數據寫入到ES中
編寫配置文件：vi data2es.conf
| input { file { #指定類型 type => "game" #監控的文件路徑 path => "/root/log.json" #每隔多久去檢查一次被監聽的文件是否有新增的內容 discover_interval => 5 #start_position可以設置為beginning或者end，beginning表示從頭開始讀取文件，end表示讀取最新的 start_position => "beginning" } } output { #數據寫入到es中 elasticsearch { #定義數據寫入到es中的哪個索引中 index => "game-%{+YYYY.MM.dd}" #定義es集群地址 hosts => ["192.168.200.100:9200"] } }
|
執行：bin/logstash -f config/data2es.conf
5.5.3 數據寫入到kafka中
編寫配置文件data2kafka.conf
| input { file { #監控的文件路徑 path => "/root/access.log" #start_position可以設置為beginning或者end，beginning表示從頭開始讀取文件，end表示讀取最新的 start_position => "beginning" #sincedb_path表示文件讀取進度的記錄 sincedb_path => "/export/servers/logstash/config/index" } } output { kafka { #topic的名稱 topic_id => "accesslog" #kafka集群地址 bootstrap_servers => ["node1:9092,node2:9092,node3:9092"] } } |
執行：bin/logstash -f config/data2kafka.conf
5.5.4 讀取kafka中topic數據
(1) 啟動zookeeper kafka集群
(2) 創建主題:
kafka-topics.sh --zookeeper node1:2181 --create --topic hello --replication-factor 1 --partitions 3
- 執行生產者腳本:
kafka-console-producer.sh --broker-list node1:9092 --topic hello
執行消費者腳本，查看是否寫入:
kafka-console-consumer.sh --zookeeper node1:2181 --from-beginning --topic hello
- 編寫logstash配置文件 readDataFromKafka.conf
| input{ kafka { #codec的默認值為plain，表示一個空的解析器，codec可以讓用戶自己指定格式 codec => "plain" #消費者組id group_id => "logstash1" #消費者消費的策略 #earliest--從提交的offset開始消費；無提交的offset時，從頭開始消費 #latest--從提交的offset開始消費；無提交的offset時，消費新產生的該分區下的數據 auto_offset_reset => "earliest" #topic的名稱 topics => ["accesslog"] #kafka集群地址 bootstrap_servers => ["node1:9092,node2:9092,node3:9092"] }
} output{ stdout{ # 采用Ruby庫來解析日志,直接輸出在控制台 codec => rubydebug } } |
執行：bin/logstash -f config/readDataFromKafka.conf
5.5.5 數據寫入到HDFS上
編寫配置文件信息 vi data2hdfs.conf
| input { file{ #正則表達式匹配/root目錄下所有的以.log結尾的文件 path =>"/root/data/*.log" #多久檢查該目錄下是否有新的文件生成 discover_interval => 5 #Logstash開始讀取文件的位置：開頭或結尾 start_position => "beginning" #sincedb_path表示文件讀取進度的記錄 sincedb_path => "/export/servers/logstash/config/index" } } output { #指定數據保存在hdfs上 webhdfs { #namenode的所在的主機名 host => "node1" #hdfs web端口 port => 50070 #保存的路徑 path => "/logstash/dt=%{+YYYY-MM-dd}/logstash-%{+HH}.log" #用戶名 user => "root" } }
|
執行：bin/logstash -f config/data2hdfs.conf
其他豐富插件使用說明：
http://blog.csdn.net/iguyue/article/details/77006201