這是我們?cè)?Monitorama 2022 上發(fā)表的演講的改編稿。您可以在此處找到包含演講者筆記的幻燈片和此處的視頻。

圖片

當(dāng) Cloudflare 的請(qǐng)求拋出錯(cuò)誤時(shí)，信息會(huì)記錄在我們的 requests_error 管道中。錯(cuò)誤日志用于幫助解決特定于客戶(hù)或網(wǎng)絡(luò)范圍的問(wèn)題。

我們，站點(diǎn)可靠性工程師 (SRE)，負(fù)責(zé)管理日志平臺(tái)。我們已經(jīng)運(yùn)行Elasticsearch集群很多年了，這些年來(lái)日志量急劇增加。隨著日志量的增加，我們開(kāi)始面臨一些問(wèn)題。查詢(xún)性能慢、資源消耗高等。我們的目標(biāo)是通過(guò)提高查詢(xún)性能并提供經(jīng)濟(jì)高效的日志存儲(chǔ)解決方案來(lái)改善日志消費(fèi)者的體驗(yàn)。這篇博文討論了日志記錄管道的挑戰(zhàn)以及我們?nèi)绾卧O(shè)計(jì)新架構(gòu)以使其更快且更具成本效益。

在我們深入探討維護(hù)日志管道的挑戰(zhàn)之前，讓我們先了解一下日志的特征。

日志的特征

圖片

不可預(yù)測(cè)：當(dāng)今世界，微服務(wù)數(shù)量眾多，集中式日志系統(tǒng)將收到的日志量非常難以預(yù)測(cè)。日志體量估算如此困難的原因有多種。主要是因?yàn)樾聭?yīng)用程序不斷部署到生產(chǎn)中，現(xiàn)有應(yīng)用程序會(huì)自動(dòng)擴(kuò)展或縮小以滿(mǎn)足業(yè)務(wù)需求，或者有時(shí)應(yīng)用程序所有者啟用調(diào)試日志級(jí)別并忘記將其關(guān)閉。

上下文：對(duì)于調(diào)試問(wèn)題，通常需要上下文信息，即事件發(fā)生之前和之后的日志。單個(gè)日志行幾乎沒(méi)有幫助，通常，是一組日志行有助于構(gòu)建上下文。此外，我們經(jīng)常需要將多個(gè)應(yīng)用程序的日志關(guān)聯(lián)起來(lái)以繪制全貌。因此，必須保留日志在數(shù)據(jù)源處填充的順序。

寫(xiě)入密集型：任何集中式日志系統(tǒng)都是寫(xiě)入密集型的。超過(guò) 99% 的已寫(xiě)入日志從未被讀取。它們占用空間一段時(shí)間，并最終被保留策略清除。剩下的不到1%的被讀取的日志非常重要，我們不能錯(cuò)過(guò)它們。

日志管道

與大多數(shù)其他公司一樣，我們的日志記錄管道由生產(chǎn)者、路由轉(zhuǎn)發(fā)器、隊(duì)列、消費(fèi)者和存儲(chǔ)組成。

圖片

在 Cloudflare 全球網(wǎng)絡(luò)上運(yùn)行的應(yīng)用程序（生產(chǎn)者）生成日志。這些日志以 Cap’n Proto 序列化格式在本地寫(xiě)入。 Shipper（內(nèi)部解決方案）通過(guò)流將 Cap’n Proto 序列化日志推送到 Kafka（隊(duì)列）進(jìn)行處理。我們運(yùn)行 Logstash（消費(fèi)者），它從 Kafka 消費(fèi)并將日志寫(xiě)入 ElasticSearch（數(shù)據(jù)存儲(chǔ)）。然后使用 Kibana 或 Grafana 可視化數(shù)據(jù)。我們?cè)?Kibana 和 Grafana 中內(nèi)置了多個(gè)儀表板來(lái)可視化數(shù)據(jù)。

Cloudflare 的 Elasticsearch 瓶頸

在 Cloudflare，我們多年來(lái)一直運(yùn)行 Elasticsearch 集群。多年來(lái)，日志量急劇增加，在優(yōu)化 Elasticsearch 集群以處理此類(lèi)量時(shí)，我們發(fā)現(xiàn)了一些限制。

Mapping 爆炸

圖片

Mapping 爆炸是 Elasticsearch 眾所周知的局限性之一。 Elasticsearch 維護(hù)一個(gè)映射，決定如何存儲(chǔ)和索引新文檔及其字段。當(dāng)此映射中的鍵太多時(shí)，可能會(huì)占用大量?jī)?nèi)存，從而導(dǎo)致頻繁的垃圾回收。防止這種情況的一種方法是使 schema 嚴(yán)格，這意味著任何不遵循此嚴(yán)格 schema 的日志行最終都會(huì)被刪除。另一種方法是使其成為半嚴(yán)格的，這意味著不屬于此映射的任何字段都將不可搜索。

多租戶(hù)支持

圖片

Elasticsearch 沒(méi)有很好的多租戶(hù)支持。一個(gè)壞用戶(hù)很容易影響集群性能。無(wú)法限制查詢(xún)可以讀取的文檔或索引的最大數(shù)量或 Elasticsearch 查詢(xún)可以占用的內(nèi)存量。錯(cuò)誤的查詢(xún)很容易降低集群性能，即使查詢(xún)完成后，它仍然會(huì)留下影響。

集群維護(hù)工作

管理Elasticsearch集群并不容易，尤其是多租戶(hù)集群。一旦集群降級(jí)，就需要花費(fèi)大量時(shí)間才能使集群恢復(fù)到完全健康的狀態(tài)。在Elasticsearch中，更新索引模板意味著重新索引數(shù)據(jù)，這是一個(gè)相當(dāng)大的開(kāi)銷(xiāo)。我們使用冷熱分層存儲(chǔ)，即最近的數(shù)據(jù)存儲(chǔ)在 SSD 中，較舊的數(shù)據(jù)存儲(chǔ)在機(jī)械硬盤(pán)中。雖然Elasticsearch每天都會(huì)將數(shù)據(jù)從熱存儲(chǔ)移動(dòng)到冷存儲(chǔ)，但它會(huì)影響集群的讀寫(xiě)性能。

垃圾回收

圖片

Elasticsearch 使用 Java 開(kāi)發(fā)并在 Java 虛擬機(jī) (JVM) 上運(yùn)行。它執(zhí)行垃圾收集以回收由程序分配但不再引用的內(nèi)存。Elasticsearch 需要垃圾收集調(diào)整。最新的 JVM 中默認(rèn)的垃圾回收是 G1GC。我們嘗試了其他 GC，例如 ZGC，這有助于減少 GC 暫停，但在讀寫(xiě)吞吐量方面并沒(méi)有給我們帶來(lái)太多性能優(yōu)勢(shì)。

圖片

Elasticsearch 是一個(gè)很好的全文搜索工具，這些限制對(duì)于小型集群來(lái)說(shuō)并不重要，但在 Cloudflare 中，我們每秒處理超過(guò) 35 到 4500 萬(wàn)個(gè) HTTP 請(qǐng)求，其中每秒有超過(guò) 500K-800K 的請(qǐng)求失敗。這些失敗可能是由于不正確的請(qǐng)求、源服務(wù)器錯(cuò)誤、用戶(hù)配置錯(cuò)誤、網(wǎng)絡(luò)問(wèn)題和各種其他原因造成的。

我們的客戶(hù)支持團(tuán)隊(duì)使用這些錯(cuò)誤日志作為定位客戶(hù)問(wèn)題的起點(diǎn)。錯(cuò)誤日志包含有關(guān) HTTP 請(qǐng)求所經(jīng)過(guò)的各種 Cloudflare 產(chǎn)品的許多字段元數(shù)據(jù)。我們將這些錯(cuò)誤日志存儲(chǔ)在 Elasticsearch 中。我們對(duì)它們進(jìn)行了大量采樣，因?yàn)榇鎯?chǔ)所有內(nèi)容需要花費(fèi)數(shù)百 TB 的空間，超出了我們的資源分配預(yù)算。此外，基于它構(gòu)建的儀表板非常慢，因?yàn)樗鼈冃枰獙?duì)各個(gè)字段進(jìn)行大量聚合。根據(jù)調(diào)試要求，我們需要將這些日志保留幾周。

建議的解決方案

我們希望完全取消采樣，即存儲(chǔ)保留期內(nèi)的每條日志行，為如此龐大的數(shù)據(jù)量提供快速查詢(xún)支持，并在不增加成本的情況下實(shí)現(xiàn)這一切。為了解決所有這些問(wèn)題，我們決定進(jìn)行概念驗(yàn)證，看看是否可以使用 ClickHouse 來(lái)滿(mǎn)足我們的要求。

Cloudflare 是 ClickHouse 的早期采用者，我們多年來(lái)一直在管理 ClickHouse 集群。我們已經(jīng)擁有許多內(nèi)部工具和庫(kù)，用于將數(shù)據(jù)插入 ClickHouse，這使我們可以輕松進(jìn)行概念驗(yàn)證。讓我們看一下 ClickHouse 的一些功能，這些功能使其非常適合存儲(chǔ)日志，并使我們能夠構(gòu)建新的日志管道。

圖片

ClickHouse 是一個(gè)面向列的數(shù)據(jù)庫(kù)，這意味著與特定列相關(guān)的所有數(shù)據(jù)在物理上彼此相鄰存儲(chǔ)。即使在普通商用硬件上，這種數(shù)據(jù)布局也有助于快速順序掃描。這使我們能夠從老一代硬件中獲得最大性能。

圖片

ClickHouse 專(zhuān)為分析工作負(fù)載而設(shè)計(jì)，數(shù)據(jù)可以有很多列。我們能夠設(shè)計(jì)具有大量列的新 ClickHouse 表，而不會(huì)犧牲性能。

圖片

ClickHouse 索引的工作方式與關(guān)系數(shù)據(jù)庫(kù)中的索引不同。在關(guān)系數(shù)據(jù)庫(kù)中，主索引非常密集，并且每個(gè)表行包含一個(gè)條目。因此，如果表中有 100 萬(wàn)行，主索引也將有 100 萬(wàn)個(gè)條目。而在 ClickHouse 中，索引是稀疏的，這意味著每幾千行只有一個(gè)索引條目。ClickHouse 索引使我們能夠動(dòng)態(tài)添加新索引。

ClickHouse 默認(rèn)使用 LZ4 壓縮所有內(nèi)容。高效的壓縮不僅有助于最大限度地減少存儲(chǔ)需求，還可以讓 ClickHouse 有效地使用頁(yè)面緩存。

ClickHouse 的一項(xiàng)很酷的功能是可以按列配置壓縮編解碼器。我們決定為所有列保留默認(rèn)的 LZ4 壓縮。我們對(duì) DateTime 列使用了 Double-Delta，對(duì) Float 列使用了 Gorilla，對(duì)固定大小的 String 列使用了 LowCardinality。

ClickHouse是線性可擴(kuò)展的；也就是說(shuō)，寫(xiě)入可以通過(guò)添加新分片來(lái)擴(kuò)展，讀取可以通過(guò)添加新副本來(lái)擴(kuò)展。ClickHouse 集群中的每個(gè)節(jié)點(diǎn)都是相同的。沒(méi)有任何特殊節(jié)點(diǎn)有助于輕松擴(kuò)展集群。

讓我們看一下我們用來(lái)提供更快的讀/寫(xiě)吞吐量和更好的日志數(shù)據(jù)壓縮的一些優(yōu)化。

Inserter

擁有高效的插入器與擁有高效的數(shù)據(jù)存儲(chǔ)一樣重要。在 Cloudflare，我們一直在運(yùn)行相當(dāng)多的分析管道，在編寫(xiě)新的插入器時(shí)我們借用了大部分概念。我們使用 Cap’n Proto 消息作為傳輸數(shù)據(jù)格式，因?yàn)樗峁┛焖俚臄?shù)據(jù)編碼和解碼。擴(kuò)展插入器很容易，可以通過(guò)添加更多 Kafka 分區(qū)并生成新的插入器 Pod 來(lái)完成。

圖片

Batch Size

將數(shù)據(jù)插入 ClickHouse 時(shí)的關(guān)鍵性能因素之一是批量大小。當(dāng)批量較小時(shí)，ClickHouse 會(huì)創(chuàng)建許多小分區(qū)，然后將其合并為更大的分區(qū)。因此，較小的批量大小會(huì)給 ClickHouse 在后臺(tái)帶來(lái)額外的工作，從而降低 ClickHouse 的性能。因此，將其設(shè)置得足夠大，以便 ClickHouse 可以愉快地接收數(shù)據(jù)批次，而不會(huì)達(dá)到內(nèi)存限制，這一點(diǎn)至關(guān)重要。

圖片

數(shù)據(jù)模型

ClickHouse 提供內(nèi)置的分片和復(fù)制，無(wú)需任何外部依賴(lài)。ClickHouse 的早期版本依賴(lài)于 ZooKeeper 來(lái)存儲(chǔ)復(fù)制信息，但最新版本通過(guò)添加 clickhouse-keeper 消除了對(duì) ZooKeeper 的依賴(lài)。

為了跨多個(gè)分片讀取數(shù)據(jù)，我們使用分布式表，一種特殊的表。這些表本身不存儲(chǔ)任何數(shù)據(jù)，而是充當(dāng)存儲(chǔ)實(shí)際數(shù)據(jù)的多個(gè)基礎(chǔ)表的代理。

圖片

與任何其他數(shù)據(jù)庫(kù)一樣，選擇正確的表 schema 非常重要，因?yàn)樗鼘⒅苯佑绊懶阅芎痛鎯?chǔ)利用率。我們想討論將日志數(shù)據(jù)存儲(chǔ)到 ClickHouse 中的三種方法。

圖片

第一個(gè)是最簡(jiǎn)單且最嚴(yán)格的表模式，您可以在其中指定每個(gè)列名稱(chēng)和數(shù)據(jù)類(lèi)型。任何具有此預(yù)定義 schema 之外的字段的日志行都將被刪除。根據(jù)我們的經(jīng)驗(yàn)，此架構(gòu)將為您提供最快的查詢(xún)性能。如果您已經(jīng)知道前面所有可能字段的列表，我們建議使用它。您始終可以通過(guò)運(yùn)行 ALTER TABLE 查詢(xún)來(lái)添加或刪除列。

第二種模式使用 ClickHouse 的一個(gè)非常新的功能，它完成了大部分繁重的工作。您可以將日志作為 JSON 對(duì)象插入，在幕后，ClickHouse 將了解您的日志架構(gòu)并動(dòng)態(tài)添加具有適當(dāng)數(shù)據(jù)類(lèi)型和壓縮的新列。僅當(dāng)您可以很好地控制日志架構(gòu)并且總字段數(shù)小于 1,000 時(shí)，才應(yīng)使用此架構(gòu)。一方面，它提供了自動(dòng)添加新列作為新日志字段的靈活性，但與此同時(shí)，一個(gè)糟糕的應(yīng)用程序可以輕松地破壞 ClickHouse 集群。

第三種模式將相同數(shù)據(jù)類(lèi)型的所有字段存儲(chǔ)在一個(gè)數(shù)組中，然后使用 ClickHouse 內(nèi)置數(shù)組函數(shù)來(lái)查詢(xún)這些字段。即使字段超過(guò) 1,000 個(gè)，此架構(gòu)也能很好地?cái)U(kuò)展，因?yàn)榱袛?shù)取決于日志中使用的數(shù)據(jù)類(lèi)型。如果某個(gè)數(shù)組元素被頻繁訪問(wèn)，可以利用ClickHouse的物化列功能將其取出作為專(zhuān)用列。我們建議采用此模式，因?yàn)樗梢苑乐箲?yīng)用程序記錄過(guò)多字段。

數(shù)據(jù)分區(qū)

圖片

分區(qū)是 ClickHouse 數(shù)據(jù)的一個(gè)單位。 ClickHouse 用戶(hù)常犯的一個(gè)錯(cuò)誤是分區(qū)鍵過(guò)于細(xì)化，導(dǎo)致分區(qū)過(guò)多。由于我們的日志管道每天都會(huì)生成 TB 級(jí)的數(shù)據(jù)，因此我們創(chuàng)建了使用toStartOfHour(dateTime)分區(qū)的表。通過(guò)這種分區(qū)邏輯，當(dāng)查詢(xún)?cè)?WHERE 子句中帶有時(shí)間戳?xí)r，ClickHouse 就會(huì)知道分區(qū)并快速檢索它。它還有助于根據(jù)數(shù)據(jù)保留策略設(shè)計(jì)有效的數(shù)據(jù)清除規(guī)則。

主鍵選擇

圖片

ClickHouse 將數(shù)據(jù)按主鍵排序存儲(chǔ)在磁盤(pán)上。因此，選擇主鍵會(huì)影響查詢(xún)性能并有助于更好的數(shù)據(jù)壓縮。與關(guān)系數(shù)據(jù)庫(kù)不同，ClickHouse 不需要每行都有唯一的主鍵，我們可以插入具有相同主鍵的多行。擁有多個(gè)主鍵會(huì)對(duì)插入性能產(chǎn)生負(fù)面影響。ClickHouse 的重要限制之一是，一旦創(chuàng)建表，主鍵就無(wú)法更新。

Data skipping indexes

圖片

ClickHouse 查詢(xún)性能與評(píng)估 WHERE 子句時(shí)是否可以使用主鍵成正比。我們有很多列，所有這些列都不能成為主鍵的一部分。因此，對(duì)這些列的查詢(xún)將必須進(jìn)行全面掃描，從而導(dǎo)致查詢(xún)速度變慢。在傳統(tǒng)數(shù)據(jù)庫(kù)中，可以添加二級(jí)索引來(lái)處理這種情況。在 ClickHouse 中，我們可以添加另一類(lèi)索引，稱(chēng)為數(shù)據(jù)跳過(guò)索引，它使用布隆過(guò)濾器并跳過(guò)讀取保證不匹配的重要數(shù)據(jù)塊。

ABR

我們?cè)?requests_error 日志上構(gòu)建了多個(gè)儀表板。加載這些儀表板通常會(huì)達(dá)到 ClickHouse 中為單個(gè)查詢(xún)/用戶(hù)設(shè)置的內(nèi)存限制。

基于這些日志構(gòu)建的儀表板主要用于識(shí)別異常情況。為了直觀地識(shí)別指標(biāo)中的異常情況，不需要確切的數(shù)字，但可以提供近似的數(shù)字。例如，要了解數(shù)據(jù)中心中錯(cuò)誤的增加，我們不需要確切的錯(cuò)誤數(shù)量。因此，我們決定使用圍繞 ABR 概念構(gòu)建的內(nèi)部庫(kù)和工具。

圖片

ABR 代表“自適應(yīng)比特率” - 術(shù)語(yǔ) ABR 主要用于視頻流服務(wù)，其中服務(wù)器選擇視頻流的最佳分辨率以匹配客戶(hù)端和網(wǎng)絡(luò)連接。博客文章《解釋 Cloudflare 的 ABR 分析》對(duì)此進(jìn)行了詳細(xì)描述。

換句話說(shuō)，數(shù)據(jù)以多種分辨率或采樣間隔存儲(chǔ)，并為每個(gè)查詢(xún)選擇最佳解決方案。

ABR的工作方式是在向ClickHouse寫(xiě)入請(qǐng)求時(shí)，它將數(shù)據(jù)寫(xiě)入多個(gè)具有不同采樣間隔的表中。例如table_1存儲(chǔ)100%的數(shù)據(jù)，table_10存儲(chǔ)10%的數(shù)據(jù)，table_100存儲(chǔ)1%的數(shù)據(jù)，table_1000存儲(chǔ)0.1%的數(shù)據(jù)等等。表之間的數(shù)據(jù)是重復(fù)的。 Table_10 將是 table_1 的子集。

Demo

在 Cloudflare 中，我們使用內(nèi)部庫(kù)和工具將數(shù)據(jù)插入 ClickHouse，但這可以通過(guò)使用開(kāi)源工具 - vector.dev 來(lái)實(shí)現(xiàn)。如果您想測(cè)試 ClickHouse 的日志攝取是如何工作的，您可以參考或使用https://github.com/cloudflare/cloudflare-blog/tree/master/2022-08-log-analytics的演示。

確保您已安裝 docker 并運(yùn)行docker compose up即可開(kāi)始。這將打開(kāi)三個(gè)容器，Vector.dev 用于生成矢量演示日志，將其寫(xiě)入 ClickHouse，ClickHouse 容器用于存儲(chǔ)日志，Grafana 實(shí)例用于可視化日志。當(dāng)容器啟動(dòng)后，訪問(wèn) http://localhost:3000/dashboards 來(lái)使用預(yù)構(gòu)建的演示儀表板。

總結(jié)

圖片

日志本質(zhì)上應(yīng)該是不可變的，而 ClickHouse 最適合處理不可變的數(shù)據(jù)。我們能夠?qū)㈥P(guān)鍵且重要的日志生成應(yīng)用程序之一從 Elasticsearch 遷移到更小的 ClickHouse 集群。

inserter 端的 CPU 和內(nèi)存消耗減少了八倍。每個(gè)使用 600 字節(jié)的 Elasticsearch 文檔在 ClickHouse 中減少到每行 60 字節(jié)。這種存儲(chǔ)增益使我們能夠在較新的集群中存儲(chǔ) 100% 的事件。在查詢(xún)方面，99分位的查詢(xún)延遲也顯著改善。

Elasticsearch 非常適合全文搜索，ClickHouse 非常適合分析！

不管是日志分析還是指標(biāo)體系，都少不了監(jiān)控告警。很多公司都會(huì)同時(shí)使用多個(gè)監(jiān)控系統(tǒng)（云上的、云下的），導(dǎo)致監(jiān)控事件散落各處，人員維護(hù)多份，缺少了告警聚合降噪、排班協(xié)同的能力。我們團(tuán)隊(duì)做了9年開(kāi)源監(jiān)控系統(tǒng)，深知大家的痛點(diǎn)，特推出 FlashDuty 事件 OnCall 中心的產(chǎn)品，一站式解決告警難題（目前提供告警分發(fā)能力，告警引擎能力很快就到）。

• 產(chǎn)品介紹地址：https://flashcat.cloud/product/flashduty/
• 產(chǎn)品注冊(cè)體驗(yàn)：https://console.flashcat.cloud/

圖片

??? 中心化告警處理，在正確的時(shí)間通知正確的人

圖片

圖片

?? 每一分鐘都很關(guān)鍵，降低故障時(shí)間，就是賺錢(qián)

圖片

圖片

圖片

??? 您常用的監(jiān)控系統(tǒng)，我們都可以集成

圖片

告警事件的及時(shí)處理，對(duì)于線上穩(wěn)定性保障至關(guān)重要。一款中心式的告警事件 OnCall 中心，去除告警風(fēng)暴，確保告警不遺漏，還能分析故障處理的MTTA、MTTR等效率指標(biāo)，您的團(tuán)隊(duì)值得擁有，快來(lái)免費(fèi)體驗(yàn)起來(lái)吧：https://console.flashcat.cloud/。