鑽石舞台

早期的網易有數平台通過ambari作為大數據底層管理平台，基於ambari做了很多定製化開發，比如通過ambari集成其他服務組件。但隨着hdp跟cdh合併後並且收費，ambari社區也停止維護了。ambari管控平台在同時管理幾百上千台服務器，會存在很多性能層面的問題，例如頁面響應慢，集群監控指標比較大，導致監控經常看不到數據，ambari相對於中台服務之間集成，運維，以及升級難度比較大，因此內部開始自研大數據管控平台。

集成服務太多，平台運維人員無法掌握相關服務的運維操作命令；

組件頻繁配置變更，如果說修改hdfs參數，下游依賴的大數據組件，中台組件相應參數變更；

集群監控指標不全，運維人員無法通過指標排查集群問題；

數據鏈路比較長，運維無法定位相關故障點；

集群組件升級頻繁，小版本升級，大版本升級。

EasyOps是網易有數旗下一個含括部署、監控、報警、運維為一體的自動化運維管理平台。目前管理着網易有數所有服務，並為其提供準確、實時的監控報警。

3.1 功能闡述

（1）解決部署工具無法適配複雜架構的問題，譬如多集群管理、服務實例混合部署等

easyops支持管控多個集群，比如說一個easyops同時管控離線集群，實時集群，hbase集群等，另外像支持雙集群部署，比如數據沙箱集群同時訪問生成數據，並且一套集群中支持部署多個組件，例如集群中部署依賴kerberos的zookeeper跟不依賴kerberos的zookeeper集群，這一點是當前主流管控平台不支持。

（2）提供集群部署、監控、升級等自動化運維操作，提升運維效率

當前easyops已經完成對每個大數據組件頁面化部署，對服務組件的啟停，修改配置，組件跨版本升級，以及支持配置集群多配置組功能，對一些組件比如impala，yarn，datanode實現滾動重啟。另外集成部署的每個組件指標進行採集，匯總，計算，最終形成dashboard展示到前端。

（3）產品化的底層數據接口，服務數據中台

像一些主流的組件hdfs/yarn/hive/impala等常用組件，其他比如kerberos/ldap/ranger等全套大數據權限管控框架，還有knox/nginx/redis/kong這些大數據周邊組件都已經完全集成，另外針對大數據上層服務，比如數據地圖，數據傳輸，數據資產等配套組件。

（4）支持原地升級HDP集群到Easyops

目前像網易有數早期通過amabari部署的集群，支持將該集群原地升級到easyops集群中，這樣省去了用戶去重新部署集群，遷移數據，遷移任務等操作。

3.2 詳細介紹

左邊主要分3部分:

中台組件：azkaban/Mammut/EasyMetahub/EasyTransfer等30個組件；

基礎組件：hdfs/yarn/hive/redis/nginx/kyuubi等20多個組件；

監控組件：主要對每個服務監控採集agent。

右邊主要是組件的詳情，健康狀態，每個組件子服務部署詳細拓撲結構，jvm，rpc等常規指標，能夠通過這個頁面直觀的反映組件的健康狀態。

3.3 配置變更

支持多配置組

對於datanode/nodemanager/impalad這些組件，由於當前節點磁盤，內存差異或者批量節點單獨配置，例如將impalad節點做coodinator跟executor分離，因此需求按照分組管理當前節點。

保留配置變更記錄，支持配置快速回滾操作

支持配置透傳

配置頁面目前支持常規參數變更，但是對於不常用的配置可以通過添加高級選項方式傳入配置中。

滾動重啟

對於一些組件如果datanode，nodemanager這些組件實現滾動重啟，以及節點服務一鍵拉起服務。

3.4 組件自動化升級

單一組件升級

目前支持添加特定服務版本，點擊組件變更，頁面直接對相關組件做滾動升級操作；

中台服務組件批量升級

對於網易內部中台服務存在服務比較多，服務版本相互依賴，版本迭代頻繁導致組件升級困難，針對這種情況，內部做了批量升級操作，通過頁面快速實現大版本升級，以及update（多個組件）升級，節省了運維誤操作的風險，以及時間。

4.1 管控Docker編排、部署和管理服務

目前easyops都是通過docker化部署：並且集成prometheus/grafana監控組件。

easyops-gateway

easyops-frontend

easyops-alarm

easyops-manager

easyops-manual

easyops-grafana

easyops-ansible

easyops-prometheus

easyops-db

4.2 支持模板化部署

4.3 設計架構

ansible：運維配置管理工具

ansible-runner ：基於ansible封裝後的自動化工具

ansible-runner-service：提供基於ansible-runner的REST API訪問接口

4.4 Easyops後端集成代碼塊

roles下以服務名創建目錄，目錄下創建defaults,tasks,templates,vars目錄；

defaults：用於存放默認的變量值，必須創建main.yml文件，調用role時會自動加載；

tasks: 所有的任務腳本存放的目錄，必須創建main.yml，當調用role時，會調用main.yml；

templates: 用於存放templates模板，生成配置文件；

vars: 用於存放動態的變量值，需要include對應的變量文件才會加載。

4.5 easyops管理集群難點

問題一：大批量節點操作時引發ansible-runner-service瞬時高負載，而拒絕超載請求

例如：當有100個datanode需要重啟，或者50個nodemanager需要擴容，會提交對應數量的ansible-runner調用，瞬間系統負載升高，同時超過默認events數的請求被拒絕。

優化方案：

資源充足前提下，提高event_threads 對應地調大ansible容器資源reservations

將1個操作請求封裝到1個ansible調用，即操作集簡化與合併；

服務個數是有限的，服務的組件實例數是無限的，批量的組件操作請求以服務為單位封裝；

將多個component操作合為一個，重寫genInventory。

問題二：EasyOps操作最終是調ansible playbook，為playbook生成運行時的inventory，當前inventory內容過多，尤其在服務與組件實例過多的情況下inventory變得很大，其創建、分發、查詢都受影響。

內容量不可控部分：

（1）dependency_service 集：隨依賴服務變多而變大；

（2）hosts 集：隨集群規模增大而變大；

（3）jinja2_vars 集：隨hosts集增大而變大；

（4）exports 集：導出文件不多、內容不大也還好；

優化方案：

（1）操作哪些組件實例生成哪些實例inventory

hosts下面只生成我們操作的那些組件實例的inventory，不是全打上去，比如只操作其中1個dn，那hosts下面只有該dn和本機上依賴服務的inventory內容

（2）按操作類型使用不同生成策略

主要對於控制類操作（服務的啟動、停止、重啟，組件的啟動、停止、重啟），不加入dependency_service段，不加入jinja2_vars段（考慮也使用start_all批量操作）

（3）同一組件抽出公共inventory

同一組件類型的各實例（如HRegionServer）inventory大多內容一樣，僅帶有instance_id部分不同，以及個性化配置項

優化辦法是從hosts下所有組件實例的內容段中抽出一個公共段vars 與hosts同級，集群規模越大 能減少越多相同行（基於1個配置組提取公共vars）

4.6 告警採集模塊

EasyOps針對所管理的服務監控，根據服務的類型，會使用不同的指標採集方式以達到監控、報警的目的。

按照採集器類型進行相關介紹主要有Exporter採集，Telegraf採集，Javaagent採集；

Exporter採集

使用此類採集方式的服務主要如下：

HDFS

Yarn

Hbase

Redis

Spark2-task

ElasticSearch

MySQL

Node

萬象

此類採集主要使用社區的開源方案，並在各類exporter上進行相關定製化開發。

exporter主要功能是將服務的指標數據按照配置規則解析成對應的數據格式，以供prometheus進行數據存儲。

Telegraf採集

使用此類採集方式的服務如下：

Hive（metastore以及hiveserver2）

Ldap

Kerberos

Nginx

Kyuubi

Impala

Telegraf採集主要是根據服務的指標數據文件（需要更改相對應的服務配置文件，進行指標數據的輸出）、暴露的指標接口等，對數據按照配置規則解析成對應的數據格式，以供prometheus進行數據的存儲。

JavaAgent採集

使用此類採集方式的服務如下：

Zookeeper

BDMS_Meta

Meta_Service

Hadoop_Meta

Hadoop_Meta

Mammut

MapReduce2_historyServer

Spark2_historyServer

JavaAgent採集主要是針對java的一些web項目。JavaAgent不能作為一個獨立的進程啟動，需要將對應的jar以及解析文件所在路徑寫在上述服務運行的啟動腳本中。此類採集方式獲取的數據較少，均是jmx數據，無業務相關指標數據。

4.7 告警存儲模塊

Prom_m01/02：僅監控prom_0n的狀態數據，不拉取各個prom_0n所存儲的監控數據。如果監控的prometheus子服務掛掉，會觸發生成相同配置的子服務邏輯，保證其子服務的高可用

Prom_0n：按照實例功能進行分區，採集對應實例的監控數據

nginx：由於prometheus寫入遠程數據源時，僅能連接存儲節點。內部NTSDB已實現高可用，一個實例有多個存儲節點，使用nginx做轉發和負載均衡

NTSDB：所有prom_0n均使用遠程數據源，寫入NTSDB

以上架構解決了如下問題：

增強了擴展性：目前採集按照實例劃分，不同的prometheus子服務負責不同的採集實例，可以橫向擴展

數據統一存儲，不重複

數據的高可用

解決單點問題：目前數據的查詢直接從NTSDB端進行

數據降維：利用NTSDB的CQ功能，實現了數據的降維處理

不需引入、維護其他組件：不需要引入對象存儲服務以及維護Gossip

4.8 告警指標展示模塊

目前通過grafana上配置dashboard展示每個組件的相關指標；

4.9 告警推送模塊

grafana頁面自定義的alert模塊，方便對集群通用性指標加監控

告警推送渠道：Dingding，webhook，Email...

操作簡單，易用，方便移植

目前Easyops在整個大數據運維平台上功能已經滿足日常需要，後期還需要細化一些指標告警模塊：

（1）支持CDH相關版本接管升級；

（2）集成業界主流組件，形成一站式管理運維工具；

（3）適配主流的雲存儲方案，包括s3/obs/oss等；

（4）集成spark/flink/MR任務分析，以及HDFS讀寫延遲，YARN調度延遲等異常診斷和異常告警。

以上就是本期分享的全部內容了，謝謝大家。