再次升級-Kubernetes Ingress監控進入智能時代

Kubernetes的門戶-Ingress

目前Kubernetes(K8s)已經真正地佔領了容器編排市場,是默認的雲無關計算抽象,愈來愈多的企業開始將服務構建在K8s集羣上。在K8s中,組件經過Service對外暴露服務,常見的包括NodePort、LoadBalancer、Ingress等。其中Ingress主要提供HTTP層(7層)路由功能,相比TCP(4層)的負載均衡具有很是多的優點(路由規則更加靈活、支持金絲雀、藍綠、A/B Test發佈模式、SSL支持、日誌、監控、支持自定義擴展等),是目前K8s中HTTP/HTTPS服務的主流暴露方式。html

image.png

Ingress提供的7層負載均衡具備很是強大的能力,例如:算法

  • 會話保持:讓相同的session ID路由到同一臺後端機器,保證每一個用戶的會話只在一臺機器上處理。
  • 基於內容的轉發:可以根據HTTP協議內容進行轉發,例如Host、URL甚至是PostBody等。
  • 重寫請求:可以對用戶的請求進行動態修改,很是適用於新老系統的兼容性改造。
  • 加密:在負載均衡上配置SSL,提供統一的證書管理,每一個服務器無需單獨維護證書。
  • 健康檢查加強:可基於業務規則進行健康檢查,而不只僅是判斷端口連通性,使健康檢查更加精確。
  • 日誌監控:全量7層訪問日誌,可以獲取每一個請求的結果、耗時、請求大小等信息,可以基於訪問日誌監控到每一個服務的質量。

Ingress日誌分析與監控

原始的訪問日誌記錄了網站的每一個訪問請求,每一個請求包括用戶地址、Host、URL、狀態碼、耗時、請求大小等多個維度的信息,基於訪問日誌能夠統計出不一樣維度下的訪問qps、成功率、延遲等黃金指標,以此實現能夠針對各類維度的網站質量監控。但構建一套完整的訪問日誌分析系統仍是很是困難,這其中包括了不少過程和工做:採集、存儲、分析、可視化、告警等。在實施過程當中最爲複雜的點在於:後端

  • 採集問題:如何保證日誌採集的可靠性、性能消耗、延時問題;
  • 分析:在保證分析靈活性的同時可以保持快速的分析、查詢速度以及較低的實施成本;
  • 自動化:尤爲在業務規模比較大的狀況下,如何智能的監控和分析各個服務的狀態是一個迫切須要的功能。

image.png
爲簡化廣大用戶對於Ingress日誌分析與監控的門檻,阿里雲容器服務和日誌服務將Ingress日誌打通(官方文檔),只須要應用一個yaml資源便可完成日誌採集、分析、可視化等一整套Ingress日誌方案的部署。
這套系統主要包括:服務器

  1. 日誌實時採集方式:經過Logtail實時採集Ingress產生的輸出日誌,並進行格式轉換
  2. 存儲:SLS提供負載均衡的實時隊列用於日誌的存儲,並提供按照TTL的存儲方式,可任意設置保存的日誌天數。
  3. 查詢/分析:基於SLS提供的SQL92語法可實現對Ingress日誌各個維度的交互式分析與計算,例如統計UV變化,訪問請求分佈,TOP延遲等。
  4. 可視化大盤:將常見的監控、分析場景需求以圖表的形式固化成大盤,用戶絕大部分時間只須要查看大盤便可瞭解整個系統的狀態。

再次升級-從1.0到2.0

image.png

Ingress日誌分析與監控的方案已經發布2年左右,目前已經有上萬的實例使用了該方案。在長期的使用中,咱們也發現了這套方案的一些限制,爲了適應新時代的DevOps節奏,咱們須要對方案進行總體的升級,提供更加簡單、更快速、更普惠、更智能的Ingress日誌監控方案。網絡

  1. 更簡單:整個方案用戶的使用更加簡單,不須要去關注SLS的相關的資源,能夠直接以單獨Ingress監控APP的方式使用;
  2. 更快速:1.0的方案基於原始訪問日誌實時計算,在時間跨度較大或日誌量較大的狀況下查詢速度較慢,使用體驗較差;
  3. 更普惠:因爲計算依賴原始日誌,因此必須將日誌長期保存,原始日誌的存儲量較高,會產生較高的費用;
  4. 更智能:隨着K8s集羣中運行服務數量的增長,傳統的監控方式愈來愈吃力,依賴靜態指標的告警規則很難監控全部的異常,所以急需更加智能的AIOps能力來解放生產力。

方案架構

image.png
爲了達到高性能、低成本、快速、智能等要求,SLS和阿里雲容器服務團隊聯合對Ingress日誌監控方案進行了一次架構升級,正式發佈了2.0版本的Ingress日誌中心,日誌中心包括如下幾個部分:session

  1. 原始訪問日誌存儲:當Ingress Controller產生訪問請求後,會實時將請求的訪問日誌推送到用戶自身的Logstore中,整個過程的延遲通常在3-5秒便可完成,SLS的Logstore具有高可靠、實時索引、自動擴容等功能,保證日誌的可靠性和可擴展性。
  2. 預聚和:因爲原始訪問日誌量巨大,基於原始日誌計算指標性能開銷較大,所以SLS專門推出了基於訪問日誌的指標預聚和能力,可以將上百萬甚至上億的訪問日誌實時聚合成指標類型的時序數據,數據量會下降1-2個數量級,後續的分析與監控可直接基於時序數據進行,大大提升效率。
  3. 智能巡檢:對於預聚和後的Metrics(指標數據),SLS提供了機器學習的自動巡檢功能,幫助用戶自動去檢測各個Ingress的各個維度的指標異常,將異常信息實時展示在時序的圖表中,結合實時告警能力進行自動的告警配置。此外後續還會支持異常打標,基於用戶反饋的信息進行更加精確的檢測。

經過以上3層數據鏈路,實現了從原始訪問日誌到預聚和的指標最後再到機器學習的異常事件整個數據的流轉,對於用戶來講,告警和監控只須要基於指標和智能巡檢的結果進行,而涉及到具體服務的問題分析能夠再回到原始的訪問日誌並基於SLS提供的各類SQL統計方式進行自定義的排查和分析。架構

實時預聚和

image.png
Ingress的訪問日誌數量和用戶訪問成正比,在原始訪問日誌上實時計算指標的開銷較大,通常不適合長時間的指標分析,而且原始日誌存儲的成本較高,通常不會將日誌存儲較長時間,但咱們仍是但願指標數據可以儘量長的存儲,這樣能夠在分析的時候查看更長時間的數據。爲此SLS專門爲Ingress訪問日誌定製了一套全託管指標實時預聚合的功能,可以實時將Ingress的訪問日誌聚合成指標並存儲在SLS的時序庫中,這樣全部的監控數據查詢工做均可以基於聚合後的時序數據進行,大大提高監控數據的查詢效率。負載均衡

豐富可視化

Ingress訪問日誌分析的一個重要工做是可視化系統的搭建,咱們須要針對不一樣場景建立不一樣的報表以便知足各個方面的需求,例如:機器學習

  1. 總體大盤:包括網站當前的訪問UV/PV、總體延遲、成功率等,這個是老闆們和SRE須要看的數據,須要保證數據時效性和刷新的速度
  2. 監控大盤:可以把監控須要關注的各類數據(延遲(平均、P99/P9999等)、流量、成功率、錯誤碼、TOP類統計)等顯示在一張報表上,而且可以支持各類維度的過濾,方便定位到問題的實例。
  3. 訪問大盤:顯示和用戶相關的訪問信息,例如PV/UV、訪問的地域分佈、設備分佈等,通常狀況技術Leader會關注,另外部分的運營同窗可能也會須要這部分數據。
  4. 異常大盤:顯示異常巡檢的指標信息,可以把異常的指標顯示在報表上,方便查看。
  5. 後端流量分析:快速分析後端的流量、QPS、延遲、錯誤率等分佈信息,可以快速查找到「調皮」的機器。

image.png

智能巡檢

在時序監控場景中,用戶每每先肯定監控對象,並經過其歷史數據,結合業務經驗,獲得不一樣組的閾值參數,經過各類手段(同比、環比、連續觸發幾回等)進行監控,每每一個監控對象要設計4~5條監控規則,並配置不一樣的參數。還有更大的問題,各個參數閾值沒法快速的複用到不一樣的相似觀測對象中,當觀測對象的規模達到數千,甚至上萬後,傳統的配置效率底下,沒法知足在大規則時序指標數據下的監控需求。流式算法具備自然的優點能夠解決上面的問題,用戶只須要發起一個機器學習服務,模型自動拉取數據,實時訓練,實時反饋(通俗地說:「來一個點,學習一個點,檢測一個點」),在極大的下降成本的同時,實現對每一條線的單獨建模,單獨分析,單獨模型參數保存,實現時序異常檢測的「千線千面」。
image.png性能

智能HPA

image.png

基於業務訪問量的HPA

HPA(Horizontal Pod Autoscaler)是Kubernetes提供的一個標準組件,用於POD的橫向自動擴縮容,例如:當Pod CPU、內存等指標上升到必定程度時會自動擴容,當這些指標下去後會自動縮容。這樣可以保證在用戶體驗不變的狀況下集羣總體的資源使用都能處於一個較低的位置。
默認的HPA只能針對集羣的一些標準指標(CPU、內存、網絡等)進行擴容,這種擴容方式相對靜態,並且反應不出業務的狀況。所以咱們對HPA進行了一些擴展,支持按照Ingress訪問QPS進行擴容。便可以設置某個Service下的Pod限定可以處理的QPS,當QPS上升到必定高度時會自動擴容一些Pod/節點,當QPS降低時會自動縮容一些Pod/節點。

基於業務量預測的HPA

HPA的預測原理是判斷某些指標的值進行擴縮容,而指標的值相對來講都有10-30秒左右的延遲,而且還有幾回的double check時間,所以從壓力上升到擴容的時間基本上在2-3分鐘左右,若是Pod啓動還須要預熱的話可能要更久,這段期間用戶的訪問請求極可能會出現高延遲或錯誤的狀況。
所以最好的方式是咱們可以提早知道將來幾分鐘的訪問請求量,當咱們發現將來訪問請求會很高的時候,提早把Pod擴容出來並進行預熱,這樣能夠在請求真正提高時Pod的資源已經提早分配好。爲此咱們結合SLS與阿里雲達摩院聯合研發的多模型預測算法,實時預測Ingress上每一個服務的訪問請求,並把這些預測的指標提供給HPA作動態擴容,可以在請求量即將超過閾值的時候提早擴出Pod/節點,保證用戶訪問一直流暢。

總結

Ingress訪問日誌中心提供了訪問日誌分析、秒級監控指標分析、實時告警等功能,並提供基於AIOps的自動異常巡檢功能。基於這些功能咱們能夠快速構建出一套企業級的監控系統,可以以很是小的工做量實現公司全部訪問入口的統一監控。

原文連接本文爲阿里雲原創內容,未經容許不得轉載。

相關文章
相關標籤/搜索