從運維和SRE角度看監控分析平臺建設

運維和SRE團隊，承載著重要的職責，其工作內容複雜而廣泛，從應用部署、性能和可用性監控、告警、值班，到容量規劃、業務支撐等都有涉及。隨著雲原生、容器化和微服務的快速發展，迭代節奏愈發加快，對於運維和SRE也提出了更多的挑戰，以下幾個也是國內運維和SRE團隊面臨常見困境：

• 支持業務線廣

• • 業務線分佈廣泛，客戶端、前端web、應用後端
  • 同時支持幾個甚至數十條業務線

• 人力嚴重短缺

• • 相對開發人員，不少公司運維和SRE團隊人員不到1%，甚至更低

• 線上穩定性壓力大

• • 經常扮演"救火隊員"的角色
  • 業務複雜，組件眾多，快速排障和業務恢復的難度陡增

• 缺乏統一而有效監控分析平臺

• • 從不同的維度，對各類數據進行監控，腳本氾濫，工具縱多，煙囪林立
  • 各類數據落在不同的系統中，關聯分析欠缺，無法快速進行根因定位
  • 閾值告警缺乏靈活性，一個系統可能出現數千告警規則，管理成本高昂，也容易造成告警氾濫，引起誤判、漏判

因此，一套簡單易用、高效、分析能力強的監控分析平臺，對於提高運維和SRE工作效率，快速而準確進行根因定位，保證業務連續性至關重要。

監控分析平臺需要解決的數據問題

運維和SRE為了保證業務穩定和支持業務發展，需要對大量的數據進行收集和分析，從機器硬件、網絡指標到業務、用戶行為等多方面數據，在完成數據採集後，還需要有一套合適的系統進行轉換、存儲、處理、分析，滿足多樣的需求。數據問題主要包括：

• 數據多樣

• • 各類系統數據 ：cpu、mem、net、disk等通用硬件指標，系統syslog
  • 業務黃金指標：延時、流量、錯誤、飽和度
  • 業務訪問日誌 ：Access Log
  • 應用日誌 :  如Java應用日誌、錯誤日誌
  • 用戶行為數據：web click
  • App埋點數據：Android、IOS app中埋點統計
  • 各類框架數據：如被廣泛使用的k8s框架產生的數據
  • 服務調用鏈 ：各類Tracing數據

• 需求多樣
  對於收集的各類數據，運維和SRE團隊不光是為了保障業務穩定，還需要支持其他業務團隊進行數據的使用，對於數據的使用也是多樣的，常見需求如：

• • 監控、報警 ：實時處理（流式，小批量），秒級~分鐘級延時
  • 客服、問題排查：快速檢索，如通過關鍵詞過濾，秒級延時
  • 風控：實時流量處理，亞秒延時
  • 運營、分析：大規模數據分析，如OLAP場景，秒級到小時級延時

• 資源需求估算難
  對於快速發展的業務，各類數據的規模在一開始是很難準確估算的，經常遇到:

• • 新業務接入，數據量無準確估算參考
  • 業務快速發展，數據暴增
  • 數據使用需求變動，原有存儲方式，保存時間不符合使用需求

構建監控分析平臺方案選擇

由於數據來源廣、樣式雜，需求多，運維和SRE團隊往往需要使用和維護多套系統，組合使用，才能滿足多樣的監控和業務需求，常見的開源組合如：

• Telegraf+Influxdb+Grafana
  Telegraf是一個輕量級的採集框架，通過豐富插件對操作系統、數據庫、中間件等各類指標進行採集，配合Influxdb對時序數據進行高效讀寫、存儲、和query，最終可在grafana上進行可視化展示和交互式查詢
• Promethues
  在雲原生k8s的生態中， Prometheus基本上作為時序數據的標配，配合靈活的exporter可以非常方便完成Metric採集，同時Promethues也可以和Grafana集成
• ELK
  在日誌數據多維度查詢和分析上，ELK套件是最常用的開源組件，提供快速、靈活、強大的查詢能力，可滿足研發、運維、客服的大部分查詢需求
• Tracing  類
  在微服務、分佈式的系統中，請求調用鏈路複雜，沒有一套合適的Tracing系統，很難進行高效的問題根因定位，從最開始的Zipkin、Jeager到逐漸形成行業標準的OpenTelemetry，國內的SkyWalking都是不錯的Tracing 系統， 而這些Tracing並未提供數數據存儲組件，需要配合ES或者Cassandra來存儲Tracing數據
• Kafka + Flink
  對於數據清洗，風控等常見需求，需要構建一套實時數據通道和流式系統，支撐數據的全量實時消費，如普遍使用的kafka和flink的組合
• ClickHouse/Presto/Druid
  在運營分析，報表等場景，為了追求更高的實時響應性，通常還會將數據導入OLAP引擎，在秒級到分鐘級內完成海量數據分析需求，以及各類Adhoc的查詢

不同的組件面向不同的數據類型和處理需求，數據需要在其中進行流轉，有時候同一份數據需要同時保存在多個系統中，增加系統複雜度的同時，也增加了成本。

當數據越來越多，使用需求越來越廣的時候，保障這些組件的穩定性、滿足多種業務性能需求、進行有效的成本控制，又要對大量業務線進行高效支撐，都是非常繁重而又有挑戰的工作。

監控分析平臺的挑戰

能夠維護好多套系統，並有效支持眾多業務線，面臨的挑戰可不小，如：

• 穩定性保障

• • 依賴系統 : 數據在多套系統中流轉，系統之間又存在依賴關係，單某系統出現問題時，對其他系統造成影響，如下游ES系統寫入變慢後，用於緩存數據的Kafka集群存儲水位變高，可能導致集群寫滿；
  • Burst問題 ：在互聯網環境下，流量Burst是非常常見的情況，對於監控分析平臺也一樣，當大量數據需要寫入系統的時候，如何保證系統不被壓垮，同時保證讀取功能正常運轉，就非常有挑戰
  • 資源隔離：不同數據的優先級有高低，如果過分依賴資源物理隔離將導致集群資源嚴重浪費和運維成本極大提高，而當數據共享資源時，需要儘可能保證相互之間不受干擾，如某些系統中，一次超大規模的查詢，可能拖垮整個集群，這對於系統整體而言是不可接受的
  • 技術門檻：各類系統都有大量參數需要調優，面對不同的場景和需求，調優模式也不盡相同，需要投入大量的時間和精力，根據實際情況進行對比和優化

• 性能可預期

• • 數據規模:  數據規模對於系統的性能有非常大的影響，如時序數據在千萬~億級時間線下讀寫， ES在10億~100億行數中的查詢性能保證，都非常有挑戰
  • Qos控制：任意一個系統，硬件資源都是有限的，需要對不同數據的qps、併發進行合理的分配和管理，必要時進行降級處理，否則某個業務的使用可能導致其他業務性能受損，而這在開源組件中，一般都很少考慮

• 成本控制

• • 資源成本：各類組件的部署都需要消耗硬件資源，特別是當數據同時存在多個系統中的時候，硬件的資源消耗將更加嚴重;  另外一個常見問題是，業務往往很難準確對數據量進行估算，很多時候，會採用相對保守手段，來降低系統水位，這又造成資源浪費
  • 接入成本：支持各業務線數據接入也是一個繁重的工作，涉及到數據格式的適配、環境管理、配置設置和維護、資源的估算等一些列工作，需要有工具或平臺幫助業務線自主完成，否則運維和SRE將陷入大量的瑣事中
  • 支持成本：對各系統的使用，難免會遇到各類問題，必要的技術支持必不可缺，但問題種類多樣，如使用模式不合適、參數配置不合理等，也有遇到開源軟件本身bug導致的問題，這對於維護這些系統的運維和SRE來說，又是一筆額外的代價
  • 運維成本:  各系統的軟硬件難免會出故障，硬件替換、縮擴容、軟件版本升級，也需要投入不小的人力和精力
  • 費用分攤：只有地將資源消耗清晰準確分攤到實際業務線，運維和SRE，才能更有效利用資源，制定合理的預算和規劃。這也就需要能提供有效計量數據進行費用分攤。

從上面的挑戰來看，為了保證系統連續性和支撐好業務，運維和SRE團隊維護好多套系統，可並不是一個輕鬆的事。下面以某公司實際場景為例，看看實踐中可能遇到的問題和需要注意的內容。

實際場景模擬

業務背景 ：

• 公司有100多應用，每個應用有Nginx訪問日誌，以及Java應用服務日誌
• 各應用日誌規模變化巨大，從單日1GB到1TB不等，每天新增10TB數據，需保存7天至90天， 平均15天
• 日誌數據主要用於業務監控和報警、線上問題排查，以及實時風控使用

業務架構選型：

• Filebeats ：實時採集數據，發送至kafka
• Kafka : 數據臨時存儲，供實時Flink實時消費，和導入ES
• Flink : 對業務數據實時分析，進行實時監控、風控
• ES :  日誌查詢分析，問題排查

在以上看似最簡單和直白的架構中，也隱藏了大量細節需要關注，以ES為例：

• 容量規劃：原始數據 * 膨脹係數 *（1 + 副本數) * (1 + 預留空間) ， 一般膨脹係數取1.1 ~ 1.3， 1個副本，25%的預留（剩餘空間，臨時文件等）， 實際磁盤空間最終是原始空間的 2.75~3.5倍。如果需要開啟_all 參數設置的話，數據膨脹會更嚴重，也需要預留更多空間
• 冷熱分離：所有數據全部保留到SSD上成本會過高，需要根據數據的重要程度和時間因素，可以將部分Index直接保存至HDD磁盤，或使用Rollover功能將Index遷移
• Index設置 : 每個應用的2類日誌，分別按照時間週期性創建Index，根據數據大小合理設置shard數， 單shard以30~50GB為宜，但是各應用的日誌量很難準確估計，常在遇到寫入或查詢問題後再調整， 然而reindex的消耗又非常大
• Kafka消費設置：通常使用logstash消費kafka再寫入ES，需要kafka topic的patition數和logconsumer_threads相匹配，否則容易導致各partition消費不均
• ES參數調優：對寫入吞吐，可見性延時，數據安全性，以及查詢性能等多方面因素進行綜合評估和權衡後，結合集群CPU、內存，對ES一些列參數進行調優，才能更好發揮ES的特性，常見的參數包括線程數、內存控制、translog設置、隊列長度、各類操作間隔interval、merge參數等
• 內存問題：通常JVM 堆內存大小在32GB以內，剩餘的留個OS緩存使用，如果頻繁gc 會嚴重影響性能，甚至直接導致服務不可用。

• • master節點內存佔用和集群中shard數直接相關，一般集群shard需要控制在10W以內，ES默認配置中，單節點shard數上限為1000，需要合理控制index和shard數量
  • data節點的內存由索引數據規模決定，如ES的FST會長期駐留在內存，雖然在7.3及之後版本中，提供了堆外內存方式（mmap)，但緩存被系統回收又會導致查詢性能下降，如果使用的是更低版本，則只能控制單節點數據大小；

• 查詢問題：影響查詢性能的因素非常多，需要花費大量時間不斷試錯和積累，常見的如：

• • 合理設置mapping，如text和keyword的選擇，儘量避免無必要的nested mapping
  • 避免過大的查詢範圍和複雜度（過深的group by等），以免急劇消耗系統資源；對結果集大小進行限制，否則複雜的聚合查詢或模糊查詢等，在過大數據集上甚至直接導致oom
  • 控制segment數量，必要時進行force merge，也需要評估好force merge帶來的大量IO和資源消耗
  • filter和query的合理選擇，在無需計算得分場景下，filter可以更好使用query cache，速度要明顯快於query
  • script 腳本帶來的性能和穩定性問題
  • 合理使用好routing可以使得單次查詢只掃描某個shard數據，提升性能

• 數據損壞：如果遇到異常的crash，可能導致文件損壞，在segment或translog文件受損時，shard可能無法加載，需要使用工具或手動將有問題的數據清理掉，但這也會導致部分數據丟失

以上是在使用和運維ES集群中，經常會遇到和需要注意的問題，穩定維護好ES集群可真不是一件容易的事情，特別是當數據逐步擴大到數百TB，又有大量使用需求的情況下。同樣的問題也存在其他系統中，這對於平時工作極其繁忙的運維和SRE同學是不小的負擔。

雲上一體化服務選擇

針對運維和SRE工作中對於監控分析平臺的需求，以及平臺搭建過程中遇到的種種問題， 阿里雲SLS團隊希望在雲上提供一套簡單易用、穩定可靠、高性能而又具有良好性價比的解決方案，以支持運維和SRE更高效地工作。SLS從原本只支持阿里+螞蟻的內部日誌系統開始，逐步完善，演進成為同時支持Log、Metric、Tracing的PB級雲原生觀測分析平臺：

• 極其簡便接入

• • Logtail : 多年百萬級服務器錘鍊，簡便、可靠、高性能，web端可視化管理
  • SDK/Producer : 各類移動端 java/c/go/ios/android/web tracking接入
  • 雲原生 ：雲上ACS原生支持，自建CRD一鍵接入

• 實時消費和生態對接

• • 秒級擴容能力，支持PB級數據實時寫入和消費
  • 原生支持flink/storm/spark streaming等主流系統

• 海量數據查詢分析力

• • 百億規模秒級查詢
  • 支持SQL92、交互式查詢、機器學習、安全特色函數

• 數據加工

• • 先比傳統ETL，可節省90%的開發代價
  • 純託管、高可用、高彈性擴展

• Metric 時序數據

• • 雲原生Metric接入，支持億級時間線的Prometheus存儲

• 統一的Tracing方案

• • 完美支持OpenTelemetry協議，兼容Jaeger、Zipkin等OpenTracing協議、OpenCensus、SkyWalking等方案

• 完善的監控和報警

• • 站式完成告警監控、降噪、事務管理、通知分派

• 異常智能診斷

• • 高效的無監督流式診斷和人工打標反饋機制，大大提高了監控效率很準確率

相比開源多套系統的方案， SLS採用了All in one的模式，在一個系統中，完整支持了運維和SRE工作中對於監控分析平臺的需求，可以直接替代搭建kafka、ES、Prometheus、OLAP等多套系統的組合，這樣帶來了明顯的好處：

• 運維複雜度

• • 雲上服務，開箱即用，0運維成本，無需再維護和調優多套系統
  • 可視化管理，5分鐘完成接入，業務支持代價大大降低

• 成本優化

• • 數據只保留一份，無需將數據在多套系統中流轉
  • 按量使用，無預留資源的浪費
  • 提供完善的技術支持，人力成本大大降低

• 資源權限管理

• • 提供完整的消費數據，助力完成內部分賬和成本優化

1. 1. 完整的權限控制和資源隔離，避免重要信息洩露

SLS 希望通過自身的不斷進步，為Log/Metric/Trace等數據提供大規模、低成本、實時平臺化服務，助力運維和SRE更高效工作，更有效支持業務快速發展。