一、業務背景
運滿滿創立於2013年，致力於爲公路運輸行業提供高效管理配貨的app。在5年時間內從初創型公司發展到獨角獸企業，我們經歷了很多次的技術架構調整。
今天給大家分享下不同時期，在運維監控方面做的多次架構升級。希望給大家在技術選型階段，提供一些參考和借鑑。
二、架構演進
運滿滿監控整體可以分爲三個階段：全家桶套餐時代、DevOps時代、定製AIOps時代
創業期：全家桶套餐
在2015年以前，公司業務發展的不確定性，服務器數量規模較少。大部分都是靠運維人工監控、每日腳本巡檢。
和大部分創業公司一樣，當時的運維人員控制在3人以下，每天都在處理各類開發需求，完全沒有空閒去開發系統，做整體的監控告警。這個階段，我們急需一款開源的、功能齊全的、入門成本低的監控系統。
Zabbix是我們當時的選擇，簡單的配置頁面，豐富的agent數據採集，支持短信、郵件及微信告警，在一個星期內，我們就完成了全站的基礎監控。
Zabbix開箱即用的使用方式，適合初創型公司。即使是現在，Zabbix還在線上運行，監控網絡設備的運行狀態。
發展期：DevOps時代
到了2016年，隨着業務高速發展，研發的需求越來越複雜，同時也暴露出Zabbix的很多缺點。
-
Zabbix性能瓶頸，監控數據存儲在Mysql中，隨着監控數據越來越多，Zabbix響應時間變慢。
-
Zabbix只支持metric類型監控，對於日誌類監控，支持並不友好。
-
Zabbix監控大盤頁面不美觀，無法滿足業務方定製的需求。
基於以上問題，我們開始尋求專業領域內的各類監控。
CAT
CAT(Central Application Tracking)是基於Java開發的實時監控平臺，主要包括移動端監控，應用側監控，核心網絡層監控，系統層監控等。
CAT的優點是功能豐富，支持釘釘告警，95線99線計算，可展示代碼級別監控，在代碼層故障定位提供了強有力的工具。
LEPUS
Lepus(天兔)數據庫企業監控系統是一套由專業DBA針對互聯網企業開發的一款強大的企業數據庫監控管理系統。Lepus後端採用Python語言開發，對於運維非常友好，可以很方便地作出一些個性化的修改。
Lepus的優點是無需安裝agent，賬號集中管理，適合作爲數據庫的CMDB使用。
ELK監控生態
ELK(Elasticsearch,Logstash,Kibana)是Elastic公司提供的三個開源組件。在日常工作中，我們需要進行日誌分析場景：直接對日誌文件進行grep、awk等正則操作，獲取我們想要的信息。在大規模的場景中，日誌文件分佈在不同的服務器上，且文件非常大，逐臺操作性能非常低。比如Nginx日誌，Mysql慢查詢日誌，應用log日誌等。ELK提供一整套的解決方案，可以幫助我們快速全站查詢。
下圖是Mysql慢查詢的截圖，通過python腳本，可以實時讀取Mysql慢查詢日誌，並寫入ES，方便查看線上問題。
下圖是服務器的dashboard，通過模糊匹配，可以快速查詢相關服務器組的性能指標。
Open-Falcon
Open-Falcon是小米開源的監控系統，靈活的數據採集，水平擴展能力以及高效的告警策略幫助我們快速監控servers的信息。在實際的環境中，我們僅採用了falcon-agent、falcon-transfer組件，幫助我們採集數據，具體的存儲及展示由更專業的組件處理。
數據存儲及展示
隨着業務的發展，數據量越來越大，需要一款通用的時序數據庫提供數據存儲，當時有Prometheus、OpenTSDB、InfluxDB三大選擇。
Prometheus提供了豐富的數據模型和查詢語句，容易上手，很容易集成到現有的環境中，但是Prometheus的集羣和HA架構並不成熟，需要額外的開發，並不適合。
InfluxDB是在Prometheus之後才提出的，並且提供商業的伸縮和集羣化服務，相比Prometheus的metrics存儲，InfluxDB還能處理事件類型的數據，對於大部分公司而言，商業化基本不會考慮。
OpenTSDB是一個基於Hadoop和Hbase的分佈式事件序列數據庫，相比Prometheus和InfluxDB，OpenTSDB的橫向擴縮容很容易(需要有豐富的Hadoop/HBase維護經驗),同時官方Open-falcon支持OpenTSDB，結合公司現有的技術棧，綜合考慮後最終選擇了OpenTSDB作爲我們的存儲。
關於數據展示的選型，在沒有自研能力的情況下，Grafana是不二選擇。Grafana的告警功能強大方便，同時支持釘釘，Webhook等，滿足公司所有的需求。與此同時，我們將Grafana和Docker技術結合，實現了Grafana高可用、自愈和無限擴展能力。
數據庫監控
Nginx監控
專線監控
Kubernetes監控
獨角獸期：定製AIOps時代
在2017年底，運滿滿與貨車幫合併，底層數據量翻倍，人員翻倍。我們碰到了以下幾個問題：
-
問題排查，需要打開多套監控系統，效率低。
-
每套監控都有學習成本，對研發不友好。
-
一個故障，多套監控工具同時告警形成短信風暴，擾亂視聽。
基於以上問題，我們提出了建設一套大而全的監控理念，主要包括以下幾個要素：
-
同時支持基礎監控與業務監控；
-
事件日誌與metric指標關聯：
-
告警接口統一；
-
支持多種語言接入。
監控架構圖如下：
在數據採集階段，保留了Open-Faclon、CAT、 客戶端SDK、Logstash等入口，通過Kafka進行匯聚，引入大數據實時計算平臺Flink，提煉metric指標，並最終入庫。
在告警方面，開發了Alert Manager組件，對接多種告警渠道：釘釘、短信、微信等，並且自動創建Jira，告警閉環。
我們的最終目標是實現AI自愈的功能，比如自動降級、限流、流量切換等，目前該部分的功能還在探索中。