開源AIOps資料中台搭建

引言

本文介紹我在

PyCon2019

上海站的議題内容，結尾有PPT下載下傳連結。

根據

Gartner的報告

，AIOps将在未來5-10年落地開花，并集中統一各種Ops平台（Dev、IT、Net、Sec），本議題介紹AIOps的核心作用、相關工程難點（資料采集、資料中台、智能算法、自動化等）與開源方案選擇，适當介紹了Python在其中的主要作用，覆寫開源方案有：Kafka、Elastic Stack (Beats， Elasticsearch，Kibana)、K8S、Prometheus、Grafana、Thanos, Tick stack (Telegraf，InfluxDB，Chronograf，Kapacitor)、Ansible、OpenTelemetry、Skywalking、Druid、Clickhouse等。

一. 關于AIOps

IT運維目标

AIOps并不是蹭熱點，而是以實實在在解決IT運維的痛點或提高效率為目标。一直以來IT運維存在以下3個核心名額/目的：

1. MTTR的降低

MTTR（Mean Time To Repair）

平均修複時間，是一個衡量系統當機時間的名額，IT運維人員以降低此目标為第一要務，越低越好。

2. Cost的降低

公司每年需要在IT上投入很多錢，包括硬體、軟體、服務、人員等，通過IT運維希望将資源效率提高到最高，形成持續的成本優化。另一方面，當機也會帶來業務損失（例如電商一時不能用，客戶就無法下單），是以此名額也與MTTR和SL相關，MTTR越長，SL越低，成本也越高。

3. Service Level的提高

SLA

表示客戶與服務商之間服務可用性的承諾，一般以服務可用性用時長為次元，例如99.99%可用，表示一個周期（例如一個月）當機的總體時間不超過0.01% * 365天 < 4.5分鐘。有時也表示API錯誤率占比。

IT運維挑戰

但是IT運維所面臨的挑戰也呈現越來越高的趨勢，大概分成兩類原因：

1. IT系統複雜度越來越⾼

目标系統越來越複雜，快速定位問題難度越來越高，具體細分為：架構演變複雜化和資料孤島越來越多。

架構演變複雜化

随着雲計算的普及，許多公司存在雲上、雲下業務，甚至多雲政策（海外業務用AWS，亞太用阿裡雲）；SaaS的普及（這點在海外非常普遍），容器化與微服務架構的流行，使得一套系統的部署非常複雜。某一個環節出錯，可能落點也都有可能。

資料孤島越來越多

各種資料存儲于各個系統之中，在大資料下呈現

4V特點（容量Volume、速度Velocity、種類Variety和價值Value）

，很難集中采集與處理，一旦發生問題，很難有效檢查具體資料資訊。

2. IT系統成本越來越⾼

禍不單行，修複的IT問題的成本也越來越高，具體細分為三類原因：

業務中斷成本

資訊化越來越發達的今天，一些流行産品動辄上億PV、千萬UV。例如一些電商、服務系統，一旦臨時不可用，造成的損失就是客戶無法下單、轉投競品處購買，設想一下，雙十一當天每秒的

交易額

可知成本之高，對于金融、公共服務類的系統，則會造成更大的損失也有可能，基本都會成為

新聞報道

。

缺少持續改進

另一方面，普遍存在的現象是運維人員的日常工作大部分時間都在忙于救⽕，自然缺少持續改進的時間和機會，包括工程流程上梳理漏洞，編寫引入自動化工具，客戶教育訓練等

學習速度跟不上

這裡特别強調這點，是因為其實人始終是一個非常重要的原因，業務增長的速度往往超乎人的想象（參考風口論），某個業務在一年内提高5倍、10倍甚至100倍都是有可能的，但人的學習成長速度往往很難比對上。

AIOps基本概念

雖然Ops的概念很寬泛，但一般AIOps表示Artificial Intelligence for IT Operations，可以了解為組合了大資料、機器學習、分析來幫助IT運維實作其目标（例如發現、預測、修複問題）。

而Gartner報告中的一張圖可以更具體的解釋AIOps對IT運維的改進：

• 通過曆史、實時流式資料的導入，結合大資料+機器學習在IT運維的三個方面（檢測、管理、自動化）中的4類場景（曆史分析、異常檢測、性能分析、關聯與上下文等）進行增強。

  

1. 大資料促進平台融合

可以看到AIOps平台要求采集各種資料（包括日志、名額、網絡資料、API、文本、社會媒體資訊等），用于分析、訓練API、關聯分析等以達到效果。

如前述IT運維挑戰所說，完整、實時地采集以上資料是很不容易，且這類資料又被各種角色的人所關心，包括不限于：

• IT運維人員
• 開發人員
• 資料工程師
• 安全運維人員
• 合規審計人員
• 商務分析師
• 相關管理者、決策者

是以Gartner認為AIOps會從功能（Feature）演逐漸變成平台并落地，且預測到2022年年，40%企業會使⽤用AIOps。

2. 機器學習促進ITOps的主要方式

機器智能主要在如下4個場景下幫助ITOps完成目标：

增強描述性

• 通過算法、可視化與統計分析等方式，對海量資料（例如日志、告警）進行降噪、去重，增強其描述性。

增強排錯

• 自動識别資料模式（例如日志模型），自動識别關鍵實體并關聯事件。

增強預測能力

• 使用經典算法，基于模式預測。

增強輔助根因分析

• 通過關聯、知識圖譜獲得可能原因。

總而言之，AIOps的最終目标時促進IT運維的目标達成，逐漸釋放IT運維人員的效率束縛，理想的未來，甚至被認為是服務Level-0（第一道關）的存在：

二. 工程難點

以下将AIOps系統拆解，并逐個從資料采集、資料中台、智能算法、自動化等角度分析其工程難點。

基本架構

簡單描述，一個典型的AIOps的系統可以劃分為如下層次：

更進一步，借鑒熱門AIOps創業公司Moogsoft的一張圖：

自上而下的劃分，可以看到如下子系統：

• 場景應⽤：基于AIOps的通用性，場景不僅可以是運維、也可以是審計、DevOps、商務分析等。
• 智能監測系統：AIOps引擎，處理大資料并使用AI、分析從4個方面增強IT運維。
• 自動化系統：自動處理工單、協同溝通、定位問題的編排系統，自動治愈修複也在其中。
• 工單知識庫：工單系統是重要的輸入源，也是曆史類似問題處理的知識庫。
• 資料湖：不同于傳統資料庫或資料倉庫，這裡是一個無結構模型依賴、實時提供服務的 資料湖
• 監控生态系統：各類監控類系統，輸出的資料，也包括告警。
• 資料源： 底層各種資料源系統，被監控的系統都在這裡，例如主機、服務、雲平台等。

資料采集

沒有大資料，AIOps就如巧婦難為無米之炊，實時、有效、完整地資料采集是AIOps的基礎前提。

1. 資料的攝取挑戰

如前面IT運維的挑戰類似，資料采集是很困難的，随着技術架構的演變，資料有3V（（大容量、常變化、高速增長））的特點、以各種格式（Log、Tracking、Event；Metrics、IoT data；⽹網絡資料）存在于各種來源（ SaaS、多雲、容器器、微服務、主機、應⽤用等）中。

2. 資料類型比較

各種類型的資料之間也有各自的特點，如下：

可見Tracking資料價值大，但采集難度較大；日志類的價值普遍更高；名額類資料簡單，但資料量也可能非常大（IoT場景下）；文本内的價值能力最大，但加工難度最大。

另一方面，資料之間也有一定的重疊（資料量僅供參考）：

某種程度上，在一些産品中，tracking、名額類資料被認為是一種結構化的日志。

資料中台的處理

沒有資料中台，AIOps如空中樓閣，我們看下資料中台具體是什麼，又要做什麼：

1. 海量多樣資料的存儲/索引

資料中台要能夠有效存儲和索引各類資料（時序名額資料、⽂文本資料、⽇日志、⽹網絡資料、Tracking等）。這裡有效指的是，針對前述資料類型的特點，有針對性的提高存儲、檢索效率（例如時序資料的索引與日志類的索引是有所不同的）。

2. 各種分析的⽀支援

還需要支援流式（或微批實時）分析處理，例如實時統計PV或異常告警。另一方面，也需要支援多元度的實時關聯統計與分析，且支援互動式add-hoc方式。

3. 資料治理的支援

資料治理的能力也很重要，包括如下兩個方面，

資料加⼯：支援通⽤資料模型，且支援對多元機器資料、半結構化資料進行靈活的規整或與各種第三⽅資料關聯（富化）等。

資料⽣命周期管理：随時間流式，更老的資料需要降維、聚集或歸檔等，需要有這方面的支援。

機器學習的挑戰

如前述，機器學習具體在如下幾個場景發揮作用：

但算法落地面對一些直接的挑戰：

• 資料不全，品質量欠佳：資料不全将導緻算法模型變形，例如隻用小貓圖檔訓練，算法永遠無法知道老虎長什麼樣。好在越來越多的團隊意識到資料全面性的價值。
• 團隊缺少懂的⼈：算法有一定的數學門檻，但這方面的專業懂的人才相對還是少一些。好在高薪的崗位吸引着越來越多的新鮮血液進入這個領域。
• ⼯具不好⽤：算法工具目前越來越易用，不需要是計算機博士就可以做AI工作，但依然存在一定門檻。
• 工程化不易：目前AI被吐槽的地方就是難的推理結論不準，簡單的推理結論顯然。

外部資料內建與自動化

AIOps的最後一塊重要系統是外部資料內建與自動化，這也是為什麼一些

大廠

逐漸在補齊方面的短闆。這部分主要包括工單系統、CMDB（資産管理）的內建；Run Book自動化、告警與應用的編排能力。

三. 開源方案選擇

這裡介紹一些特定場景下特定的平台搭建的開源選擇及政策：

• 日志類資料⽅方案
• 名額類時序資料⽅方案
• 其他OLAP選擇
• AI增強⽅方案

1. 資料源與監控

這裡以容器化架構為例，自下而上可以看到多個層次的開源方案選擇。

• 底層實體虛拟機層的監控由傳統優勢方案占主導，例如 Zabbix 、 statsd collectd Nagios fluentd 等。
• 往上的容器類監控是 Prometheus + Grafana Thanos 的領地。
• 上層應用的性能、日志類監控的選擇是 Elastic棧 TICK棧 和 Open Telemetry 類方案。

2. 監控⽅案作為中台的能力比較

這裡選擇上面三類監控方案作為中台進行能力比較，次元參考前述挑戰中的方面：

其中Prometheus和Tick方案對于名額類支援很好，而Elastic對于日志類支援更好。但流式分析方面，Prometheus和Elastic方案并無直接支援。而統計關聯分析方面，Elastic較強，其他一般。在資料治理方面的支援，三個方面也都差強人意。總體而言，一個結論是：沒有銀彈。

以下大緻介紹下相關方案的特點與優缺點。

3. Prometheus棧方案

3.1 名額類資料監控 - Prometheus

Prometheus作為K8S監控标配（繼K8S後第2個CNCF項⽬目），其有如下特點：

• 多元資料模型 + PromQL。
• 彙總性資料+Label過濾。
• 可從160+源管道提取名額資料。
• 主動拉去模式（可由gateway被動）。
• 自動發現。
• 主要用于短期名額。
• 支援20+外部存儲用于長期存儲。

3.2 通⽤用名額類可視化 - Grafana

作為通⽤型名額類可視化⽅案，Grafana已然是Phrometheus的連體嬰兒了，其有如下特點：

• 近70資料源（支援混合）。
• 新推簡單⽇志方案：Promtail+Loki，目前還非常初級。
• ⾃由報表定制與建構。
• 30+ 可視化插件。
• ⽀持查詢原始名額。

3.3 Prometheus的擴充 - Thanos

試圖解決Prometheus的幾個核心問題而生的方案，其有如下特點：

• 全相容Prometheus，提供全局視圖+HA。
• 擴充⾼可用。
• Sidecar + Query節點。
• ⻓時間備份與歸檔。
• 壓縮與下采樣（Down Sampling）。

4. Open Telemetry方案

是目前CNCF藍圖下統⼀Metric、Tracking的新标準（統一了Open Tracing和Open Census），目前還處于開發階段，其主要是用戶端标準。

Open Telemetry - SkyWalking

SkyWalking作為國内流行Tracking方案，已經是Apache孵化項目，其有如下特點：

• 性能影響較小(<10%)

• Cloud Native容器化⽀持好

• 支援存儲到ES/TiDB、MySQL等

5. TICK棧方案

作為InfluxDB家的全家桶，其表示Telegraf + InfluxDB + Chronograf + Kapacitor。此方案具備如下一些特點：

• InfluxDB：⾼性能的時序資料庫。 與ElasticSearch比較報告 号稱有8X寫⼊速度，少4X磁盤占用，以及3~7X響應速度。
• Telegraf：資料采集用戶端，支援200+資料管道。
• Chronograf：可視化方案，其沒有Grafana強⼤和靈活。
• 此方案一個缺點是開源免費版本缺少叢集、安全、管理等功能。

6. Elastic棧方案

作為Elastic家的全家桶，在日志與文本領域非常流行，常用BELK表示，意為Beats + Elasticsearch + Logstash + Kibana。此方案有如下特點：

• 接⼊層通常還會搭配Kafka使用。
• 重要企業級元件都在商業元件X-Pack中，包括安全、機器學習、SQL、監控、告警、Transform等
• 其附帶了⼀個簡單的開源免費的APM方案。

典型Elasticsearch部署方式

是搭配

Kafka

使用，并在整個接入過程中使用Logstash（或Ingest Node）完成資料的轉換（ETL），引⼊隊列，主要是解決丢資料問題，但相應的部署、維護複雜度也較為複雜。

6.1 Elasticsearch核⼼能⼒

作為Elastic核心資料庫，Elasticsearch具有如下特點：

• 簡單、易擴充、功能集豐富、生态活躍。
• NoSQL、schema靈活。
• 全文索引查詢強、過濾快、聚集功能強⼤。
• 不支援外部關聯，有SQL擴充卡器（有限支援）。

但其缺點也較為明顯：

• 企業特性需要商業License（x-pack）。
• 記憶體管理理挑戰較大，複雜類統計DSL易失控。
• 超過百TB規模後運維成本⾼（非線性增長）。
• 存儲壓縮效率偏低。

6.2 Kibana核⼼能⼒

Kibana作為Elastic專屬可視化方案，近幾年疊代很快，其具有如下特點：

• 支援互動式查詢控制台、類tail-f功能。
• 支援完整報表中⼼與互動功能。
• 提供⾼級圖表功能：地圖、關系圖等。
• 支援時序資料。
• 支援機器學習（收費）。
• 提供Canvas⾃由編輯能力（支援暗黑主題，但挂接資料方式有限）。

6.3 Logstash核⼼能⼒

作為ELK的主要接入與資料治理核心元件，Logstash具備如下特點：

• 插件化靈活：輸⼊入/過濾/輸出
• 200+插件
• 配置統⼀一管理理
• 資料傳輸可靠性

但其缺點也較為明顯：占用資源較大，性能較差。

6.4 Beats核⼼能⼒

為解決Logstash的性能問題，引入了Beats，提供8類輕量級Beats，具備如下特點：

• 配置統⼀管理，部分邏輯插件化
• 內建50+内置⽣态子產品（⽇志與名額）
• ⽀持容器類部署場景

7. 其他OLAP選擇

除了前述三種主要開源監控類方案外，這裡也介紹一下其他部分流行OLAP的開源方案作為中台選擇參考。

7.1 Druid

Druid

作為Apache項目，有如下特點：

• 性能優越：
  • PB級别規模。
  • 亞秒級OLAP系統。
  • 實時寫入與查詢。
• 元件⻆色較多，搭建較為複雜。
• Json-QL（有SQL擴充卡器）。
• 不⽀持外Join、視窗等。

7.2 ClickHouse

作為新起之秀，

ClickHouse

以其獨門武功的卓越性能吸引了一大批使用者，其具有如下特點：

• • 10億+條規模⽐比商業軟體快5倍
  • ⽐比MySQL快⼏幾百倍
• 穩定可靠，⾮非Hadoop體系，
• 類SQL功能
• 缺點：
  • 聚合結果要在⼀一台機器器記憶體内
  • 缺少完整更更新删除操作
  • ⽀支援作業系統有限

8. AI與自動化

關于AI方面以Python架構為主，而自動化方面選擇較多，這裡也列舉一些Python的方案如下：

• 資料治理：Python ETL、PySpark、Flink/Blink-Python
• 機器學習：Airflow（編排）+ 如下機器學習架構
• 自動化：Ansible、Puppet等

以下列舉一下具體的AI算法在場景下應用執行個體：

8.1 AI增強 - 降噪去重與模式識别

這裡主要展現在機器資料的聚類（模式識别），例如對海量日志進行模式聚類（從65萬條日志，聚類出50條日志模式），以下是一些方案樣例：

8.2 AI增強 - 異常值（Outlier)與異常識别（Anomaly）

傳統Ops平台普遍存在告警疲勞，因為傳統基于門檻值方式的告警并不能很好解決問題：

• 門檻值難以合理，例如CPU高于90%在某些情況下合理，某些又不正常。
• 基于經驗的有效門檻值會⾮常複雜：例如外網非工作時間頻繁登入失敗是異常，但公司内工作時間相對容忍度較高。
• 有效門檻值維護成本較⾼：經常因情況變化要調整。
• 過濾後的告警數量依然較多。

比較好的方法政策是以曆史資料作為基準，對周期性或斷層資料異常進⾏識别：

• 使⽤基于統計的動态門檻值。
• 使⽤模式識别正常行為與異常行為。

如下是一些方案樣例：

8.3 AI增強 - 預測

對周期性趨勢性資料進行預測，一些方案樣例：

8.4 AI增強 - 根因分析

關聯事件上下⽂文與相關鍊路路名額，提供根因輔助，一些方案樣例：

四. 結語

開源⽅案選擇政策

使用開源方案時需要考慮幾點：

1. 沒有銀彈，沒有one for all

沒有一套方案完美解決所有問題，需要權衡選擇合适的方案組合，但也不要萬花筒。

2. 開源 ≠免費

開源的東西不等于免費，因為如下幾點原因：

• 學習、遷移、維護更新、穩定性、License、潛在坑（例如這個長長的 breaking change清單 ）等。
• 某些開源軟體的重要擴充是需要額外費用的（例如InfluxDB的叢集功能）。

需要結合團隊、技術需求、⽅案選擇做細緻評估。商業軟體或SaaS方案（簡化Ops平台⾃自身運維成本，例如

阿裡雲日志服務

）也可作為選項。

其他

PPT下載下傳:

https://github.com/wjo1212/ChinaPyCon2019

另外，我們一直在提供并發展雲上AISecDevOps平台，歡迎掃群加入日志服務技術交流釘釘群, 獲得第一手資料與支援：