降本30%、提效200%！解密星巴克日志平臺的極致升級優化之道

作者 | 星巴克中國技術部日志平臺團隊

星巴克中國技術部日志平臺團隊經過近 1 年的日志集群遷移和升級，將維護支持星巴克中國的日志平臺多個日志集群，數 PB 的數據，從 ES 版本從 7.8.X、7.9.X 跨大版本無縫升級至 8.X，從虛擬機架構部署模式遷移至云原生祼金屬 k8s 平臺部署模式。完成日志平臺組件升級的過程中，也完成了日志平臺的架構升級。從開始計劃到執行完成，中間也遇到了很多的阻力和問題，經過團隊技術攻堅，跨團隊配合，新資源支持等方式解決了相關困難，完成之后我們回顧一路走來的付出和成就，確實有很多值得思考的地方，分享出來供大家參考。

2024 年 9 月開始計劃，在不改變用戶查詢和提升用戶體驗的前提下，到 2025 年 6 月完成所有日志平臺組件架構升級和版本遷移，在這中間的過程中，經歷了 mapping 不兼容，字段類型沖突，查詢上下文失效，重復消費誤告警等諸多業內普遍存在的難題，最終實現了單機查詢性能提升 80%，整體 cpu 下降 30%，寫入 tps 提升 200%，用戶也明顯感覺到了查詢性能提升帶來的快感，本次分享從以下幾個方面進行展開。

背 景

在數字化業務高速發展的當下，日志作為系統運行狀態的 “全景鏡像”，承載著業務監控、故障排查、安全審計、數據分析等核心場景需求，星巴克日志平臺從 2017 年開始建設以來，存在一些架構設計不合理，日志查詢緩慢，超時，丟日志等情況，用戶體驗不好。傳統架構下的日志平臺逐漸暴露出性能瓶頸：查詢延遲超 10 秒、存儲成本年增長率達 30%、跨集群數據協同效率低，難以滿足業務對 “實時性”“低成本”“高可用” 的訴求。為此，技術團隊啟動全方位升級優化，通過架構重構、引擎升級、智能調度等手段，實現平臺從 “能用” 到 “好用” 的跨越，為萬億級數據場景下的日志服務樹立新標桿。

自 2024 年以來，日志平臺團隊開始逐步接手相關的平臺建設工作，從日志采集組件（filebeat），日志接收（logstash producer）, kafka , 日志消費組件（logstash consumer）, ES 集群，數據存儲模式，日志查詢組件（kibana）,ES 多集群查詢組件（CCS）等層面進行了逐個優化，下圖為日志集群沒有優化之前的架構模式圖：

此架構存在以下問題：

1. ES 集群依賴遠程網絡存儲，寫入能力受到遠程存儲 io 資源限制，當時的數據量場景下，存儲 io 帶寬已經處于滿載運行的狀態，且擴容麻煩周期較長；

2. logstash-producer 和 logstash-consumer 單節點處理能力有限，兩者占用了大量的計算資源，需進行優化或者技術演進，以提高效率和節約計算資源

3. 遠程存儲容量即將達到安全線內使用上限，如果不進行優化，無法承接更多的業務日志接入，用戶體驗也經常收到業務反饋查詢超時，日志延遲等投訴建議

各組件都是虛擬機部署，運維成本高，集群的可觀測性，穩定性得不到保證。

在穩定性方面，因歷史原因日志數據的數據清洗和存儲方面沒有最佳實踐，沒有合理的索引的模版結構和生命周期管理，索引分片和大小配置也沒經過合理的優化，這樣造成了數據查詢超時，甚至部分節點內存溢出，資源使用傾斜情況等，用戶體驗非常不好。其次，存儲使用的是遠程網絡存儲，受遠程存儲性能的限制，造成 ES 集群寫入和查詢的資源受限，經常出現數據堆積，ES 查詢隊列居高不下，查詢緩慢的情況；

基于以上原因，日志平臺技術伙伴從技術層面和成本管理層面來考慮，經過團隊對現有硬件資源情況，日志每天增量情況，早晚高峰期流量情況等方面的評估，在同等硬件資源的情況下，進行日志平臺技術架構升級,，能夠讓日志的查詢效率，日志高峰流量寫入得到顯著提升，可以緩解高峰時日志寫入延遲，提高 ES 的寫入能力方面等到優化，因此日志平臺伙伴對日志平臺進行了升級改造。

計劃目標及面臨的挑戰

目標

日志平臺伙伴根據實際的技術調研，跨團隊配合情況，設定了詳細的日志平臺升級計劃，保障每個關鍵節點實現相關里程碑成就，主要包括以下幾點：

1. 所有日志涉及的環境組件統一都遷移至云原生祼金屬 k8s 平臺引擎之上，即：日志平臺涉及到的所有組件都需要容器化部署。

2. 統一日志平臺各組件的運行版本和交付標準, 實現日志數據采集、日志規則解析，數據入庫等流程化體系建設。

3. 資源分配合理化使用，對不同索引根據流量大小，高峰流量情況，業務活動情況，從采集，接入，解析，存儲進行資源的精細化控制。

4. 提升日志平臺的接入能力，保證業務高峰期及活動保障期間不會有數據堆積和丟失情況。

5. 提升用戶數據查詢服務體驗，目標是 p99 查詢 < 5s，改善用戶對日志平臺一些不好的看法。

日志平臺改造架構圖如下：

與此前架構設計相比，本架構所具有的優勢為：

1. 所有組件都是容器化部署，運維相對簡單，由之前在虛擬機上部署組件變為 operator 快速制備 pod, 組件交付效率提升 90% 以上；

2. producer 和 consumer 的組件由之前的 logstash 替換為 vector, 同等硬件資源下數據處理能力提升 2 倍以上；

3. ES 集群采用冷熱角色部署，熱節點使用本地磁盤，提高查詢和存儲速率，冷盤使用遠程網絡存儲，可以最大程度使用已有資源，節約存儲采購成本；

4. 計算資源可以集中化管理和調度，提升資源利用率的同步，也使用資源可以快速的支持需要重保的組件；

挑戰

如何保障用戶體驗？

在實際的集群升級過程中是不允許有數據丟失情況的，包括歷史數據及新接入數據，用戶查詢界面也不能更換，即要在一個界面上進行新舊集群的日志查詢，不能出現新集群數據在新界面查詢，舊集群數據在舊界面查詢的情況，另外，當時日志查詢經常超時，用戶經常反饋日志平臺查詢不到數據，查詢緩慢，平臺難用的情況，如何優化用戶體驗成為了日志平臺伙伴面臨的一個非常棘手的挑戰。

如何解決數據積壓問題？

遠程網絡存儲 io 帶寬已經達到寫入瓶頸，io 帶寬資源支持最高 4Gb/s, 但是高峰期已經超過這個流量，直接制約了 ES 集群的寫入能力，這也是造成日志經常堆積，日志數據延遲的主要原因。

如何提升單個消費節點的寫入能力？

消費組件 logstash-consumer 的規則解析比較多，單個節點的平均寫入大約 1w/s 左右，而且單個節點占用資源為 32c 64g 的配置，涉及到大量的規則解析，所以性能受到嚴重影響，流量高峰期間需要啟動大量消費節點進行數據寫入，是日志集群除 ES 節點外最大的資源消耗組件，如何提升單個節點的寫入能力，降低資源消耗成為技術伙伴攻關的主要挑戰。

如何提升集群的存儲能力？

集群硬件存儲資源總共數 PB 左右，但是當時日志增量為每天百 TB 左右，日志保留時長一般為 30 天，有些業務日志由于業務原因需要保留 60 天或者 90 天，所以存儲資源當時已經處于飽和的狀態，總共數據量達到萬億級別，所以如何在不增加存儲容量的情況下進行存儲資源的優化，也是技術伙伴面臨的重大挑戰。

如何解決業務日志接入流程長的問題？

之前業務日志接入是按照業務組件名稱，要從采集側開始配置，再手動配置生產者，kafka 的 topic, 消費者及寫入的索引名稱，分片數量，查詢別名及索引生命周期管理等，這一套流程手動操作下來要 2 小時左右，這也是在伙伴對流程比較熟練的情況下，但是我們接收到的新的日志接入每天大概 3-4 個，消耗在日志接入方面的人力成本非常多，如何優化日志接入流程成為了平臺伙伴需要面臨的挑戰。

以上為主要面臨的挑戰，還有一些比如：業務組件如何對應索引名稱和管理？人力資源有限的情況下，如何進行多集群的高效運維和管理？面對組件容器化之后，針對 ES 節點，kafka 節點等有狀態節點出現故障之后如何快速恢復？集群各組件的可觀測能力，告警能力，故障自動恢復能力等等，都是在集群升級過程中要面臨的問題和挑戰。

執行步驟

在開始實施前，我們按照以上問題的優先級進行了執行步驟的制定，對每個步驟的實施方案，期望達到的效果及預計的完成時間進行了詳細的技術討論，拆分如下：

遷移過程中如何保障用戶體驗

實施方案：

• 通過 ES 集群中的 ccs（Cross-Cluster-Search）的角色，可以實現 kibana 跨 ES 集群日志查詢，由于資源的限制，新的中轉集群開始只有 9 臺物理節點，需要通過騰挪的方式，把舊集群的物理機逐步釋放，再添加到新集群的方式完成硬件資源的遷移，由于初始的集群資源較少，所以遷移只能按照索引級別逐個遷移，涉及 200 多個索引，所以遷移周期比較長, ccs 支持多 ES 集群查詢流程如下圖：

• 但是新集群仍然面臨寫入遠程帶寬受限的問題，所以團隊經過技術評估，決定新的 ES 集群使用本地盤 + 遠程存儲的方式，即在新集群中 hot 節點數據使用本地盤，數據保留時間為 7 天，cold 節點使用遠程存儲的方式，數據為 7 天之后 hot 節點遷移過來的數量，繼續保存 23 天，以解決遠程存儲帶寬受限及 ES 寫入性能不足的問題, 新集群的所有組件均在 k8s 平臺基于容器化部署的方式交付，本地盤通過 local storage 的方式掛載給到 ES 的 pod 使用。

預期效果：

• 用戶在原有 kibana 平臺可以通過索引別名的方式查詢新舊集群的數據，新集群的 hot 節點數據查詢明顯變快，因為新集群的 hot 節點使用的是本地 nvme 存儲，寫入和查詢的速率較快。

• 新集群的 ES 單個節點的寫入性能明顯提升，7 天內的數據查詢 p99 < 5 s, 新集群解決了數據寫入和用戶查詢體驗的問題。

使用本地磁盤代替遠程網絡存儲的收益如下：

在單節點的性能優化中，我們主要優化了以下幾個方面：

• 磁盤調度器根據硬盤硬件能力使用 noop 調度器或者 mq- deadline 調度器；

• 磁盤隊列深度擴大數倍，以很好利用超大內存 JVM；

• 磁盤臟頁比例和回寫比例優化，減少頻繁 IO 次數，提升吞吐量；

下圖是單個物理機在 20w/eps 時的 iostat 性能圖

從上圖可以看出，使用本地磁盤存儲代替遠程存儲，磁盤 io 性能得到了指數級提升。

如何解決數據積壓問題

實施方案：

經過團隊內部仔細梳理，發現在業務高峰期導致日志積壓的因素有多種，具體歸納如下：

• 個別組件日志量瞬間太大，最高單個 topic 可達 15w/s，導致其它的索引寫入和查詢變慢

• 生產者發送 kafka 單條業務日志太大，占用較多的帶寬資源

• kafka 對應 topic 的 partition 的數量設置不合理，沒有根據實際的數據量評估單個 partition 可以承載的流量

• logstash-consumer 消費線程數量設置不合理，造成有些線程空輪詢，有些線程繁忙的情況，表現總體消費能力持續的忽高忽低，消費能力很不穩定

• 索引的 shards 的數量設置不合理，建議單個 shards 的存儲容量最高在 20-40GB 之間，但實際的情況是單個 shards 的數量達到 TB 級別，并且部分索引沒有滾動策略，造成 shards 存儲越來越大，直接影響了數據的查詢和故障時索引的恢復時間

• ES 寫入線程數據及資源分配也不合理，對于部分集群冷熱節點的資源沒有合理規劃，造成熱節點在寫入高峰期 cpu 資源不足，經常出現 cpu 打滿，ES 寫入隊列居高不下的情況，影響 ES 的寫入性能。

針對以上發現的問題，團隊在進行集群遷移升級的過程，對集群的吞吐能力從不同組件的緯度進行了優化，具體實施步驟如下：

• 對采集側發送到 logstash-procuder 的大流量業務日志數據進行采樣策略，即按照百分比丟棄，這個可以 logstash-producer 邏輯里面實現，和業務溝通高峰流量日志會有單條日志被放大 7-10 倍的情況，即一條數據在同一個組件內部或者跨組件過程中，由于不同的邏輯處理被多次打印的情況，所以部分日志進行采樣收集不影響業務排查問題。

• 對于單條日志過大的情況（單條業務日志大于 10MB）， 在 logstash-producer 中進行過濾攔截，并通知業務整改，這種單條數據量過大的日志收集沒有實際的意義，因為 kibana 也查詢不出來，浪費集群的計算和存儲資源。

• 對于 kafka 中相關 topic 的 partiton 數量設置不合理，logstash-consumer 的線程數設置不合理，ES 的寫入線程設置不合理，索引的 shards 數量設置不合理的情況，在實際的操作過程中通過壓測找到合適的參數匹配關系，合理的利用集群的計算資源，比如針對大流量業務組件，如果 topic 的 partition 數量設置為 80， 如果單個 consumer 的 worker 線程數量設置為 10，那么最多只需要啟動 8 個消費者節點就可以，因為單個 partiton 同一時間只能有一個消費者線程消費，諸如此類的細節的優化措施在實施過程中對集群的吞吐能力提升很大, 相關組件的參數調整及說明如下：

kafka 集群設置：

topic 分區設置規則：針對業務應用日志量大的 topic 分區：設置 45 個 (9 個 kakfa 節點，保證是 9 的倍數)，日志 topic 默認分區設置：9 個

kafka 參數主要參考批次大小，參數過大，導致 cpu，內存異常告警，設置過小導致 filebeat 事件活躍數高，日志寫入延遲。

message.max.bytes: 41943040

vector 寫入 ES 參數設置：

主要針對日志量大的業務，減少日志寫入提交頻次，降低 ES 寫入隊列：

batch:

compression: "zstd"

ES 索引模版參數優化設置：

"routing": { "total_shards_per_node": "1" }

• 對于索引 shards 中存儲數據比較大的情況，給索引設置合理的 shards 數量，shards 數量過多會占用更多的 ES 內存資源，過少會導致存儲過大和寫入性能問題，所以在實施過程中對每個索引進行了 shards 數量的優化，段合并優化，合理規劃 shards 數量，制定索引的生產周期管理策略，在 shards 存儲到達一定的水位之后自動滾動生成新索引，保證數據寫入速率的同時，控制索引的存儲容量。

預期效果：

• 通過限流的手段保障即使在流量高峰，也不會因為單個業務的日志量大拖垮集群的情況，從而緩解了流量高峰期日志查詢緩慢，用戶體驗差的情況，通過對單條日志過大的治理，釋放了集群的帶寬和計算資源，為集群可以承載更多的流量提供了資源條件

• 通過對 kafka, logstash-consumer,es 等相關參數的優化，提升了 ES 的集群的數據吞吐能力，降低了日志在流量高峰期間出現頻繁積壓和延遲的情況，提升了集群的穩定性

• 通過對索引 shards 數量和存儲容量的優化，提升了 ES 集群的寫入能力，縮短了集群出現故障或者節點維護需要重啟 ES 節點時的索引分片恢復的時間，進而保障了集群的可用性能力

如何提升單個消費節點的寫入能力

實施方案：

在 ELK 的架構體系中，logstash 組件扮演著數據管道的角色，把數據從 filebeat 寫入 kafka, 再把數據從 kafka 經過解析或者清洗寫入 ES, 這種組件集群的方式在業界使用非常廣泛，但是 logstash 是 java 實現，在進行大數據量處理時經常需要占用更多的 cpu 和內存資源，日志平臺總資源只有數十臺物理機，平臺提供給 logstash 的計算資源達到 10 臺，一半以上的計算資源被鎖在 logstash-producer 及 logstash-consumer 上，其實也沒有存在資源浪費的情況，只是數據處理的性能低下，1 個 32c64g 的生產者可以每秒發送 3-4w 條數據到 kafka, 而消費者的處理和寫入能力也只有 1w/s, 因為要處理大量的日志數據字段解析，所以性能比不上生產者 結合以上情況，團隊伙伴決定做技術演進，在技術調研的過程中，新興組件 vector 進入了我們的視野，據官方壓測數據，其性能是 logstash 的數倍以上，所以我們決定引入 vector 取代 logstash 組件作為集群中的管道組件，具體實施步驟如下：

• 把 logstash-consumer 先替換為 vector, 此過程要解決的問題就是解析規則的遷移和兼容性測試，消費者需要處理的解析規則大概有 3000 多條，都是根據實際的業務需求作的日志數據字段解析，方便業務伙伴檢索從而快速排查和定位生產問題，由于規則解析的多樣性，遷移過程中還要保障解析規則的正確性，團隊伙伴在規則驗證方面投入了很多精力，也沉淀了一些規則遷移和驗證的工具，保證了規則遷移的完整性和數據正確性。

• 根據業務重要性及日志數據的大小對對所有消費的 topic 進行了分組消費，示意圖如下：

從上圖可以看出，在每一組內如果消費堆積，不會影響其它組的消費，只需要解決堆積的那個組的問題就可以，也可以對重點保障的業務所在的組投入更多的消費資源，做到了消費資源的精細化控制，也可以在活動期間對活動涉及到的業務組進行重點保障工作。

• logstash-producer 替換為 vector, 因為生產者不涉及規則解析，只承擔了數據轉發和限流的功能，所以此部分的替換工作相對簡單，但是 vector 本身的一些參數設置會影響其投遞到 kafka 的速率，實際的替換過程中團隊伙伴也是沉淀一些參數配置的最佳實踐。

預期效果：

• 通過 vector 組件的引入及日志數據解析規則的遷移，在同等 cpu 和內存資源配置下，單個生產者的寫入速率最高可達 10w/s, 比 logstash-producer 提升 3-4 倍，資源節約近 50%，同時生產者的限流能力也得到了平滑的遷移， 單個消費者消費和寫入 ES 能力提升到 3-5w/s, 比 logstash-consumer 提升 2-3 倍，資源節約 60% 左右，為集群支持日志數量增長提供了資源支持

• 分組消費的優化也把堆積影響范圍進一步縮小，使問題影響面變得更加可控和可快速定位及處理，方便了活動日的集群穩定性保障，由于每個組內的消費者節點數量都可以單獨控制，極大方便了計算資源的動態調度，保障了集群的穩定。

如何提升集群的存儲能力

實施方案：

日志集群的總存儲資源在團隊接手管理時存儲容量已經使用 85% 以上，而且每天不斷有新增的業務組件需要接入日志集群，在存儲硬件資源受限的情況，在業務日志保存時長不受影響的情況下，如何對現有的存儲邏輯進行優化，釋放更多的存儲空間，進而承接更多的業務日志接入也成為了團隊需要亟待解決的問題，經過團隊伙伴的共同努力，發現可以進行存儲優化的點有兩處：

• kafka 存儲優化，kafka 的存儲數據沒有進行壓縮設置，單個集群內有 9 個 kafka 節點，同時 kafka 對數據有副本機制保障高可用，所以在保證磁盤使用率控制在 80% 以下的情況下，kafka 可以保存的時長只有 4 個小時，這個時間要求團隊伙伴如果在集群出現問題時，處理和恢復時間不能超過 4 個小時，否則數據丟失風險很大。

• ES 集群對索引存儲沒有開啟壓縮算法，據了解，這里主要原因是開啟壓縮會占用更多的 cpu 資源，集群本來資源就非常有限，處理數據寫入已經占用了大量的資源，經常會有寫入堆積，還開啟壓縮功能就會適得其反，影響集群吞吐，ES7.9.x 版本開啟 gzip 壓縮可以壓縮 30% 左右，但是新版本的 ES8.x 支持 zstd 壓縮，壓縮比可達 40% 左右，但是，想要開啟 ES 數據壓縮能力，就必需提升 ES 的吞吐保證不會積壓的同步，提供更多的計算資源給到 ES 集群，針對以上兩點，團隊伙伴進行了如下的實施方案：

• 對 kafka 進行存儲優化，首先，對不再使用的 topic 進行清理，對流量小的 topic 進行合并。其次，對 kafka 數據落盤進行壓縮，減少磁盤空間的占用，對日志的存儲時長進行延長，保證在集群出現問題時有足夠和時間處理，不會出現因集群故障，kafka 日志過期導致數據丟失的情況。

• 對 ES 集群進行壓縮算法開啟，在上面的 logstash -> vector 的組件演進過程中已經提升了 ES 集群的吞吐量，釋放了足夠的硬件資源，可以支持 ES 集群開啟壓縮能力，至此，集群資源利用出現了正向循環，首先對舊的 7.9.x 的版本直接開啟 gzip 壓縮，對新集群開啟 zstd 壓縮。

預期效果：

• 通過對 kafka 集群的治理和優化，kafka 集群在存儲容量不變的情況下，數據保留時間由之前的 4 小時延長到了 8 小時，數據壓縮效率明顯，數據存儲容量下降 50%，為集群的故障處理爭取到了更多的處理時間，但實際情況是故障恢復也沒有出現處理過長時間的情況，但是承接了更多的業務日志接入，在沒有增加硬件資源的情況下，kafka 層面解決了日志增長對存儲壓力的問題。

• 通過對新舊 ES 集群開啟壓縮算法，舊集群存儲容量減少了 30%， 新集群的容量減少了近 50%，整體存儲容量下降了 40%， 在不斷的新增業務日志接入的情況下，取得了預期存儲治理的目的，為后面可以承接更多的新境日志接入騰出了足夠的存儲空間，節約了公司存儲資源采購的成本。

下表是使用不同 ES 版本索引同一份數據的存儲空間測試對比：

從表中數據可以看出，開啟壓縮前后在不同的 ES 版本中存儲容量均有明顯下降。

如何解決業務日志接入流程長的問題

實施方案：

日志接入從應用到 ES 需要經過多個組件，涉及到業務應用跟 topic 映射配置，topic 跟日志索引映射配置，針對不同的應用日志需要設置單獨的索引生命周期，分片數，索引模版以及查詢模版。整個日志接入流程下來，需要大概花費耗時 2 小時。原來整體日志接入流程如下：

在經過日志索引規范治理后，團隊對日志接入流程進行了分析以及流程優化，基本能實現日志流程接入自動化。實施步驟如下：

• 業務應用上線提交工單申請，在工單提供集群，應用分區，應用名稱，日志保存時長等信息。工單審批通過后訂閱 ELK 系統接口，將參數傳到 ELK 平臺。

• ELK 平臺接收到應用上線信息，通過應用分區，應用名稱自動生成 topic 名稱，topic 生成規則：prod-container_ 應用分區。將生成的配置更新業務應用 topic 映射表，vector 生產端定時更新配置寫入 topic。

• vector 消費端，腳本讀取業務應用 topic 映射表，判斷是否有新生成的 topic，有的話將生成的 topic 跟索引配置更新到 vector 消費配置里面，且調用 ES 接口創建新索引模版，初始化新索引。vector 消費端定時更新配置寫入 ES 集群。

• 調用 ES 接口，判斷是否有新初始化的索引，如果有，調用 kibana 接口創建查詢索引。

預期效果：

• 人工操作時間：單個應用服務從 2 小時 → 5 分鐘（無人值守）

• 接入應用量：單批次支持多個應用同時接入, 減少人工一個個應用接入。

• 配置一致性：避免人工錯誤。

成果與體會

成果總結：

經過 3 個月的升級與驗證，日志平臺的性能、成本、可用性均實現顯著突破，核心指標如下：

• 用戶查詢 P99 < 5s，極大的改善了業務團隊對日志平臺之前體驗不好的印象，查詢超時問題，日志延遲問題，日志丟失問題等用戶體驗相關問題得到了很好的解決

• 集群吞吐能力得到的增強，由之前的 45w/s 提升到 90w/s, 吞吐能力提升近 3 倍，滿足當前日志平臺高峰期流量寫入，很少再出現日志積壓和消費延遲的情況；

• 存儲壓縮能力提升了 50%，容量降低了 50% 左右，較大的節省了硬件資源成本。

• 集群穩定性得到極大提升，之前只要是早晚業務高峰，集群就會有問題，積壓問題，存儲問題等等，由于可觀測和告警能力的建設完成，穩定性的問題也很少出現，給業務伙伴排障提供了很好的支持。

體會與感悟：

• 日志系統升級初期面臨諸多問題，業務所有告警策略全部都是通過查詢日志索引，稍有考慮不到地方就可能會引起大量誤告警，給日志升級方案設計帶來了很大的挑戰，同時還要兼顧業務訴求，平臺使用無感，數據不能丟失等，需要考慮諸多因素，團隊伙伴在保障日志平臺平滑升級過程中付出了諸多努力。

• 因為星巴克的業務場景原因，日志平臺所有的升級動作都必須要在晚上 10：00 以后進行，不能影響正常白天業務日志的查詢，為此，團隊伙伴經常作業到凌晨以后，現在回頭再看，正是團隊伙伴兢兢業業的奉獻，才能使日志平臺升級工作順利完成，正是團隊伙伴熬過的每一個夜晚，才換來了業務伙伴對日志平臺體驗提升的一次次肯定。

• 日志平臺是一個多組件構成的復雜系統，升級優化需要考慮每個組件在流程中的貢獻和作用，以及可能的優化空間，各組件的參數使用需要上下游連動，全流程優化也需要考慮整個系統的木板效應，過程復雜且具有挑戰性，只有堅實的做好每一項的優化，才能得到整個系統的性能提升。

未來發展規劃

• 架構優化降本增效：依托全自動化日志接入流程的技術，推動采集層架構升級，實現 filebeat 采集器結合 CMDB 自動路由寫入 Kafka 消息隊列的閉環鏈路，精簡現有架構中 logstash 與 vector 生產者的中轉環節，顯著降低計算資源占用率，進一步優化平臺整體運營成本。

• 生態化整合：打通日志平臺與 APM、監控平臺的數據壁壘，構建 “日志 - 監控 - 告警” 一體化運維體系，實現從 “被動排查” 到 “主動預防” 的轉型。

• 智能搜索深化：引入大語言模型（LLM），支持自然語言查詢日志（如 “查詢今日 dpfm 接口錯誤日志”），降低業務人員使用門檻。