從運維和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更高效工作，更有效支援業務快速發展。