日志聚合和可視化

標(biāo)簽(空格分隔): 架構(gòu) 日志 聚合


一逾冬、背景需求&常見方案

1褂始、日志分類和作用

image.png
image.png

2慎菲、傳統(tǒng)日志管理方案&存在的問題

image.png

現(xiàn)代日志管理和分析解決方案包括以下主要功能:

  • 聚合 - 從多個(gè)數(shù)據(jù)源收集和發(fā)送日志的能力迟郎。
  • 處理 - 將日志消息轉(zhuǎn)換為有意義的數(shù)據(jù)以便于分析的能力齿坷。
  • 存儲(chǔ) - 能夠在延長的時(shí)間段內(nèi)存儲(chǔ)數(shù)據(jù)辫狼,以便進(jìn)行監(jiān)控初斑,趨勢(shì)分析和安全用例。
  • 分析 - 通過查詢數(shù)據(jù)并在其上創(chuàng)建可視化和儀表板來分析數(shù)據(jù)的能力膨处。

3见秤、常用日志聚合方案

  1. Elastic Stack(ELK)

????ELK,即 Elasticsearch真椿、Logstash 和 Kibana 簡(jiǎn)稱鹃答,是最流行的開源日志聚合工具。它被 Netflix突硝、Facebook挣跋、微軟、LinkedIn 和思科使用狞换。這三個(gè)組件都是由 Elastic 開發(fā)和維護(hù)的避咆。Elasticsearch 本質(zhì)上是一個(gè) NoSQL 數(shù)據(jù)庫,以 Lucene 搜索引擎實(shí)現(xiàn)的修噪。Logstash 是一個(gè)日志管道系統(tǒng)查库,可以接收數(shù)據(jù),轉(zhuǎn)換數(shù)據(jù)黄琼,并將其加載到像 Elasticsearch 這樣的應(yīng)用中樊销。Kibana 是 Elasticsearch 之上的可視化層。

????幾年前脏款,引入了 Beats 围苫。Beats 是數(shù)據(jù)采集器。它們簡(jiǎn)化了將數(shù)據(jù)運(yùn)送到 Logstash 的過程撤师。用戶不需要了解每種日志的正確語法剂府,而是可以安裝一個(gè) Beats 來正確導(dǎo)出 NGINX 日志或 Envoy 代理日志,以便在 Elasticsearch 中有效地使用它們剃盾。

  1. Graylog

????Graylog 最近越來越受歡迎腺占,但它是在 2010 年由 Lennart Koopmann 創(chuàng)建并開發(fā)的淤袜。兩年后,一家公司以同樣的名字誕生了衰伯。盡管它的使用者越來越多铡羡,但仍然遠(yuǎn)遠(yuǎn)落后于 ELK 套件。這也意味著它具有較少的社區(qū)開發(fā)特征意鲸,但是它可以使用與 ELK 套件相同的 Beats 烦周。由于 Graylog Collector Sidecar 使用 Go 編寫,所以 Graylog 在 Go 社區(qū)贏得了贊譽(yù)怎顾。

????Graylog 使用 Elasticsearch论矾、MongoDB 和底層的 Graylog Server 。這使得它像 ELK 套件一樣復(fù)雜杆勇,也許還要復(fù)雜一些。然而饱亿,Graylog 附帶了內(nèi)置于開源版本中的報(bào)警功能蚜退,以及其他一些值得注意的功能,如流彪笼、消息重寫和地理定位钻注。

  1. Fluentd

????FluentdTreasure Data 開發(fā)的,CNCF 已經(jīng)將它作為一個(gè)孵化項(xiàng)目配猫。它是用 C 和 Ruby 編寫的幅恋,并被 AWSGoogle Cloud 所推薦。Fluentd 已經(jīng)成為許多系統(tǒng)中 logstach 的常用替代品泵肄。它可以作為一個(gè)本地聚合器捆交,收集所有節(jié)點(diǎn)日志并將其發(fā)送到中央存儲(chǔ)系統(tǒng)。它不是日志聚合系統(tǒng)腐巢。

image.png
  1. 阿里云日志服務(wù)(云計(jì)算)


    image.png

4品追、日志采集工具對(duì)比

Logstash

Logstash 不是這個(gè)列表里最老的傳輸工具(最老的應(yīng)該是 syslog-ng ,諷刺的是它也是唯一一個(gè)名字里帶有 new 的)冯丙,但 Logstash 絕對(duì)可以稱得上最有名的肉瓦。因?yàn)樗泻芏嗖寮狠斎搿⒕幗獯a器胃惜、過濾器以及輸出泞莉。基本上船殉,可以獲取并豐富任何數(shù)據(jù)鲫趁,然后將它們推送到多種目標(biāo)存儲(chǔ)。

  • 優(yōu)勢(shì)

Logstash 主要的有點(diǎn)就是它的靈活性利虫,這還主要因?yàn)樗泻芏嗖寮H缓笏宄奈臋n已經(jīng)直白的配置格式讓它可以再多種場(chǎng)景下應(yīng)用孝扛。這樣的良性循環(huán)讓我們可以在網(wǎng)上找到很多資源,幾乎可以處理任何問題幽崩。

  • 劣勢(shì)

Logstash 致命的問題是它的性能以及資源消耗(默認(rèn)的堆大小是 1GB)苦始。盡管它的性能在近幾年已經(jīng)有很大提升,與它的替代者們相比還是要慢很多的慌申。這里有 Logstash 與 rsyslog 性能對(duì)比以及Logstash 與 filebeat 的性能對(duì)比陌选。它在大數(shù)據(jù)量的情況下會(huì)是個(gè)問題。

另一個(gè)問題是它目前不支持緩存蹄溉,目前的典型替代方案是將 Redis 或 Kafka 作為中心緩沖池咨油。

  • 典型應(yīng)用場(chǎng)景

因?yàn)?Logstash 自身的靈活性以及網(wǎng)絡(luò)上豐富的資料,Logstash 適用于原型驗(yàn)證階段使用柒爵,或者解析非常的復(fù)雜的時(shí)候役电。在不考慮服務(wù)器資源的情況下,如果服務(wù)器的性能足夠好棉胀,我們也可以為每臺(tái)服務(wù)器安裝 Logstash 法瑟。我們也不需要使用緩沖,因?yàn)槲募陨砭陀芯彌_的行為唁奢,而 Logstash 也會(huì)記住上次處理的位置霎挟。

如果服務(wù)器性能較差,并不推薦為每個(gè)服務(wù)器安裝 Logstash 麻掸,這樣就需要一個(gè)輕量的日志傳輸工具酥夭,將數(shù)據(jù)從服務(wù)器端經(jīng)由一個(gè)或多個(gè) Logstash 中心服務(wù)器傳輸?shù)?Elasticsearch。

隨著日志項(xiàng)目的推進(jìn)脊奋,可能會(huì)因?yàn)樾阅芑虼鷥r(jià)的問題熬北,需要調(diào)整日志傳輸?shù)姆绞剑╨og shipper)。當(dāng)判斷 Logstash 的性能是否足夠好時(shí)诚隙,重要的是對(duì)吞吐量的需求有著準(zhǔn)確的估計(jì)蒜埋,這也決定了需要為 Logstash 投入多少硬件資源。

Filebeat

作為 Beats 家族的一員最楷,F(xiàn)ilebeat 是一個(gè)輕量級(jí)的日志傳輸工具整份,它的存在正彌補(bǔ)了 Logstash 的缺點(diǎn):Filebeat 作為一個(gè)輕量級(jí)的日志傳輸工具可以將日志推送到中心 Logstash。

在版本 5.x 中籽孙,Elasticsearch 具有解析的能力(像 Logstash 過濾器)— Ingest烈评。這也就意味著可以將數(shù)據(jù)直接用 Filebeat 推送到 Elasticsearch,并讓 Elasticsearch 既做解析的事情犯建,又做存儲(chǔ)的事情讲冠。也不需要使用緩沖,因?yàn)?Filebeat 也會(huì)和 Logstash 一樣記住上次讀取的偏移:

如果需要緩沖(例如适瓦,不希望將日志服務(wù)器的文件系統(tǒng)填滿)竿开,可以使用 Redis/Kafka谱仪,因?yàn)?Filebeat 可以與它們進(jìn)行通信:

  • 優(yōu)勢(shì)

Filebeat 只是一個(gè)二進(jìn)制文件沒有任何依賴。它占用資源極少否彩,盡管它還十分年輕疯攒,正式因?yàn)樗?jiǎn)單,所以幾乎沒有什么可以出錯(cuò)的地方列荔,所以它的可靠性還是很高的敬尺。它也為我們提供了很多可以調(diào)節(jié)的點(diǎn),例如:它以何種方式搜索新的文件贴浙,以及當(dāng)文件有一段時(shí)間沒有發(fā)生變化時(shí)砂吞,何時(shí)選擇關(guān)閉文件句柄。

  • 劣勢(shì)

Filebeat 的應(yīng)用范圍十分有限崎溃,所以在某些場(chǎng)景下我們會(huì)碰到問題蜻直。例如,如果使用 Logstash 作為下游管道袁串,我們同樣會(huì)遇到性能問題概而。正因?yàn)槿绱耍現(xiàn)ilebeat 的范圍在擴(kuò)大般婆。開始時(shí),它只能將日志發(fā)送到 Logstash 和 Elasticsearch朵逝,而現(xiàn)在它可以將日志發(fā)送給 Kafka 和 Redis蔚袍,在 5.x 版本中,它還具備過濾的能力配名。

  • 典型應(yīng)用場(chǎng)景

Filebeat 在解決某些特定的問題時(shí):日志存于文件啤咽,我們希望將日志直接傳輸存儲(chǔ)到 Elasticsearch。這僅在我們只是抓去(grep)它們或者日志是存于 JSON 格式(Filebeat 可以解析 JSON)渠脉∮钫或者如果打算使用 Elasticsearch 的 Ingest 功能對(duì)日志進(jìn)行解析和豐富。

將日志發(fā)送到 Kafka/Redis芋膘。所以另外一個(gè)傳輸工具(例如鳞青,Logstash 或自定義的 Kafka 消費(fèi)者)可以進(jìn)一步豐富和轉(zhuǎn)發(fā)。這里假設(shè)選擇的下游傳輸工具能夠滿足我們對(duì)功能和性能的要求为朋。

Fluentd

Fluentd 創(chuàng)建的初衷主要是盡可能的使用 JSON 作為日志輸出臂拓,所以傳輸工具及其下游的傳輸線不需要猜測(cè)子字符串里面各個(gè)字段的類型。這樣习寸,它為幾乎所有的語言都提供庫胶惰,這也意味著,我們可以將它插入到我們自定義的程序中霞溪。

  • 優(yōu)勢(shì)

和多數(shù) Logstash 插件一樣孵滞,F(xiàn)luentd 插件是用 Ruby 語言開發(fā)的非常易于編寫維護(hù)中捆。所以它數(shù)量很多,幾乎所有的源和目標(biāo)存儲(chǔ)都有插件(各個(gè)插件的成熟度也不太一樣)坊饶。這也意味這我們可以用 Fluentd 來串聯(lián)所有的東西泄伪。

  • 劣勢(shì)

因?yàn)樵诙鄶?shù)應(yīng)用場(chǎng)景下,我們會(huì)通過 Fluentd 得到結(jié)構(gòu)化的數(shù)據(jù)幼东,它的靈活性并不好臂容。但是我們?nèi)匀豢梢酝ㄟ^正則表達(dá)式,來解析非結(jié)構(gòu)化的數(shù)據(jù)根蟹。盡管脓杉,性能在大多數(shù)場(chǎng)景下都很好,但它并不是最好的简逮,和 syslog-ng 一樣球散,它的緩沖只存在與輸出端,單線程核心以及 Ruby GIL 實(shí)現(xiàn)的插件意味著它大的節(jié)點(diǎn)下性能是受限的散庶,不過蕉堰,它的資源消耗在大多數(shù)場(chǎng)景下是可以接受的。對(duì)于小的或者嵌入式的設(shè)備悲龟,可能需要看看 Fluent Bit屋讶,它和 Fluentd 的關(guān)系與 Filebeat 和 Logstash 之間的關(guān)系類似

  • 典型應(yīng)用場(chǎng)景

Fluentd 在日志的數(shù)據(jù)源和目標(biāo)存儲(chǔ)各種各樣時(shí)非常合適,因?yàn)樗泻芏嗖寮虢獭6颐笊绻蠖鄶?shù)數(shù)據(jù)源都是自定義的應(yīng)用,所以可以發(fā)現(xiàn)用 fluentd 的庫要比將日志庫與其他傳輸工具結(jié)合起來要容易很多轻腺。特別是在我們的應(yīng)用是多種語言編寫的時(shí)候乐疆,即我們使用了多種日志庫,日志的行為也不太一樣贬养。

Logagent

Logagent 是 Sematext 提供的傳輸工具挤土,它用來將日志傳輸?shù)?Logsene(一個(gè)基于 SaaS 平臺(tái)的 Elasticsearch API),因?yàn)?Logsene 會(huì)暴露 Elasticsearch API误算,所以 Logagent 可以很容易將數(shù)據(jù)推送到 Elasticsearch 仰美。

  • 優(yōu)勢(shì)

可以獲取 /var/log 下的所有信息,解析各種格式(Elasticsearch儿礼,Solr筒占,MongoDB,Apache HTTPD等等)蜘犁,它可以掩蓋敏感的數(shù)據(jù)信息翰苫,例如,個(gè)人驗(yàn)證信息(PII),出生年月日奏窑,信用卡號(hào)碼导披,等等。它還可以基于 IP 做 GeoIP 豐富地理位置信息(例如埃唯,access logs)漠趁。同樣甥绿,它輕量又快速图谷,可以將其置入任何日志塊中隅茎。在新的 2.0 版本中绸硕,它以第三方 node.js 模塊化方式增加了支持對(duì)輸入輸出的處理插件咬崔。重要的是 Logagent 有本地緩沖兜蠕,所以不像 Logstash 便监,在數(shù)據(jù)傳輸目的地不可用時(shí)會(huì)丟失日志。

  • 劣勢(shì)

盡管 Logagent 有些比較有意思的功能(例如沼头,接收 Heroku 或 CloudFoundry 日志)进倍,但是它并沒有 Logstash 靈活

  • 典型應(yīng)用場(chǎng)景

Logagent 作為一個(gè)可以做所有事情的傳輸工具是值得選擇的(提取猾昆、解析、緩沖和傳輸)。

logtail

阿里云日志服務(wù)的生產(chǎn)者档悠,目前在阿里集團(tuán)內(nèi)部機(jī)器上運(yùn)行,經(jīng)過3年多時(shí)間的考驗(yàn)望浩,目前為阿里公有云用戶提供日志收集服務(wù)辖所。

采用C++語言實(shí)現(xiàn),對(duì)穩(wěn)定性磨德、資源控制缘回、管理等下過很大的功夫,性能良好。相比于logstash酥宴、fluentd的社區(qū)支持揩环,logtail功能較為單一,專注日志收集功能幅虑。

  • 優(yōu)勢(shì)

logtail占用機(jī)器cpu丰滑、內(nèi)存資源最少,結(jié)合阿里云日志服務(wù)的E2E體驗(yàn)良好倒庵。

  • 劣勢(shì)

logtail目前對(duì)特定日志類型解析的支持較弱褒墨,后續(xù)需要把這一塊補(bǔ)起來。

rsyslog

絕大多數(shù) Linux 發(fā)布版本默認(rèn)的 syslog 守護(hù)進(jìn)程擎宝,rsyslog 可以做的不僅僅是將日志從 syslog socket 讀取并寫入 /var/log/messages 郁妈。它可以提取文件、解析绍申、緩沖(磁盤和內(nèi)存)以及將它們傳輸?shù)蕉鄠€(gè)目的地噩咪,包括 Elasticsearch 〖模可以從此處找到如何處理 Apache 以及系統(tǒng)日志胃碾。

  • 優(yōu)勢(shì)

rsyslog 是經(jīng)測(cè)試過的最快的傳輸工具。如果只是將它作為一個(gè)簡(jiǎn)單的 router/shipper 使用筋搏,幾乎所有的機(jī)器都會(huì)受帶寬的限制仆百,但是它非常擅長處理解析多個(gè)規(guī)則。它基于語法的模塊(mmnormalize)無論規(guī)則數(shù)目如何增加奔脐,它的處理速度始終是線性增長的俄周。這也就意味著,如果當(dāng)規(guī)則在 20-30 條時(shí)髓迎,如解析 Cisco 日志時(shí)峦朗,它的性能可以大大超過基于正則式解析的 grok ,達(dá)到 100 倍(當(dāng)然排龄,這也取決于 grok 的實(shí)現(xiàn)以及 liblognorm 的版本)波势。

它同時(shí)也是我們能找到的最輕的解析器,當(dāng)然這也取決于我們配置的緩沖涣雕。

  • 劣勢(shì)

rsyslog 的配置工作需要更大的代價(jià)(這里有一些例子)艰亮,這讓兩件事情非常困難:

文檔難以搜索和閱讀闭翩,特別是那些對(duì)術(shù)語比較陌生的開發(fā)者挣郭。

5.x 以上的版本格式不太一樣(它擴(kuò)展了 syslogd 的配置格式,同時(shí)也仍然支持舊的格式)疗韵,盡管新的格式可以兼容舊格式兑障,但是新的特性(例如,Elasticsearch 的輸出)只在新的配置下才有效,然后舊的插件(例如流译,Postgres 輸出)只在舊格式下支持逞怨。

盡管在配置穩(wěn)定的情況下,rsyslog 是可靠的(它自身也提供多種配置方式福澡,最終都可以獲得相同的結(jié)果)叠赦,它還是存在一些 bug 。

  • 典型應(yīng)用場(chǎng)景

rsyslog 適合那些非常輕的應(yīng)用(應(yīng)用革砸,小VM除秀,Docker容器)。如果需要在另一個(gè)傳輸工具(例如算利,Logstash)中進(jìn)行處理册踩,可以直接通過 TCP 轉(zhuǎn)發(fā) JSON ,或者連接 Kafka/Redis 緩沖效拭。

rsyslog 還適合我們對(duì)性能有著非常嚴(yán)格的要求時(shí)暂吉,特別是在有多個(gè)解析規(guī)則時(shí)。那么這就值得為之投入更多的時(shí)間研究它的配置缎患。

syslog-ng

可以將 syslog-ng 當(dāng)作 rsyslog 的替代品(盡管歷史上它們是兩種不同的方式)慕的。它也是一個(gè)模塊化的 syslog 守護(hù)進(jìn)程,但是它可以做的事情要比 syslog 多挤渔。它可以接收磁盤緩沖并將 Elasticsearch HTTP 作為輸出业稼。它使用 PatternDB 作為語法解析的基礎(chǔ),作為 Elasticsearch 的傳輸工具蚂蕴,它是一個(gè)不錯(cuò)的選擇低散。

  • 優(yōu)勢(shì)

和 rsyslog 一樣,作為一個(gè)輕量級(jí)的傳輸工具骡楼,它的性能也非常好熔号。它曾經(jīng)比 rsyslog 慢很多,但是 2 年前能達(dá)到 570K Logs/s 的性能并不差鸟整。并不像 rsyslog 引镊,它有著明確一致的配置格式以及完好的文檔。

  • 劣勢(shì)

Linux 發(fā)布版本轉(zhuǎn)向使用 rsyslog 的原因是 syslog-ng 高級(jí)版曾經(jīng)有很多功能在開源版中都存在篮条,但是后來又有所限制弟头。我們這里只關(guān)注與開源版本,所有的日志傳輸工具都是開源的∩婕耄現(xiàn)在又有所變化赴恨,例如磁盤緩沖,曾經(jīng)是高級(jí)版存在的特性伴栓,現(xiàn)在開源版也有伦连。但有些特性雨饺,例如帶有應(yīng)用層的通知的可靠傳輸協(xié)議(reliable delivery protocol)還沒有在開源版本中。

  • 典型應(yīng)用場(chǎng)景

和 rsyslog 類似惑淳,可能將 syslog-ng 部署在資源受限的環(huán)境中额港,但仍希望它能在處理復(fù)雜計(jì)算時(shí)有著良好的性能。如果使用 rsyslog 歧焦,它可以輸出至 Kafka 移斩,以 Kafka 作為一個(gè)中心隊(duì)列,并以 Logstash 作為一個(gè)自定義消費(fèi)者绢馍。

不同的是叹哭,syslog-ng 使用起來比 rsyslog 更容易,性能沒有 rsyslog 那么極致:例如痕貌,它只對(duì)輸出進(jìn)行緩沖风罩,所以它所有的計(jì)算處理在緩沖之前就完成了,這也意味著它會(huì)給日志流帶來壓力舵稠。

二超升、Elastic Stack

1、產(chǎn)品架構(gòu)&介紹

1.1 傳統(tǒng)ELK

直到一兩年前哺徊,ELK Stack是三個(gè)開源產(chǎn)品的集合 - Elasticsearch室琢, LogstashKibana全部由Elastic開發(fā),管理和維護(hù)落追。

下載 (1).png

Logstash在JVM上運(yùn)行并消耗大量資源來執(zhí)行此操作盈滴。關(guān)于Logstash顯著的內(nèi)存消耗,許多討論都在浮動(dòng)轿钠。顯然巢钓,當(dāng)您想要從小型機(jī)器(例如AWS微實(shí)例)發(fā)送日志而不損害應(yīng)用程序性能時(shí),這可能是一個(gè)巨大的挑戰(zhàn)疗垛。

1.2 從ELK到BELK(Elastic Stack)

最新版本的Logstash和ELk Stack已經(jīng)改善了這種固有的弱點(diǎn)症汹。使用Filebeat和/或Elasticsearch Ingest Node,可以將一些處理外包給堆棧中的其他組件贷腕。您還可以使用監(jiān)視API來識(shí)別瓶頸和有問題的處理背镇。

Logstash的Java執(zhí)行引擎(在版本6.3中公布為試驗(yàn)版)默認(rèn)在版本7.x中啟用。它取代了舊的Ruby執(zhí)行引擎泽裳,擁有更好的性能瞒斩,更少的內(nèi)存使用和整體 - 更快的體驗(yàn)。

Beats的引入和后續(xù)添加將堆棧變成了一個(gè)四腳的項(xiàng)目涮总,并導(dǎo)致堆棧重命名為Elastic Stack胸囱。

下載.png
image.png

其它參考:Elastic發(fā)展歷程

1.3 Elastic Stack生態(tài)

image.png
Jietu20190602-112754.jpg

訂閱 · Elastic Stack 產(chǎn)品和支持 | Elastic

2、部署Elastic Stack最簡(jiǎn)方案

Beats平臺(tái)設(shè)置最簡(jiǎn)單的架構(gòu)包括一個(gè)或多個(gè)Beats妹卿,Elasticsearch和Kibana旺矾。這種架構(gòu)易于入門,足以滿足低流量網(wǎng)絡(luò)的需求夺克。它還使用最少量的服務(wù)器:運(yùn)行Elasticsearch和Kibana的單臺(tái)機(jī)器箕宙。Beats將事務(wù)直接插入Elasticsearch實(shí)例。

但是铺纽,如果要對(duì)數(shù)據(jù)執(zhí)行其他處理或緩沖柬帕,則需要安裝Logstash。

image.png

本節(jié)介紹部署Elastic Stack最簡(jiǎn)方案:Filebeat+Elasticsearch+Kibana方案狡门,示例使用Filebeat收集應(yīng)用日志文件陷寝,通過Elasticsearch的pipeline進(jìn)行字段攝取再進(jìn)行存儲(chǔ),最后使用Kibana進(jìn)行可視化查詢其馏。

應(yīng)用日志內(nèi)容示例凤跑,它存在單行的日志,也存在包含堆棧的多行日志:

[2019-05-30 15:25:23.609] [logging_demo] [pool-2-thread-2] INFO  ylz.test.TimerTaskFactory - 這是一個(gè)info log, tick: 1559201123609
[2019-05-30 15:25:23.609] [logging_demo] [pool-2-thread-4] ERROR ylz.test.TimerTaskFactory - 運(yùn)行時(shí)異常:
java.lang.Exception: 這是一個(gè)error log, tick: 1559201123609
    at ylz.test.TimerTaskFactory$2.run(TimerTaskFactory.java:28)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
    at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)

2.1 安裝&啟動(dòng)Elasticsearch

下載安裝包:https://www.elastic.co/cn/downloads/elasticsearch

命令行啟動(dòng):

linux & Mac:
./bin/elasticsearch

守護(hù)進(jìn)程啟動(dòng)&關(guān)閉:

./bin/elasticsearch -d -p pid
pkill -F pid

訪問端口(默認(rèn)):http://localhost:9200/

2.2 安裝&啟動(dòng)Kibana

下載安裝包:https://www.elastic.co/cn/downloads/kibana

命令行啟動(dòng):

> linux & Mac:
./bin/kibana

> windows:
.\bin\kibana.bat

訪問端口(默認(rèn)):http://localhost:5601

2.3 安裝&啟動(dòng)FileBeat

下載安裝包:https://www.elastic.co/downloads/beats/filebeat

配置./filebeat.yml:

filebeat.inputs:
- type: log
  enabled: true
  paths:
    ### 此處配置需要收集的日志路徑
    - /Users/ivan/Projects/logging_demo/logs/*.log
output.elasticsearch:
  hosts: ["127.0.0.1:9200"]

啟動(dòng)filebeat:

> linux:
./filebeat -e

啟動(dòng)完畢后叛复,可在Kibana中看到的結(jié)果:

image.png

2.4 Kibana操作介紹

Kibana幾個(gè)常用菜單:

image.png
  • Managemnt

Management
The Management application is where you perform your runtime configuration of Kibana, including both the initial setup and ongoing configuration of index patterns, advanced settings that tweak the behaviors of Kibana itself, and the various "objects" that you can save throughout Kibana such as searches, visualizations, and dashboards.

Management是您執(zhí)行Kibana的運(yùn)行時(shí)配置的地方仔引,包括索引模式的初始設(shè)置和持續(xù)配置,調(diào)整Kibana本身行為的高級(jí)設(shè)置褐奥,以及您可以在整個(gè)Kibana中保存的各種“對(duì)象”咖耘,例如搜索,可視化和儀表板撬码。

????使用Beats或LogStash采集數(shù)據(jù)到Elasticsearch后儿倒,可在Index Management中看到指定名稱的Index:

image.png

Kibana使用Index Pattern從ElasticSearch索引中檢索諸如可視化之類的數(shù)據(jù),因此在使用Discover前呜笑,需要先創(chuàng)建Create index pattern:

image.png
  • Discover

Discover
Discover enables you to explore your data with Kibana’s data discovery functions. You have access to every document in every index that matches the selected index pattern. You can submit search queries, filter the search results, and view document data. You can also see the number of documents that match the search query and get field value statistics. If a time field is configured for the selected index pattern, the distribution of documents over time is displayed in a histogram at the top of the page.

Discover使您可以使用Kibana的數(shù)據(jù)發(fā)現(xiàn)功能探索數(shù)據(jù)夫否。您可以訪問與所選索引模式匹配的每個(gè)索引中的每個(gè)文檔。您可以提交搜索查詢叫胁,過濾搜索結(jié)果以及查看文檔數(shù)據(jù)慷吊。您還可以查看與搜索查詢匹配的文檔數(shù)量并獲取字段值統(tǒng)計(jì)信息。如果為所選索引模式配置了時(shí)間字段曹抬,則文檔隨時(shí)間的分布將顯示在頁面頂部的直方圖中溉瓶。

KQL查詢語法

查詢數(shù)據(jù)時(shí),可以使用KQL(Kibana Query Language)查詢語法谤民,它支持全文搜索堰酿、關(guān)系運(yùn)算等功能,搜索結(jié)果中關(guān)鍵字也會(huì)高亮顯示:

image.png
  • Dev Tools

Console使您可以與Elasticsearch的REST API進(jìn)行交互张足。

image.png

在數(shù)據(jù)處理管道中使用之前触创,您可以在Kibana Grok Debugger中構(gòu)建和調(diào)試grok模式。

image.png
  • Visualize

Visualize使您可以在Elasticsearch索引中創(chuàng)建數(shù)據(jù)的可視化为牍。然后哼绑,您可以構(gòu)建顯示相關(guān)可視化的Dashboard岩馍。

  • Dashboard

Kibana Dashboard顯示Visualize和搜索的集合。

  • Monitoring

Monitoring功能提供了一種有效方法抖韩,讓您能夠密切關(guān)注 Elasticsearch、Kibana、Beats 和 Logstash 的運(yùn)行狀況和性能顽馋。它的儀表板集合能夠幫助您在各個(gè)層級(jí)上評(píng)估儀表板的狀態(tài)属桦,同時(shí)為您提供所有必要的信息亏吝,讓您始終最大限度地發(fā)揮 Elastic Stack 的作用馆类。
借助強(qiáng)大的 Alerting 功能沟于,自動(dòng)獲知集群中的任何更改——所有 Elasticsearch存崖、Kibana 和 Logstash 中的集群狀態(tài)贞瞒、授權(quán)過期情況或其他監(jiān)測(cè)指標(biāo)掰盘。
Monitoring 主要特性免費(fèi)提供撒遣。Alerting功能為非基礎(chǔ)許可證所有功能。

3征椒、進(jìn)階

目前方案下在Kibana中查看到的日志存在如下問題:

  1. 包含堆棧的多行日志被按行記錄為多筆日志
  2. 日志內(nèi)容全部記錄在單個(gè)message字段上勃黍,沒有按日志內(nèi)容的含義提取到不同的字段進(jìn)行存儲(chǔ)覆获,不利于查詢

3.1 管理多行消息

Manage multiline messages
The files harvested by Filebeat may contain messages that span multiple lines of text. For example, multiline messages are common in files that contain Java stack traces. In order to correctly handle these multiline events, you need to configure multiline settings in the filebeat.yml file to specify which lines are part of a single event.

由filebeat收集的文件可能包含跨多行文本的消息缨称。例如,多行消息在包含Java堆棧跟蹤的文件中是常見的四啰。為了正確處理這些多行事件欧瘪,需要在filebeat.yml文件中配置多行設(shè)置,以指定哪些行是單個(gè)事件的一部分匙赞。

filebeat.ymlfilebeat.inputs配置節(jié)下添加如下配置:

filebeat.inputs:
  ...
  ### Multiline options
  multiline.pattern: ^\[
  multiline.negate: true
  multiline.match: after

3.2 使用Ingest Node解析數(shù)據(jù)

Parse data by using ingest node
When you use Elasticsearch for output, you can configure Filebeat to use ingest node to pre-process documents before the actual indexing takes place in Elasticsearch. Ingest node is a convenient processing option when you want to do some extra processing on your data, but you do not require the full power of Logstash. For example, you can create an ingest node pipeline in Elasticsearch that consists of one processor that removes a field in a document followed by another processor that renames a field.

使用Elasticsearch進(jìn)行輸出時(shí)佛掖,可以將Filebeat配置為使用 攝取節(jié)點(diǎn)在Elasticsearch中進(jìn)行實(shí)際索引之前預(yù)處理文檔。當(dāng)您想對(duì)數(shù)據(jù)進(jìn)行一些額外處理時(shí)涌庭,攝取節(jié)點(diǎn)是一個(gè)方便的處理選項(xiàng)芥被,但您不需要Logstash的全部功能。例如坐榆,您可以在Elasticsearch中創(chuàng)建一個(gè)攝取節(jié)點(diǎn)管道拴魄,該管道由一個(gè)處理器組成,該處理器刪除文檔中的字段,然后是另一個(gè)重命名字段的處理器匹中。

ingest node
Use an ingest node to pre-process documents before the actual document indexing happens. The ingest node intercepts bulk and index requests, it applies transformations, and it then passes the documents back to the index or bulk APIs.

使用攝取節(jié)點(diǎn)在實(shí)際文檔索引發(fā)生之前預(yù)處理文檔夏漱。攝取節(jié)點(diǎn)攔截批量和索引請(qǐng)求,應(yīng)用轉(zhuǎn)換顶捷,然后將文檔傳遞回索引或批量API挂绰。

image.png

要在索引前預(yù)處理文檔,請(qǐng)定義指定一系列處理器的管道服赎。每個(gè)處理器都以某種特定的方式轉(zhuǎn)換文檔葵蒂。

image.png

新增一個(gè)json文件,如app-log-pipeline.json

{
  "description" : "app-log-pipeline",
  "processors" : [
    {
      ### 從文檔中的單個(gè)文本字段message中提取結(jié)構(gòu)化字段
      "grok" : {
        "field" : "message",
        "patterns" :["\\[%{TIMESTAMP_ISO8601:timestamp}\\] \\[%{WORD:topic}\\] \\[%{DATA:thread}\\] %{WORD:level} (?<msg>[\\s\\S]*)"]
      }
    }
  ]
}

有關(guān)grok processor語法的說法重虑,詳見下面3.3章節(jié)Grok践付。

通過API接口在Elasticsearch中添加管道:

### 如果elasticsearch啟用了身份驗(yàn)證,則需要再加上參數(shù)`--user username:password`
curl -H 'Content-Type: application/json' -XPUT 'http://localhost:9200/_ingest/pipeline/app-log-pipeline' -d@/work/app-log-pipeline.json

修改Beat配置文件:

output.elasticsearch:
  ...
  ### 指定管道
  pipeline: "app-log-pipeline"

調(diào)整后嚎尤,在Kibana中看到的結(jié)果:

image.png

3.3 Grok

Grok是迄今為止使蹩腳的荔仁、非結(jié)構(gòu)化的日志結(jié)構(gòu)化和可查詢的最好方式伍宦。Grok在解析 syslog logs芽死、apache and other webserver logs、mysql logs等任意格式的文件上表現(xiàn)完美次洼。

在LogStash的Grok Filter关贵、Elasticsearch的Grok Processor中都使用到了Grok。

在上節(jié)中的app-log-pipeline.json中卖毁,我們使用了Grok Processor將非結(jié)構(gòu)化事件數(shù)據(jù)message解析為多個(gè)字段timestamp揖曾、topic、thread亥啦、level炭剪、msg:

      ### 從文檔中的單個(gè)文本字段message中提取結(jié)構(gòu)化字段
      "grok" : {
        "field" : "message",
        "patterns" :["\\[%{TIMESTAMP_ISO8601:timestamp}\\] \\[%{WORD:topic}\\] \\[%{DATA:thread}\\] %{WORD:level} (?<msg>[\\s\\S]*)"]
      }

Grok內(nèi)置了120多種的正則表達(dá)式庫,源代碼地址:https://github.com/logstash-plugins/logstash-patterns-core/tree/master/patterns翔脱。

也可以通過自定義正則表達(dá)式和命名分組直接攝取字段奴拦,如上面示例中通過(?<msg>[\\s\\S]*)攝取字段msg

提示:在數(shù)據(jù)處理管道中使用之前届吁,您可以在Kibana Grok Debugger中構(gòu)建和調(diào)試grok模式错妖。

3.4 Processors/Filter

除了Grok Processor/Filter,經(jīng)常還需要用到其它的一些Processor/Filter疚沐,如geoid暂氯、date、user_agent亮蛔、remove等痴施,示例如下:

{
  "description" : "apache-log-pipeline",
  "processors" : [
    {
      ### 從文檔中的單個(gè)文本字段message中提取結(jié)構(gòu)化字段
      "grok" : {
        "field" : "message",
        "patterns" :["%{IPORHOST:clientip} %{USER:ident} %{USER:auth} \\[%{HTTPDATE:timestamp}\\] \"%{WORD:verb} %{DATA:request} HTTP/%{NUMBER:httpversion}\" %{NUMBER:response:int} (?:-|%{NUMBER:bytes:int}) %{QS:referrer} %{QS:useragent}"]
      },
      ### 添加關(guān)于IP地址的地理位置信息(基于MaxMind數(shù)據(jù)庫中的數(shù)據(jù))
      "geoip" : {
        "field" : "clientip",
        "target_field": "geo"
      },
      ### 解析字段中的日期,然后使用日期或時(shí)間戳作為文檔的時(shí)間戳
      "date" : {
        "field" : "timestamp",
        "target_field" : "@timestamp",
        "formats" : ["dd/MMM/yyyy:HH:mm:ss Z"],
        "timezone" : "Asia/Shanghai"
      },
      ### 從瀏覽器發(fā)送Web請(qǐng)求中所述的user_agent字符串中提取細(xì)節(jié)信息
      "user_agent" : {
        "field" : "useragent"
      },
      ### 刪除現(xiàn)有字段
      "remove": {
        "field": "message"
      }
    }
  ]
}

Processors

Filter plugins

詳見Filter plugins

4、引入緩沖機(jī)制

如果您要追蹤問題并查看一組日志辣吃,則只需要一個(gè)缺少的日志即可能得不到正確的結(jié)果锉矢。如果您丟失了其中一個(gè)事件,則可能無法查明問題的原因齿尽。

Elasticsearch是ELK核心的引擎沽损。它非常容易受到負(fù)載,這意味著在索引和增加文檔數(shù)量時(shí)需要非常小心循头。當(dāng)Elasticsearch忙碌時(shí)绵估,Logstash的工作速度比平常慢 - 這是緩沖區(qū)累積了更多即將推送到Elasticsearch的文檔。這對(duì)于丟失日志事件至關(guān)重要卡骂。

一般來說国裳,生產(chǎn)級(jí)ELK實(shí)現(xiàn)需要:

  • 必須確保捕獲每個(gè)到日志事件
  • 在生產(chǎn)系統(tǒng)過載甚至失敗時(shí)運(yùn)行

確保彈性數(shù)據(jù)管道的推薦方法是在Logstash前面放置一個(gè)緩沖區(qū),作為發(fā)送到系統(tǒng)的所有日志事件的入口點(diǎn)全跨。然后它將緩沖數(shù)據(jù)缝左,直到下游組件有足夠的資源來索引。

常見緩沖區(qū)是Redis或Kafka浓若。

image.png

引入消息隊(duì)列中間件作為緩沖渺杉,beats采集到的數(shù)據(jù)先輸出到消息隊(duì)列中,再由logstash作為隊(duì)列的消費(fèi)者進(jìn)行數(shù)據(jù)處理后挪钓,輸出到elasticsearch是越。

出于說明的目的,這當(dāng)然是簡(jiǎn)化圖碌上。完整的生產(chǎn)級(jí)體系結(jié)構(gòu)將包含多個(gè)Elasticsearch節(jié)點(diǎn)倚评,可能包含多個(gè)Logstash實(shí)例、歸檔機(jī)制馏予、警報(bào)插件以及跨數(shù)據(jù)中心區(qū)域或部分的完全復(fù)制天梧,以實(shí)現(xiàn)高可用性。

image.png

4.1 redis方案

  • 安裝啟動(dòng)redis

linux: https://redis.io/download
windows: https://github.com/microsoftarchive/redis/releases

  • 配置filebeat.yml

output.redis:
  hosts: ["127.0.0.1:6379"]
  password: "123456"
  key: "filebeat-redis"
  db: 0
  timeout: 5
  • 配置logstash.confinputoutput節(jié):

input {
  redis {
    host => "127.0.0.1"
    port => "6379"
    password => "123456"
    data_type => "list"
    db => 0
    batch_count => 1
    #type => "log"
    key => "filebeat-redis"
  }
}

# filter {
#  ...
# }

output {
  elasticsearch {
    hosts => "localhost:9200"
    manage_template => false
    index => "%{[@metadata][beat]}-redis-%{[@metadata][version]}-%{+YYYY.MM.dd}"
    pipeline => "app-log-pipeline"
  }
}

4.2 kafka方案

  • 安裝啟動(dòng)zookeeper

https://zookeeper.apache.org/doc/current/zookeeperStarted.html

  • 安裝啟動(dòng)Kafka

https://kafka.apache.org/quickstart

  • 配置filebeat.yml

output.kafka:
  # initial brokers for reading cluster metadata
  hosts: ["localhost:9092"] #["kafka1:9092", "kafka2:9092", "kafka3:9092"]

  # message topic selection + partitioning
  topic: "filebeat-kafka" #'%{[fields.log_topic]}'
  partition.round_robin:
    reachable_only: false

  required_acks: 1
  compression: gzip
  max_message_bytes: 1000000
  • 配置logstash.confinputoutput節(jié):

input {
  kafka {
    bootstrap_servers => "localhost:9092"
    topics => "filebeat-kafka"
    group_id => "logstash"
  }
}

filter {  
  grok {    
      match => {
         "message" => "\[%{TIMESTAMP_ISO8601:timestamp}\] \[%{WORD:topic}\] \[%{DATA:thread}\] %{WORD:level} (?<msg>[\s\S]*)"
      }
  }
}

output {
  elasticsearch {
    hosts => "localhost:9200"
    manage_template => false
    index => "filebeat-kafka-%{+YYYY.MM.dd}"
    # pipeline => "app-log-pipeline"
  }
}

4.3 使用Logstash限流

為了防止異常終止期間的數(shù)據(jù)丟失霞丧,Logstash具有持久隊(duì)列功能呢岗,該功能將消息隊(duì)列存儲(chǔ)在磁盤上。啟用持久隊(duì)列的好處如下:

  • 在正常關(guān)閉期間以及Logstash異常終止時(shí)提供至少一次傳遞保證以防止消息丟失蚯妇。如果在事件發(fā)生時(shí)重新啟動(dòng)Logstash敷燎,Logstash將嘗試傳遞存儲(chǔ)在持久隊(duì)列中的消息,直到傳遞成功至少一次箩言。
  • 無需像Redis或Apache Kafka這樣的外部緩沖機(jī)制即可吸收突發(fā)事件硬贯。
image.png

配置示例:

queue.type: persisted
queue.max_bytes: 4gb

當(dāng)隊(duì)列已滿時(shí),Logstash會(huì)對(duì)input端施加Back-Pressure陨收,以阻止流入Logstash的數(shù)據(jù)饭豹。這種機(jī)制有助于Logstash控制輸入階段的數(shù)據(jù)流速率鸵赖,而不會(huì)壓倒性地輸出到output端(如Elasticsearch)。

5拄衰、其它最佳實(shí)踐

5.1 使用Security增加訪問安全性

5.1.1 身份驗(yàn)證-安全登錄

????要想保護(hù)流經(jīng) Elasticsearch它褪、Kibana、Beats 和 Logstash 的數(shù)據(jù)翘悉,以免數(shù)據(jù)受到意外修改或被未經(jīng)授權(quán)用戶的訪問茫打,這是第一步。

xpack.security.enabled: true
### 需要額外設(shè)置此選項(xiàng)妖混,否則啟動(dòng)時(shí)會(huì)報(bào)錯(cuò)
xpack.security.transport.ssl.enabled: true
./bin/elasticsearch-setup-passwords interactive

如果您不介意在配置文件中顯示密碼老赤,請(qǐng)取消注釋并更新kibana.yml

elasticsearch.username: "kibana"
elasticsearch.password: "123456"

如果您不想將用戶ID和密碼放在kibana.yml文件中,請(qǐng)將它們存儲(chǔ)在密鑰庫中

./bin/kibana-keystore create
./bin/kibana-keystore add elasticsearch.username
./bin/kibana-keystore add elasticsearch.password

此后制市,登錄Kibana將出現(xiàn)登錄頁面抬旺,需要輸入內(nèi)置的超級(jí)用戶權(quán)限帳號(hào)elastic進(jìn)行登錄。

image.png

5.1.2 授權(quán)-管理用戶和角色

交付給用戶使用時(shí)祥楣,一般會(huì)創(chuàng)建最小權(quán)限的用戶开财,示例:
Management / Security中創(chuàng)建用戶,并分配分配kibana_user內(nèi)置角色误褪。

如果您不介意在配置文件中顯示密碼责鳍,請(qǐng) 在Logstash目錄中的文件中添加以下內(nèi)容user和password設(shè)置demo-metrics-pipeline.conf:

...
output {
  elasticsearch {
    ...
    user => "logstash_system" 
    password => "123456" 
  }
}

如果您不想將您的用戶ID和密碼放在配置文件中,請(qǐng)將它們存儲(chǔ)在密鑰庫中振坚。

set +o history
export LOGSTASH_KEYSTORE_PASS=mypassword 
set -o history
./bin/logstash-keystore create
./bin/logstash-keystore add ES_USER
./bin/logstash-keystore add ES_PWD
output {
  elasticsearch {
    ...
    user => "${ES_USER}"
    password => "${ES_PWD}"
  }
}
  • 在filebeat中添加用戶信息

如果您不介意在配置文件中顯示密碼薇搁,請(qǐng) 在Logstash目錄中的文件中添加以下內(nèi)容user和password設(shè)置demo-metrics-pipeline.conf:

...
output {
  elasticsearch {
    ...
    user => "logstash_system" 
    password => "123456" 
  }
}

如果您不想將您的密碼放在配置文件中斋扰,請(qǐng)將它們存儲(chǔ)在密鑰庫中渡八。

filebeat keystore create
filebeat keystore add ES_PWD
output {
  elasticsearch {
    ...
    user => "logstash_system"
    password => "${ES_PWD}"
  }
}

注意:
如果您直接從Metricbeat連接到Elasticsearch,則需要在Metricbeat配置文件中為Elasticsearch輸出配置身份驗(yàn)證憑據(jù)传货。在 入門彈性堆棧屎鳍,但是,你配置Metricbeat發(fā)送數(shù)據(jù)到Logstash額外的解析问裕,所以在Metricbeat不需要額外的設(shè)置逮壁。

參考:Tutorial: Getting started with security

以下功能為非基礎(chǔ)許可證所有功能,詳見:訂閱 · Elastic Stack 產(chǎn)品和支持 | Elastic

  • 加密-防止嗅探粮宛、篡改和監(jiān)聽
  • 分層安全-全方位保護(hù)窥淆,直到字段級(jí)
  • 審核日志-記錄何人何時(shí)做過何事
  • 合規(guī)性-符合安全標(biāo)準(zhǔn)

5.2 管理索引的生命周期

Index Lifecycle Management (ILM) 使您能夠自動(dòng)化您希望隨著時(shí)間的推移來管理你的索引。您可以將操作基于其他因素(如分片大小和性能要求)巍杈,而不是簡(jiǎn)單地在設(shè)置的計(jì)劃上對(duì)索引執(zhí)行管理操作忧饭。
您可以通過將生命周期策略附加到用于創(chuàng)建索引模板的索引模板來控制索引在老化時(shí)的處理方式。您可以更新策略以修改新索引和現(xiàn)有索引的生命周期筷畦。

對(duì)于時(shí)間序列索引词裤,索引生命周期中有四個(gè)階段:

階段 說明
Hot 索引正在積極更新和查詢刺洒。
Warm 索引不再更新,但仍在查詢中吼砂。
Cold 索引不再被更新逆航,很少被查詢。信息仍然需要搜索渔肩,但如果這些查詢速度較慢也沒關(guān)系因俐。
Delete 不再需要索引,可以安全刪除周偎。
setup.ilm.enabled: auto
setup.ilm.rollover_alias: "filebeat"
setup.ilm.pattern: "{now/d}-000001"
setup.ilm.policy_name: "filebeat-{agent.version}" # default value
  • Kibana中可視化配置生命周期管理

通過Elasticsearch的開放API接口女揭,可設(shè)置索引生命周期管理策略。使用Kibana管理界面可實(shí)現(xiàn)同樣的效果:

Management / Index Lifecycle Policies中創(chuàng)建和編輯生命周期策略:

image.png

Management / Index management中設(shè)置索引對(duì)應(yīng)的Lifecycle Policy:

image.png

5.3 自定義輸出到Elasticsearch的Index Name

由于系統(tǒng)默認(rèn)啟用ILM(詳見 Index Lifecycle Management (ILM) )栏饮,F(xiàn)ilebeat的output.elasticsearch.index配置項(xiàng)將會(huì)被覆蓋吧兔,因此可以使用如下配置自定義輸出elasticsearch index(詳見Filebeat配置索引生命周期管理):

### customize index name
setup.ilm.rollover_alias: "applog"
setup.ilm.pattern: "{now/d}-000001"

output.elasticsearch:
  ...
  # index: "applog-%{[agent.version]}-%{+yyyy.MM.dd}"

5.4 Elasticsearch設(shè)置JVM選項(xiàng)

Elasticsearch有三個(gè)配置文件,這些文件位于config目錄中:

  • elasticsearch.yml 用于配置Elasticsearch
  • jvm.options 用于配置Elasticsearch JVM設(shè)置
  • log4j2.properties 用于配置Elasticsearch日志記錄

一般很少需要更改Java虛擬機(jī)(JVM)選項(xiàng)袍嬉,最可能的更改是設(shè)置堆大小境蔼。

-Xms1g
-Xmx1g

5.5 監(jiān)控Logstash / Elasticsearch異常

前面提到過,如果您要追蹤問題并查看一組日志伺通,則只需要一個(gè)缺少的日志即可能得不到正確的結(jié)果箍土。

嘗試索引Elasticsearch中無法適應(yīng)自動(dòng)生成的映射的日志時(shí)凫佛,Logstash可能會(huì)失敗褥傍。
Elasticsearch不會(huì)為文檔編制索引,它只會(huì)返回失敗消息并且日志將被刪除懈凹。

為了確保捕獲每個(gè)到日志事件弓柱,必須始終向Logstash提供信息并監(jiān)視Elasticsearch異常沟堡, 以確保日志不以錯(cuò)誤的格式發(fā)送。

//TODO:如何監(jiān)控elasticsearch.log矢空、logstash.log

5.6 可視化分析Web訪問日志

通過采集Nginx等Web服務(wù)器上的訪問日志航罗,使用圖表和儀表盤進(jìn)行可視化分析:

FireShot Capture 006 - yh-Web訪問日志分析 - Kibana - localhost.png

5.7 Filebeat CPU使用率

Filebeat是一個(gè)非常輕量級(jí)的托運(yùn)者,占用空間小屁药,雖然很少發(fā)現(xiàn)有關(guān)Filebeat的抱怨粥血,但在某些情況下,您可能會(huì)遇到高CPU使用率酿箭。

影響所用計(jì)算能力的一個(gè)因素是掃描頻率 - Filebeat配置為掃描文件的頻率复亏。可以使用Filebeat配置文件中的scan_frequency設(shè)置為每個(gè)探測(cè)器定義此頻率缭嫡,因此如果您有大量探測(cè)器以嚴(yán)格的掃描頻率運(yùn)行缔御,則可能導(dǎo)致CPU使用率過高。

參考:Why is Filebeat using too much CPU?

5.8 使用Alerting告警

Alerting告警為非基礎(chǔ)許可證所有功能械巡,詳見:訂閱 · Elastic Stack 產(chǎn)品和支持 | Elastic
TODO:待研究...ELK借助ElastAlert實(shí)現(xiàn)故障提前感知預(yù)警功能

5.9 使用MetricBeat監(jiān)控服務(wù)器

5.10 APM插件

6刹淌、生產(chǎn)環(huán)境配置

默認(rèn)情況下啟動(dòng)的Elasticsearch只綁定到localhost地址饶氏,局域網(wǎng)內(nèi)也無法訪問,這不適合于生產(chǎn)環(huán)境有勾,可以通過network.host配置解決疹启。另外對(duì)于服務(wù)器數(shù)量有限的情況,也可以使用Single-node discovery模式啟動(dòng)單節(jié)點(diǎn)蔼卡。

network.host: 192.168.52.35
discovery.seed_hosts: ["192.168.52.35"]
discovery.type: single-node

參考:
Important Elasticsearch configuration
Bootstrap Checks

Run as a Service

linux:

sudo /bin/systemctl daemon-reload
sudo /bin/systemctl enable elasticsearch.service
sudo systemctl start elasticsearch.service
sudo systemctl stop elasticsearch.service

elasticsearch.service文件:
https://github.com/elastic/elasticsearch/blob/master/distribution/packages/src/common/systemd/elasticsearch.service

Kibana配置參考:

server.host: "192.168.52.35"
elasticsearch.hosts: ["http://192.168.52.35:9200"]

7喊崖、Cluster方案

Elasticsearch由許多不同的節(jié)點(diǎn)類型組成,其中兩個(gè)是最重要的:主節(jié)點(diǎn)和數(shù)據(jù)節(jié)點(diǎn)雇逞。主節(jié)點(diǎn)負(fù)責(zé)集群管理荤懂,而數(shù)據(jù)節(jié)點(diǎn),顧名思義塘砸,負(fù)責(zé)數(shù)據(jù)(詳細(xì)了解如何在此處設(shè)置Elasticsearch集群)节仿。

我們建議構(gòu)建一個(gè)由至少三個(gè)主節(jié)點(diǎn)組成的Elasticsearch集群,因?yàn)槠毡榇嬖诹涯X掉蔬,這實(shí)際上是兩個(gè)節(jié)點(diǎn)之間關(guān)于哪一個(gè)實(shí)際上是主節(jié)點(diǎn)的爭(zhēng)議廊宪。

就數(shù)據(jù)節(jié)點(diǎn)而言,我們建議至少擁有兩個(gè)數(shù)據(jù)節(jié)點(diǎn)女轿,以便至少復(fù)制一次數(shù)據(jù)箭启。這導(dǎo)致至少五個(gè)節(jié)點(diǎn):三個(gè)主節(jié)點(diǎn)可以是小型機(jī)器,并且兩個(gè)數(shù)據(jù)節(jié)點(diǎn)需要在具有非瞅燃#快的存儲(chǔ)和大容量存儲(chǔ)器的固態(tài)機(jī)器上擴(kuò)展傅寡。

我們建議您將Elasticsearch節(jié)點(diǎn)運(yùn)行在不同的可用區(qū)域或數(shù)據(jù)中心的不同部分,以確保高可用性北救。這可以通過Elasticsearch設(shè)置來完成荐操,該設(shè)置允許您配置要在不同AZ之間復(fù)制的每個(gè)文檔。與Logstash一樣扭倾,由于數(shù)據(jù)傳輸淀零,由此類部署產(chǎn)生的成本可能非常陡峭。

8膛壹、快速安裝包

9、大數(shù)據(jù)擴(kuò)展

Elasticsearch-Hadoop (ES-Hadoop) 連接器將 Hadoop 海量的數(shù)據(jù)存儲(chǔ)和深度加工能力與 Elasticsearch 實(shí)時(shí)搜索和分析功能進(jìn)行連接唉堪。

image.png

三模聋、阿里云日志服務(wù)

查詢分析全方位對(duì)比(ELK)

查詢方案(ELK/Hive)對(duì)比

使用Producer Library采集日志

LogHub 支持客戶端、網(wǎng)頁唠亚、協(xié)議链方、SDK/API、云產(chǎn)品等多種日志無損采集方式灶搜,所有采集方式均基于Restful API實(shí)現(xiàn)祟蚀。

Aliyun LOG Java Producer 是一個(gè)易于使用且高度可配置的 Java 類庫工窍,專門為運(yùn)行在大數(shù)據(jù)、高并發(fā)場(chǎng)景下的 Java 應(yīng)用量身打造前酿。

Github 項(xiàng)目地址以及更多詳細(xì)說明請(qǐng)參見Aliyun LOG Java Producer

只需要簡(jiǎn)單的幾個(gè)步驟患雏,就可以使用日志聚合和可視化查詢:

  1. pom添加引用
<dependency>
    <groupId>com.aliyun.openservices</groupId>
    <artifactId>aliyun-log-producer</artifactId>
    <version>0.2.0</version>
</dependency>
<dependency>
    <groupId>com.aliyun.openservices</groupId>
    <artifactId>aliyun-log</artifactId>
    <version>0.6.31</version>
</dependency>
<dependency>
    <groupId>com.google.protobuf</groupId>
    <artifactId>protobuf-java</artifactId>
    <version>2.5.0</version>
</dependency>

注意:由于com.aliyun.openservices:aliyun-log中引用的commons-validator是1.4.0的版本,因此項(xiàng)目中的commons-validator也需要升級(jí)為1.4.0的版本罢维,否則會(huì)有異常淹仑。

 <dependency>
    <groupId>commons-validator</groupId>
    <artifactId>commons-validator</artifactId>
    <version>1.4.0</version>
</dependency>
  1. 編寫繼承自AppenderBase的自定義AppenderAliyunLogAppender,參考ylzpay-common模塊下的AliyunLogAppender
  1. 配置logback.xml肺孵,增加新的Appender
    <appender name="aliyun" class="com.ylzinfo.onepay.sdk.log.AliyunLogAppender">
        <projectName>ylz</projectName>
        <logStore>ylz-test</logStore>
        <endpoint>ylz-test.cn-shenzhen.log.aliyuncs.com</endpoint>
        <accessKeyId>{yourAccessKeyId}</accessKeyId>
        <accessKeySecret>{yourAccessKeySecret}</accessKeySecret>>
        <topic>ylzpay-test-web</topic>
        <timeFormat>yyyy-MM-dd HH:mm:ss</timeFormat>
        <timeZone>GMT+8</timeZone>
        <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
            <level>INFO</level>
        </filter>
    </appender>
    ...
    <root level="debug">
        ...
        <appender-ref ref="aliyun"/>
    </root>

效果:


image.png

日志服務(wù)其它最佳實(shí)線

典型使用場(chǎng)景

  • 云產(chǎn)品采集-負(fù)載均衡7層訪問日志

https://help.aliyun.com/document_detail/66828.html?spm=a2c4g.11186623.6.646.42551519Egyw0M

  • 可視化分析匀借、圖表分析、儀表盤

https://help.aliyun.com/document_detail/102530.html?spm=a2c4g.11186623.6.844.5485566aKsTXr6

  • 聚類分析

https://help.aliyun.com/document_detail/100039.html?spm=5176.11065259.1996646101.searchclickresult.13fc56e37dNOnn

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
  • 序言:七十年代末平窘,一起剝皮案震驚了整個(gè)濱河市吓肋,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌瑰艘,老刑警劉巖蓬坡,帶你破解...
    沈念sama閱讀 216,324評(píng)論 6 498
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場(chǎng)離奇詭異磅叛,居然都是意外死亡屑咳,警方通過查閱死者的電腦和手機(jī),發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 92,356評(píng)論 3 392
  • 文/潘曉璐 我一進(jìn)店門弊琴,熙熙樓的掌柜王于貴愁眉苦臉地迎上來兆龙,“玉大人,你說我怎么就攤上這事敲董∽匣剩” “怎么了?”我有些...
    開封第一講書人閱讀 162,328評(píng)論 0 353
  • 文/不壞的土叔 我叫張陵腋寨,是天一觀的道長聪铺。 經(jīng)常有香客問我,道長萄窜,這世上最難降的妖魔是什么铃剔? 我笑而不...
    開封第一講書人閱讀 58,147評(píng)論 1 292
  • 正文 為了忘掉前任,我火速辦了婚禮查刻,結(jié)果婚禮上键兜,老公的妹妹穿的比我還像新娘。我一直安慰自己穗泵,他們只是感情好普气,可當(dāng)我...
    茶點(diǎn)故事閱讀 67,160評(píng)論 6 388
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著佃延,像睡著了一般现诀。 火紅的嫁衣襯著肌膚如雪夷磕。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 51,115評(píng)論 1 296
  • 那天仔沿,我揣著相機(jī)與錄音坐桩,去河邊找鬼。 笑死于未,一個(gè)胖子當(dāng)著我的面吹牛撕攒,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播烘浦,決...
    沈念sama閱讀 40,025評(píng)論 3 417
  • 文/蒼蘭香墨 我猛地睜開眼抖坪,長吁一口氣:“原來是場(chǎng)噩夢(mèng)啊……” “哼!你這毒婦竟也來了闷叉?” 一聲冷哼從身側(cè)響起擦俐,我...
    開封第一講書人閱讀 38,867評(píng)論 0 274
  • 序言:老撾萬榮一對(duì)情侶失蹤,失蹤者是張志新(化名)和其女友劉穎握侧,沒想到半個(gè)月后蚯瞧,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 45,307評(píng)論 1 310
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡品擎,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 37,528評(píng)論 2 332
  • 正文 我和宋清朗相戀三年埋合,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片萄传。...
    茶點(diǎn)故事閱讀 39,688評(píng)論 1 348
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡甚颂,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出秀菱,到底是詐尸還是另有隱情振诬,我是刑警寧澤,帶...
    沈念sama閱讀 35,409評(píng)論 5 343
  • 正文 年R本政府宣布衍菱,位于F島的核電站赶么,受9級(jí)特大地震影響,放射性物質(zhì)發(fā)生泄漏脊串。R本人自食惡果不足惜辫呻,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 41,001評(píng)論 3 325
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望洪规。 院中可真熱鬧印屁,春花似錦、人聲如沸斩例。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,657評(píng)論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽念赶。三九已至础钠,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間叉谜,已是汗流浹背旗吁。 一陣腳步聲響...
    開封第一講書人閱讀 32,811評(píng)論 1 268
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留停局,地道東北人很钓。 一個(gè)月前我還...
    沈念sama閱讀 47,685評(píng)論 2 368
  • 正文 我出身青樓,卻偏偏與公主長得像董栽,于是被迫代替她去往敵國和親码倦。 傳聞我的和親對(duì)象是個(gè)殘疾皇子,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 44,573評(píng)論 2 353

推薦閱讀更多精彩內(nèi)容