作為中國最大的在線教育站點,目前滬江日志服務的用戶包含網(wǎng)校,交易,金融,CCTalk 等多個部門的多個產(chǎn)品的日志搜索分析業(yè)務,每日產(chǎn)生的各類日志有好十幾種,每天處理約10億條(1TB)日志,熱數(shù)據(jù)保留最近7天數(shù)據(jù),冷數(shù)據(jù)永久保存。
成都創(chuàng)新互聯(lián)服務項目包括召陵網(wǎng)站建設、召陵網(wǎng)站制作、召陵網(wǎng)頁制作以及召陵網(wǎng)絡營銷策劃等。多年來,我們專注于互聯(lián)網(wǎng)行業(yè),利用自身積累的技術優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關系等,向廣大中小型企業(yè)、政府機構等提供互聯(lián)網(wǎng)行業(yè)的解決方案,召陵網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前,我們服務的客戶以成都為中心已經(jīng)輻射到召陵省份的部分城市,未來相信會繼續(xù)擴大服務區(qū)域并繼續(xù)獲得客戶的支持與信任!
首先,什么是日志? 日志就是程序產(chǎn)生的,遵循一定格式(通常包含時間戳)的文本數(shù)據(jù)
通常日志由服務器生成,輸出到不同的文件中,一般會有系統(tǒng)日志、 應用日志、安全日志。這些日志分散地存儲在不同的機器上。
通常當系統(tǒng)發(fā)生故障時,工程師需要登錄到各個服務器上,使用 grep / sed / awk 等 Linux 腳本工具去日志里查找故障原因。在沒有日志系統(tǒng)的情況下,首先需要定位處理請求的服務器,如果這臺服務器部署了多個實例,則需要去每個應用實例的日志目錄下去找日志文件。每個應用實例還會設置日志滾動策略(如:每天生成一個文件),還有日志壓縮歸檔策略等。
這樣一系列流程下來,對于我們排查故障以及及時找到故障原因,造成了比較大的麻煩。因此,如果我們能把這些日志集中管理,并提供集中檢索功能,不僅可以提高診斷的效率,同時對系統(tǒng)情況有個全面的理解,避免事后救火的被動。
我認為,日志數(shù)據(jù)在以下幾方面具有非常重要的作用:
針對這些問題,為了提供分布式的實時日志搜集和分析的監(jiān)控系統(tǒng),我們采用了業(yè)界通用的日志數(shù)據(jù)管理解決方案 - 它主要包括 Elasticsearch 、 Logstash 和 Kibana 三個系統(tǒng)。通常,業(yè)界把這套方案簡稱為ELK,取三個系統(tǒng)的首字母,但是我們實踐之后將其進一步優(yōu)化為EFK,F(xiàn)代表Filebeat,用以解決Logstash導致的問題。下面,我們展開詳細介紹。
文中涉及的 ELK stack 版本是:
Elasticsearch 5.2.2
Logstash 5.2.2
Kibana 5.2.2
Filebeat 5.2.2
Kafka 2.10
Logstash:數(shù)據(jù)收集處理引擎。支持動態(tài)的從各種數(shù)據(jù)源搜集數(shù)據(jù),并對數(shù)據(jù)進行過濾、分析、豐富、統(tǒng)一格式等操作,然后存儲以供后續(xù)使用。
Kibana:可視化化平臺。它能夠搜索、展示存儲在 Elasticsearch 中索引數(shù)據(jù)。使用它可以很方便的用圖表、表格、地圖展示和分析數(shù)據(jù)。
Elasticsearch:分布式搜索引擎。具有高可伸縮、高可靠、易管理等特點。可以用于全文檢索、結構化檢索和分析,并能將這三者結合起來。Elasticsearch 基于 Lucene 開發(fā),現(xiàn)在使用最廣的開源搜索引擎之一,Wikipedia 、StackOverflow、Github 等都基于它來構建自己的搜索引擎。
Filebeat:輕量級數(shù)據(jù)收集引擎?;谠?Logstash-fowarder 的源碼改造出來。換句話說:Filebeat就是新版的 Logstash-fowarder,也會是 ELK Stack 在 shipper 端的第一選擇。
既然要談 ELK 在滬江系統(tǒng)中的應用,那么 ELK 架構就不得不談。本次分享主要列舉我們曾經(jīng)用過的 ELK 架構,并討論各種架構所適合的場景和優(yōu)劣供大家參考
這種架構下我們把 Logstash 實例與 Elasticsearch 實例直接相連。Logstash 實例直接通過 Input 插件讀取數(shù)據(jù)源數(shù)據(jù)(比如 Java 日志, Nginx 日志等),經(jīng)過 Filter 插件進行過濾日志,最后通過 Output 插件將數(shù)據(jù)寫入到 ElasticSearch 實例中。
這個階段,日志的收集、過濾、輸出等功能,主要由這三個核心組件組成 Input 、Filter、Output
Input:輸入,輸入數(shù)據(jù)可以是 File 、 Stdin(直接從控制臺輸入) 、TCP、Syslog 、redis 、Collectd 等
Filter:過濾,將日志輸出成我們想要的格式。Logstash 存在豐富的過濾插件:Grok 正則捕獲、時間處理、JSON 編解碼、數(shù)據(jù)修改 Mutate 。Grok 是 Logstash 中最重要的插件,強烈建議每個人都要使用 Grok Debugger 來調試自己的 Grok 表達式
grok {
match => ["message", "(?m)\[%{LOGLEVEL:level}\] \[%{TIMESTAMP_ISO8601:timestamp}\] \[%{DATA:logger}\] \[%{DATA:threadId}\] \[%{DATA:requestId}\] %{GREEDYDATA:msgRawData}"]
}
Output:輸出,輸出目標可以是 Stdout (直接從控制臺輸出)、Elasticsearch 、Redis 、TCP 、File 等
這是最簡單的一種ELK架構方式,Logstash 實例直接與 Elasticsearch 實例連接。優(yōu)點是搭建簡單,易于上手。建議供初學者學習與參考,不能用于線上的環(huán)境。
這種架構下我們采用多個 Elasticsearch 節(jié)點組成 Elasticsearch 集群,由于 Logstash 與 Elasticsearch 采用集群模式運行,集群模式可以避免單實例壓力過重的問題,同時在線上各個服務器上部署 Logstash Agent,來滿足數(shù)據(jù)量不大且可靠性不強的場景。
數(shù)據(jù)收集端:每臺服務器上面部署 Logstash Shipper Agent 來收集當前服務器上日志,日志經(jīng)過 Logstash Shipper 中 Input插件、Filter插件、Output 插件傳輸?shù)?Elasticsearch 集群
數(shù)據(jù)存儲與搜索:Elasticsearch 配置默認即可滿足,同時我們看數(shù)據(jù)重要性來決定是否添加副本,如果需要的話,最多一個副本即可
數(shù)據(jù)展示:Kibana 可以根據(jù) Elasticsearch 的數(shù)據(jù)來做各種各樣的圖表來直觀的展示業(yè)務實時狀況
這種架構使用場景非常有限,主要存在以下兩個問題
這個架構相對上個版本略微復雜,不過維護起來同樣比較方便,同時可以滿足數(shù)據(jù)量不大且可靠性不強的業(yè)務使用。
該場景下面,多個數(shù)據(jù)首先通過 Lostash Shipper Agent 來收集數(shù)據(jù),然后經(jīng)過 Output 插件將數(shù)據(jù)投遞到 Kafka 集群中,這樣當遇到 Logstash 接收數(shù)據(jù)的能力超過 Elasticsearch 集群處理能力的時候,就可以通過隊列就能起到削峰填谷的作用, Elasticsearch 集群就不存在丟失數(shù)據(jù)的問題。
目前業(yè)界在日志服務場景中,使用比較多的兩種消息隊列為 :Kafka VS Redis。盡管 ELK Stack 官網(wǎng)建議使用 Redis 來做消息隊列,但是我們建議采用 Kafka 。主要從下面兩個方面考慮:
綜合上述的理由,我們決定采用 Kafka 來緩沖隊列。不過在這種架構下仍然存在一系列問題
這種架構適合較大集群的應用部署,通過消息隊列解決了消息丟失、網(wǎng)絡堵塞的問題。
隨著滬江業(yè)務的飛速增長,單機房的架構已經(jīng)不能滿足需求。不可避免的,滬江的業(yè)務需要分布到不同機房中,對于日志服務來說也是不小的挑戰(zhàn)。當然業(yè)界也有不少成熟的方法,比如阿里的單元化、騰訊的 SET 方案等等。單元化在這邊不詳細展開,大家可以參考微博的【單元化架構】
最終我們決定采用單元化部署的方式來解決 ELK 多機房中遇到的問題(延時、專線流量過大等),從日志的產(chǎn)生、收集、傳輸、存儲、展示都是在同機房里面閉環(huán)消化,不存在跨機房傳輸與調用的問題。因為交互緊密的應用盡量部署在同機房,所以這種方案并不會給業(yè)務查詢造成困擾。
Logstash、Elasticsearch、Kafka、Kibana 四個集群都部署到同一機房中,每個機房都要每個機房自己的日志服務集群,比如A機房業(yè)務的日志只能傳輸給本機房 Kafka ,而A機房 Indexer 集群消費并寫入到A機房 Elasticsearch 集群中,并由A機房 Kibana 集群展示,中間任何一個步驟不依賴B機房任何服務。
Filebeat 是基于原先 logstash-forwarder 的源碼改造出來的,無需依賴 Java 環(huán)境就能運行,安裝包10M不到。
如果日志的量很大,Logstash 會遇到資源占用高的問題,為解決這個問題,我們引入了Filebeat。Filebeat 是基于 logstash-forwarder 的源碼改造而成,用 Golang 編寫,無需依賴 Java 環(huán)境,效率高,占用內存和 CPU 比較少,非常適合作為 Agent 跑在服務器上。
下面看看Filebeat的基本用法。編寫配置文件,從 Nginx access.log 中解析日志數(shù)據(jù)
# filebeat.yml
filebeat.prospectors:
- input_type: log
paths: /var/log/nginx/access.log
json.message_key:
output.elasticsearch:
hosts: ["localhost"]
index: "filebeat-nginx-%{+yyyy.MM.dd}"
我們來看看壓測數(shù)據(jù)
Logstash / Filebeat 讀取 350W 條日志 到 console,單行數(shù)據(jù) 580B,8個進程寫入采集文件
項目 | workers | cpu usr | 總共耗時 | 收集速度 |
---|---|---|---|---|
Logstash | 8 | 53.7% | 210s | 1.6w line/s |
Filebeat | 8 | 38.0% | 30s | 11w line/s |
Filebeat 所消耗的CPU只有 Logstash 的70%,但收集速度為 Logstash 的7倍。從我們的應用實踐來看,F(xiàn)ilebeat 確實用較低的成本和穩(wěn)定的服務質量,解決了 Logstash 的資源消耗問題。
最后,分享給大家一些血淚教訓,希望大家以我為鑒。
突然有一天監(jiān)控發(fā)現(xiàn)日志不消費了,排查下來發(fā)現(xiàn)消費Kafka數(shù)據(jù)的indexer 掛掉了。所以,Indexer 進程也是需要用 supervisor 來監(jiān)控的,保證它時刻都在運行。
開始我們在通過 grok 切割日志的時候,發(fā)現(xiàn)Java 的 Exception 日志輸出之后,會出現(xiàn)換行的問題。后來使用 Logstash codec/multiline插件來解決。
input {
stdin {
codec => multiline {
pattern => "^\["
negate => true
what => "previous"
}
}
}
Logstash 2.3版本 date插件配置如下,查看解析結果發(fā)現(xiàn)@timestamp比中國時間早了8小時。
解決方案 Kibana 讀取瀏覽器的當前時區(qū),然后在頁面上轉換時間內容的顯示。
date {
match => [ "log_timestamp", "YYYY-MM-dd HH:mm:ss.SSS" ]
target => "@timestamp"
}
我們遇到線上node日志突然有幾天日志查看不出來。后來拉出原始日志對比才發(fā)現(xiàn)生成出來的日志格式不正確,同時包含 JSON 格式和非 JSON格式的日志。但是我們用grok解析的時候采用是json格式。建議大家輸出日志保證格式一致同時不要出現(xiàn)空格等異常字符,可以使用在線grok debug (http://grokdebug.herokuapp.com/) 來調試正則。
基于 ELK stack 的日志解決方案的優(yōu)勢主要體現(xiàn)于
文章名稱:從ELK到EFK演進
文章源于:http://bm7419.com/article36/pscspg.html
成都網(wǎng)站建設公司_創(chuàng)新互聯(lián),為您提供靜態(tài)網(wǎng)站、ChatGPT、定制網(wǎng)站、云服務器、、外貿網(wǎng)站建設
聲明:本網(wǎng)站發(fā)布的內容(圖片、視頻和文字)以用戶投稿、用戶轉載內容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內容未經(jīng)允許不得轉載,或轉載時需注明來源: 創(chuàng)新互聯(lián)