監(jiān)控目標(biāo)

我們先來了解什么是監(jiān)控piwik關(guān)鍵詞排名插件，監(jiān)控的重要性以及監(jiān)控的目標(biāo)piwik關(guān)鍵詞排名插件，當(dāng)然每個(gè)人所在的行業(yè)不同、公司不同、業(yè)務(wù)不同、崗位不同、對(duì)監(jiān)控的理解也不同，但是我們需要注意，監(jiān)控是需要站在公司的業(yè)務(wù)角度去考慮，而不是針對(duì)某個(gè)監(jiān)控技術(shù)的使用。

對(duì)系統(tǒng)不間斷實(shí)時(shí)監(jiān)控:實(shí)際上是對(duì)系統(tǒng)不間斷的實(shí)時(shí)監(jiān)控(這就是監(jiān)控)實(shí)時(shí)反饋系統(tǒng)當(dāng)前狀態(tài):我們監(jiān)控某個(gè)硬件、或者某個(gè)系統(tǒng)，都是需要能實(shí)時(shí)看到當(dāng)前系統(tǒng)的狀態(tài)，是正常、異常、或者故障保證服務(wù)可靠性安全性:我們監(jiān)控的目的就是要保證系統(tǒng)、服務(wù)、業(yè)務(wù)正常運(yùn)行保證業(yè)務(wù)持續(xù)穩(wěn)定運(yùn)行:如果我們的監(jiān)控做得很完善，即使出現(xiàn)故障，能第一時(shí)間接收到故障報(bào)警，在第一時(shí)間處理解決，從而保證業(yè)務(wù)持續(xù)性的穩(wěn)定運(yùn)行。監(jiān)控方法

既然我們了解到了監(jiān)控的重要性、以及監(jiān)控的目的，那么下面我們需要了解下監(jiān)控有哪些方法。

了解監(jiān)控對(duì)象:我們要監(jiān)控的對(duì)象你是否了解呢piwik關(guān)鍵詞排名插件？比如CPU到底是如何工作的？性能基準(zhǔn)指標(biāo):我們要監(jiān)控這個(gè)東西的什么屬性？比如CPU的使用率、負(fù)載、用戶態(tài)、內(nèi)核態(tài)、上下文切換。報(bào)警閾值定義:怎么樣才算是故障，要報(bào)警呢？比如CPU的負(fù)載到底多少算高，用戶態(tài)、內(nèi)核態(tài)分別跑多少算高？故障處理流程:收到了故障報(bào)警，那么我們?cè)趺刺幚砟?？有什么更高效的處理流程嗎？監(jiān)控核心

我們了解了監(jiān)控的方法、監(jiān)控對(duì)象、性能指標(biāo)、報(bào)警閾值定義、以及故障處理流程幾步驟，當(dāng)然我們更需要知道監(jiān)控的核心是什么？

發(fā)現(xiàn)問題:當(dāng)系統(tǒng)發(fā)生故障報(bào)警，我們會(huì)收到故障報(bào)警的信息定位問題:故障郵件一般都會(huì)寫某某主機(jī)故障、具體故障的內(nèi)容，我們需要對(duì)報(bào)警內(nèi)容進(jìn)行分析，比如一臺(tái)服務(wù)器連不上:我們就需要考慮是網(wǎng)絡(luò)問題、還是負(fù)載太高導(dǎo)致長(zhǎng)時(shí)間無法連接，又或者某開發(fā)觸發(fā)了防火墻禁止的相關(guān)策略等等，我們就需要去分析故障具體原因。解決問題:當(dāng)然我們了解到故障的原因后，就需要通過故障解決的優(yōu)先級(jí)去解決該故障?？偨Y(jié)問題:當(dāng)我們解決完重大故障后，需要對(duì)故障原因以及防范進(jìn)行總結(jié)歸納，避免以后重復(fù)出現(xiàn)。監(jiān)控工具

下面我們需要選擇一款合適公司業(yè)務(wù)的監(jiān)控工具進(jìn)行監(jiān)控,這里我對(duì)監(jiān)控工具進(jìn)行了簡(jiǎn)單的分類。

老牌監(jiān)控

MRTG（Multi Route Trffic Grapher）是一套可用來繪制網(wǎng)絡(luò)流量圖的軟件，由瑞士奧爾滕的Tobias Oetiker與Dave Rand所開發(fā)，以GPL授權(quán)。MRTG最好的版本是1995年推出的，用perl語言寫成，可跨平臺(tái)使用，數(shù)據(jù)采集用SNMP協(xié)議，MRTG將手機(jī)到的數(shù)據(jù)通過Web頁面以GIF或者PNG格式繪制出圖像。

Grnglia是一個(gè)跨平臺(tái)的、可擴(kuò)展的、高性能的分布式監(jiān)控系統(tǒng)，如集群和網(wǎng)格。它基于分層設(shè)計(jì)，使用廣泛的技術(shù)，用RRDtool存儲(chǔ)數(shù)據(jù)。具有可視化界面，適合對(duì)集群系統(tǒng)的自動(dòng)化監(jiān)控。其精心設(shè)計(jì)的數(shù)據(jù)結(jié)構(gòu)和算法使得監(jiān)控端到被監(jiān)控端的連接開銷非常低。目前已經(jīng)有成千上萬的集群正在使用這個(gè)監(jiān)控系統(tǒng)，可以輕松的處理2000個(gè)節(jié)點(diǎn)的集群環(huán)境。

Cacti（英文含義為仙人掌）是一套基于PHP、MySQL、SNMP和RRDtool開發(fā)的網(wǎng)絡(luò)流量監(jiān)測(cè)圖形分析工具，它通過snmpget來獲取數(shù)據(jù)使用RRDtool繪圖，但使用者無須了解RRDtool復(fù)雜的參數(shù)。提供了非常強(qiáng)大的數(shù)據(jù)和用戶管理功能，可以指定每一個(gè)用戶能查看樹狀結(jié)構(gòu)、主機(jī)設(shè)備以及任何一張圖，還可以與LDAP結(jié)合進(jìn)行用戶認(rèn)證，同時(shí)也能自定義模板。在歷史數(shù)據(jù)展示監(jiān)控方面，其功能相當(dāng)不錯(cuò)。Cacti通過添加模板，使不同設(shè)備的監(jiān)控添加具有可復(fù)用性，并且具備可自定義繪圖的功能，具有強(qiáng)大的運(yùn)算能力（數(shù)據(jù)的疊加功能）

Nagios是一個(gè)企業(yè)級(jí)監(jiān)控系統(tǒng)，可監(jiān)控服務(wù)的運(yùn)行狀態(tài)和網(wǎng)絡(luò)信息等，并能監(jiān)視所指定的本地或遠(yuǎn)程主機(jī)狀態(tài)以及服務(wù)，同時(shí)提供異常告警通知功能等。Nagios可運(yùn)行在Linux和UNIX平臺(tái)上。同時(shí)提供Web界面，以方便系統(tǒng)管理人員查看網(wǎng)絡(luò)狀態(tài)、各種系統(tǒng)問題、以及系統(tǒng)相關(guān)日志等 Nagios的功能側(cè)重于監(jiān)控服務(wù)的可用性，能根據(jù)監(jiān)控指標(biāo)狀態(tài)觸發(fā)告警。目前Nagios也占領(lǐng)了一定的市場(chǎng)份額，不過Nagios并沒有與時(shí)俱進(jìn)，已經(jīng)不能滿足于多變的監(jiān)控需求，架構(gòu)的擴(kuò)展性和使用的便捷性有待增強(qiáng)，其高級(jí)功能集成在商業(yè)版Nagios XI中。

Smokeping主要用于監(jiān)視網(wǎng)絡(luò)性能，包括常規(guī)的ping、xintu服務(wù)器性能、DNS查詢性能、SSH性能等。底層也是用RRDtool做支持，特點(diǎn)是繪制圖非常漂亮，網(wǎng)絡(luò)丟包和延遲用顏色和陰影來標(biāo)示，支持將多張圖疊放在一起，其作者還開發(fā)了MRTG和RRDtll等工具。Smokeping的站點(diǎn)為piwik關(guān)鍵詞排名插件：http://tobi.oetiker.cn/hp

開源監(jiān)控系統(tǒng)OpenTSDB用Hbase存儲(chǔ)所有時(shí)序（無須采樣）的數(shù)據(jù)，來構(gòu)建一個(gè)分布式、可伸縮的時(shí)間序列數(shù)據(jù)庫。它支持秒級(jí)數(shù)據(jù)采集，支持永久存儲(chǔ)，可以做容量規(guī)劃，并很容易地接入到現(xiàn)有的告警系統(tǒng)里。OpenTSDB可以從大規(guī)模的集群（包括集群中的網(wǎng)絡(luò)設(shè)備、操作系統(tǒng)、應(yīng)用程序）中獲取相應(yīng)的采集指標(biāo)，并進(jìn)行存儲(chǔ)、索引和服務(wù)，從而使這些數(shù)據(jù)更容易讓人理解，如Web化、圖形化等。

王牌監(jiān)控

Zabbix是一個(gè)分布式監(jiān)控系統(tǒng)，支持多種采集方式和采集客戶端，有專用的Agent代理，也支持SNMP、IPMI、JMX、Telnet、SSH等多種協(xié)議，它將采集到的數(shù)據(jù)存放到數(shù)據(jù)庫，然后對(duì)其進(jìn)行分析整理，達(dá)到條件觸發(fā)告警。其靈活的擴(kuò)展性和豐富的功能是其他監(jiān)控系統(tǒng)所不能比的。相對(duì)來說，它的總體功能做的非常優(yōu)秀。從以上各種監(jiān)控系統(tǒng)的對(duì)比來看，Zabbix都是具有優(yōu)勢(shì)的，其豐富的功能、可擴(kuò)展的能力、二次開發(fā)的能力和簡(jiǎn)單易用的特點(diǎn)，讀者只要稍加學(xué)習(xí)，即可構(gòu)建自己的監(jiān)控系統(tǒng)。

Prometheus 是一套開源的系統(tǒng)監(jiān)控報(bào)警框架。它啟發(fā)于 Google 的 borgmon 監(jiān)控系統(tǒng)，由工作在 SoundCloud 的 google 前員工在 2012 年創(chuàng)建，作為社區(qū)開源項(xiàng)目進(jìn)行開發(fā)，并于 2015 年正式發(fā)布。Prometheus是最近幾年開始流行的一個(gè)新興監(jiān)控告警工具，特別是kubernetes的流行帶動(dòng)了prometheus的應(yīng)用。

小米的監(jiān)控系統(tǒng)：open-falcon。open-falcon的目標(biāo)是做最開放、最好用的互聯(lián)網(wǎng)企業(yè)級(jí)監(jiān)控產(chǎn)品。

三方監(jiān)控

現(xiàn)在市場(chǎng)上有很多不錯(cuò)的第三方監(jiān)控，比如：監(jiān)控寶、監(jiān)控易、還有很多云廠商自帶監(jiān)控，但是在這里我們不打算著重介紹，如果想了解三方監(jiān)控可自行上官網(wǎng)咨詢。

監(jiān)控指標(biāo)

我們上面了解了監(jiān)控方法、目標(biāo)、流程、也了解了監(jiān)控有哪些工具，可能有人會(huì)疑惑，我們具體要監(jiān)控寫什么東西，那么我在這里進(jìn)行了分類整理:

硬件監(jiān)控

早期我們通過機(jī)房巡檢的方式，查看硬件設(shè)備燈光閃爍情況判斷是否故障，這樣非常浪費(fèi)人力，并且是重復(fù)性無技術(shù)含量的工作，大家懂得。

當(dāng)然我們現(xiàn)在可以通過IPMI對(duì)硬件詳細(xì)情況進(jìn)行監(jiān)控，并對(duì)CPU、內(nèi)存、磁盤、溫度、風(fēng)扇、電壓等設(shè)置報(bào)警設(shè)置報(bào)警閾值(自行對(duì)監(jiān)控報(bào)警內(nèi)容編寫合理的報(bào)警范圍)

系統(tǒng)監(jiān)控

中小型企業(yè)基本全是Linux服務(wù)器，那么我們肯定是要監(jiān)控起系統(tǒng)資源的使用情況，系統(tǒng)監(jiān)控是監(jiān)控體系的基礎(chǔ)。

CPU CPU有幾個(gè)重要的概念:上下文切換、運(yùn)行隊(duì)列和使用率。

這也是我們CPU監(jiān)控的幾個(gè)重點(diǎn)指標(biāo)。通常情況，每個(gè)處理器的運(yùn)行隊(duì)列不要高于3，CPU 利用率中用“戶態(tài)/內(nèi)核態(tài)”比例維持在70/30，空閑狀態(tài)維持在50%，上下文切換要根據(jù)系統(tǒng)繁忙程度來綜合考量。

針對(duì)CPU常用的工具有:htop、top、vmstat、mpstat、dstat、glances

內(nèi)存 通常我們需要監(jiān)控內(nèi)存的使用率、SWAP使用率、同時(shí)可以通過zabbix描繪內(nèi)存使用率的曲線圖形發(fā)現(xiàn)某服務(wù)內(nèi)存溢出等。針對(duì)內(nèi)存常用的工具有: free、top、vmstat、glances

IO IO分為磁盤IO和網(wǎng)絡(luò)IO。除了在做性能調(diào)優(yōu)我們要監(jiān)控更詳細(xì)的數(shù)據(jù)外，那么日常監(jiān)控，只關(guān)注磁盤使用率、磁盤吞吐量、磁盤寫入繁忙程度，網(wǎng)絡(luò)也是監(jiān)控網(wǎng)卡流量即可。

常用工具有：iostat、iotop、df、iftop、sar、glances

應(yīng)用監(jiān)控

把硬件監(jiān)控和系統(tǒng)監(jiān)控研究明白后，我們進(jìn)一步操作是需要登陸到服務(wù)器上查看服務(wù)器運(yùn)行了哪些服務(wù)，都需要監(jiān)控起來。應(yīng)用服務(wù)監(jiān)控也是監(jiān)控體系中比較重要的內(nèi)容，例如：LVS、Haproxy、Docker、Nginx、PHP、Memcached、Redis、MySQL、Rabbitmq等等，相關(guān)的服務(wù)都需要使用zabbix監(jiān)控起來。

網(wǎng)絡(luò)監(jiān)控

網(wǎng)絡(luò)監(jiān)控是我們構(gòu)建監(jiān)控平臺(tái)是必須要考慮的，尤其是針對(duì)有多個(gè)機(jī)房的場(chǎng)景，各個(gè)機(jī)房之間的網(wǎng)絡(luò)狀態(tài)，機(jī)房和全國(guó)各地的網(wǎng)絡(luò)狀態(tài)都是我們需要重點(diǎn)關(guān)注的對(duì)象，那么如何掌握這些狀態(tài)信息呢？我們需要借助于網(wǎng)絡(luò)監(jiān)控工具Smokeping。

Smokeping 是rrdtool的作者Tobi Oetiker的作品，是用Perl寫的，主要是監(jiān)視網(wǎng)絡(luò)性能，xintu 服務(wù)器性能，dns查詢性能等，使用rrdtool繪圖，而且支持分布式，直接從多個(gè)agent進(jìn)行數(shù)據(jù)的匯總。

同時(shí)，由于自己監(jiān)控點(diǎn)比較少，還可以借助很多商業(yè)的監(jiān)控工具，比如監(jiān)控寶、聽云、基調(diào)、博瑞等。同時(shí)這些服務(wù)提供商還可以幫助你監(jiān)控CDN的狀態(tài)。

流量分析

網(wǎng)站流量分析對(duì)于運(yùn)維人員來說，更是一門必須掌握的知識(shí)了。比如對(duì)于一家電商公司來說：通過對(duì)訂單來源的統(tǒng)計(jì)和分析，可以了解我們?cè)谀硞€(gè)網(wǎng)站上的廣告投入有沒有收到預(yù)期的效果?？梢詤^(qū)分不同地區(qū)的訪問人數(shù)、甚至商品交易額等。

百度統(tǒng)計(jì)、google分析、站長(zhǎng)工具等等，只需要在頁面嵌入一個(gè)js即可。但是，數(shù)據(jù)始終是在對(duì)方手中，個(gè)性化定制不方便，于是google出一個(gè)叫piwik的開源分析工具。

日志監(jiān)控

通常情況下，隨著系統(tǒng)的運(yùn)行，操作系統(tǒng)會(huì)產(chǎn)生系統(tǒng)日志，應(yīng)用程序會(huì)產(chǎn)生應(yīng)用程序的訪問日志、錯(cuò)誤日志，運(yùn)行日志，網(wǎng)絡(luò)日志，我們可以使用ELK來進(jìn)行日志監(jiān)控。

對(duì)于日志監(jiān)控來說，最見的需求就是收集、存儲(chǔ)、查詢、展示，開源社區(qū)正好有相對(duì)應(yīng)的開源項(xiàng)目：logstash（收集） + elasticsearch（存儲(chǔ)+搜索） + kibana（展示） 我們將這三個(gè)組合起來的技術(shù)稱之為ELK Stack，所以說ELK Stack指的是Elasticsearch、Logstash、Kibana技術(shù)棧的結(jié)合。

如果收集了日志信息，那么如果部署更新有異常出現(xiàn)，可以立即在kibana上看到。

安全監(jiān)控

雖然Linux開源的安全產(chǎn)品不少，比如四層iptables，七層WEB防護(hù)nginx+lua實(shí)現(xiàn)WAF，最后將相關(guān)的日志都收至Elkstack，通過圖形化進(jìn)行不同的攻擊類型展示。但是始終是一件比較耗費(fèi)時(shí)間，并且個(gè)人效果并不是很好。這個(gè)時(shí)候我們可以選擇接入第三方服務(wù)廠商。

三方廠商提供全面的漏洞庫，涵蓋服務(wù)、后門、數(shù)據(jù)庫、配置檢測(cè)、CGI、SMTP等多種類型全面檢測(cè)主機(jī)、Web應(yīng)用漏洞自主挖掘和行業(yè)共享相結(jié)合第一時(shí)間更新0day漏洞，杜絕最新安全隱患。

API監(jiān)控

由于API變得越來越重要，很顯然我們也需要這樣的數(shù)據(jù)來分辨我們提供的 API是否能夠正常運(yùn)作。監(jiān)控API接口GET、POST、PUT、DELETE、HEAD、OPTIONS的請(qǐng)求 可用性、正確性、響應(yīng)時(shí)間為三大重性能指標(biāo)

性能監(jiān)控

全面監(jiān)控網(wǎng)頁性能，DNS響應(yīng)時(shí)間、HTTP建立連接時(shí)間、頁面性能指數(shù)、響應(yīng)時(shí)間、可用率、元素大小等

業(yè)務(wù)監(jiān)控

沒有業(yè)務(wù)指標(biāo)監(jiān)控的監(jiān)控平臺(tái)，不是一個(gè)完善的監(jiān)控平臺(tái)，通常在我們的監(jiān)控系統(tǒng)中，必須將我們重要的業(yè)務(wù)指標(biāo)進(jìn)行監(jiān)控，并設(shè)置閾值進(jìn)行告警通知。比如電商行業(yè)：

每分鐘產(chǎn)生多少訂單， 每分鐘注冊(cè)多少用戶， 每天有多少活躍用戶， 每天有多少推廣活動(dòng)， 推廣活動(dòng)引入多少用戶， 推廣活動(dòng)引入多少流量， 推廣活動(dòng)引入多少利潤(rùn)， 等等 重要指標(biāo)都可以加入zabbix上，然后通過screen展示。

監(jiān)控報(bào)警

故障報(bào)警通知的方式有很多種，當(dāng)然我們最常用的還是短信，郵件

報(bào)警處理

一般報(bào)警后我們故障如何處理，首先，我們可以通過告警升級(jí)機(jī)制先自動(dòng)處理，比如nginx服務(wù)down了，可以設(shè)置告警升級(jí)自動(dòng)啟動(dòng)nginx。但是如果一般業(yè)務(wù)出現(xiàn)了嚴(yán)重故障，我們通常根據(jù)故障的級(jí)別，故障的業(yè)務(wù)，來指派不同的運(yùn)維人員進(jìn)行處理。當(dāng)然不同業(yè)務(wù)形態(tài)、不同架構(gòu)、不同服務(wù)可能采用的方式都不同，這個(gè)沒有一個(gè)固定的模式套用。

面試監(jiān)控

在運(yùn)維面試中，常常會(huì)被問題監(jiān)控相關(guān)的問題，那么這個(gè)問題到底該如何來回答，我針對(duì)本文給大家提供了一個(gè)簡(jiǎn)單的回答思路。

硬件監(jiān)控。通過SNMP來進(jìn)行路由器交換機(jī)的監(jiān)控(這些可以跟一些廠商溝通來了解如何做)、服務(wù)器的溫度以及其他，可以通過IPMI來實(shí)現(xiàn)。當(dāng)然如果沒有硬件全都是云，直接跳過這一步驟。系統(tǒng)監(jiān)控。如CPU的負(fù)載，上下文切換、內(nèi)存使用率、磁盤讀寫、磁盤使用率、磁盤inode使用率。當(dāng)然這些都是需要配置觸發(fā)器，因?yàn)槟J(rèn)太低會(huì)頻繁報(bào)警。

3.服務(wù)監(jiān)控。比如公司用的LNMP架構(gòu)，nginx自帶Status模塊、PHP也有相關(guān)的Status、MySQL的話可以通過percona官方工具來進(jìn)行監(jiān)控。Redis這些通過自身的info獲取信息進(jìn)行過濾等。方法都類似。要么服務(wù)自帶。要么通過腳本來實(shí)現(xiàn)想監(jiān)控的內(nèi)容，以及報(bào)警和圖形功能。

4.網(wǎng)絡(luò)監(jiān)控。如果是云主機(jī)又不是跨機(jī)房，那么可以選擇不監(jiān)控網(wǎng)絡(luò)。當(dāng)然你說我們是跨機(jī)房以及如何如何。推薦使用smokeping來做網(wǎng)絡(luò)相關(guān)的監(jiān)控。或者直接交給你們的網(wǎng)絡(luò)工程師來做，因?yàn)樾g(shù)業(yè)有專攻。

5.安全監(jiān)控。如果是云主機(jī)可以考慮使用自帶的安全防護(hù)。當(dāng)然也可以使用iptables。如果是硬件，那么推薦使用硬件防火墻。使用云可以購(gòu)買防DDOS，避免出現(xiàn)故障導(dǎo)致down機(jī)一天。如果是系統(tǒng)，那么權(quán)限、密碼、備份、恢復(fù)等基礎(chǔ)方案要做好。web同時(shí)也可以使用Nginx+Lua來實(shí)現(xiàn)一個(gè)web層面的防火墻。當(dāng)然也可以使用集成好的openresty。

6.Web監(jiān)控。web監(jiān)控的話題其實(shí)還是很多。比如可以使用自帶的web監(jiān)控來監(jiān)控頁面相關(guān)的延遲、js響應(yīng)時(shí)間、下載時(shí)間、等等。這里我推薦使用專業(yè)的商業(yè)軟件,監(jiān)控寶或聽云來實(shí)現(xiàn)。畢竟人家全國(guó)各地都有機(jī)房。（如果本身是多機(jī)房那就另說了）

如果是web的話可以使用監(jiān)控Nginx的50x、40x的錯(cuò)誤日志，PHP的ERROR日志。其實(shí)這些需求無非是，收集、存儲(chǔ)、查詢、展示，我們其實(shí)可以使用開源的ELKstack來實(shí)現(xiàn)。Logstash（收集）、elasticsearch（存儲(chǔ)+搜索）、kibana（展示）

8.業(yè)務(wù)監(jiān)控。我們上面做了那么多，其實(shí)最終還是保證業(yè)務(wù)的運(yùn)行。這樣我們做的監(jiān)控才有意義。所以業(yè)務(wù)層面這塊的監(jiān)控需要和開發(fā)以及總監(jiān)開會(huì)討論，監(jiān)控比較重要的業(yè)務(wù)指標(biāo)，（需要開會(huì)確認(rèn)）然后通過簡(jiǎn)單的腳本就可以實(shí)現(xiàn)，最后設(shè)置觸發(fā)器即可

9.流量分析。平時(shí)我們分析日志都是拿awk sed xxx一堆工具來實(shí)現(xiàn)。這樣對(duì)我們統(tǒng)計(jì)ip、pv、uv不是很方便。那么可以使用百度統(tǒng)計(jì)、google統(tǒng)計(jì)、商業(yè)，讓開發(fā)嵌入代碼即可。為了避免隱私也可以使用piwik來做相關(guān)的流量分析。

10.可視化。通過screen以及引入一些第三方的庫來美化界面，同時(shí)我們也需要知道，訂單量突然增加、突然減少?；蛘哒f突然來了一大波流量，這流量從哪兒來，是不是推廣了，還是被攻擊了。可以結(jié)合監(jiān)控平來梳理各個(gè)系統(tǒng)之間的業(yè)務(wù)關(guān)系。

11.自動(dòng)化監(jiān)控。如上我們做了那么多的工作，當(dāng)然不能是一臺(tái)一臺(tái)的來加key實(shí)現(xiàn)?？梢酝ㄟ^Zabbix的主動(dòng)模式以及被動(dòng)模式來實(shí)現(xiàn)。當(dāng)然最好還是通過API來實(shí)現(xiàn)。

監(jiān)控如何精準(zhǔn)實(shí)時(shí)的覆蓋

監(jiān)控建設(shè)需要解決的兩個(gè)核心問題就是：優(yōu)先用戶發(fā)現(xiàn)問題和快速定位解決問題。

如何優(yōu)先用戶發(fā)現(xiàn)問題：需要具備監(jiān)控的眼睛足夠多，針對(duì)運(yùn)維對(duì)象從物理設(shè)備、系統(tǒng)組件以及應(yīng)用層對(duì)象能夠全面覆蓋，以及針對(duì)不斷增長(zhǎng)的運(yùn)維對(duì)象能夠持續(xù)擴(kuò)展。

如何快速定位解決問題：不僅需要針對(duì)告警信息的多維關(guān)聯(lián)分析，同時(shí)還需具備針對(duì)告警事件的閉環(huán)處理以及故障自愈管理，支撐運(yùn)維人員快速解決故障。

平臺(tái)化監(jiān)控設(shè)計(jì)

基于傳統(tǒng)建設(shè)監(jiān)控系統(tǒng)的方式，你會(huì)發(fā)現(xiàn)如果想要覆蓋全面的運(yùn)維對(duì)象，所需建設(shè)各種場(chǎng)景監(jiān)控系統(tǒng)就會(huì)越來越多，海量無效的告警事件接踵而來，同時(shí)圍繞同一故障的告警信息都分布在各個(gè)監(jiān)控系統(tǒng)中，這么一來就很難實(shí)現(xiàn)快速的告警定位分析。

為了滿足不斷變化的監(jiān)控需求，我們得換一種建設(shè)思路，通過平臺(tái)+場(chǎng)景的建設(shè)思路，不僅能夠滿足監(jiān)控覆蓋全面性的要求，還能夠持續(xù)擴(kuò)展監(jiān)控場(chǎng)景以滿足變化的需求。

監(jiān)控平臺(tái)

聚焦監(jiān)控?cái)?shù)據(jù)鏈路能力，從數(shù)據(jù)采集 → 數(shù)據(jù)存儲(chǔ) → 數(shù)據(jù)加工 → 數(shù)據(jù)監(jiān)測(cè) → 告警管理 → 故障閉環(huán) → 監(jiān)控可視化能力。

數(shù)據(jù)采集：監(jiān)控?cái)?shù)據(jù)采集類型包括指標(biāo)（Metrics）、日志（Logs）、跟蹤（Trace），針對(duì)不同的數(shù)據(jù)采用的數(shù)據(jù)采集方式也不同，如：Agent代理采集、腳本插件采集、日志采集、協(xié)議采集、進(jìn)程采集、Web撥測(cè)、APM探針以及API接口等。

因此在考慮監(jiān)控平臺(tái)采集能力設(shè)計(jì)的時(shí)候，需要具備靈活擴(kuò)展的采集器擴(kuò)展能力，能夠支持適配當(dāng)下主流監(jiān)控系統(tǒng)的不同采集器的方法。

數(shù)據(jù)存儲(chǔ)：

數(shù)據(jù)分析：針對(duì)監(jiān)控?cái)?shù)據(jù)分析能力，包括數(shù)據(jù)清洗、數(shù)據(jù)豐富、數(shù)據(jù)計(jì)算以及數(shù)據(jù)檢測(cè)能力，如數(shù)據(jù)豐富過程中的CMDB字段豐富，數(shù)據(jù)計(jì)算支持各種運(yùn)算規(guī)則（AVG\SUM\MAX\MIN\COUNT），數(shù)據(jù)檢測(cè)支持靜態(tài)閾值、同比、環(huán)比以及機(jī)器學(xué)習(xí)擴(kuò)展。

告警管理：

提供告警事件的統(tǒng)一管理，包括告警收斂、告警聚合、告警屏蔽以及告警通知等功能：告警聚合：支持按對(duì)象進(jìn)行聚合、按應(yīng)用進(jìn)行聚合、按時(shí)間進(jìn)行聚合、基于CMDB拓?fù)潢P(guān)系進(jìn)行聚合、以及按負(fù)責(zé)人進(jìn)行聚合。告警屏蔽：支持變更維護(hù)期內(nèi)告警屏蔽，屏蔽維度支持時(shí)間、對(duì)象、策略等。告警通知：支持微信、短信、語言、郵件告警通知，以及API或自定義渠道通知。

故障閉環(huán)：實(shí)現(xiàn)告警事件的快速跟進(jìn)和閉環(huán)管理，如對(duì)接工單系統(tǒng)自動(dòng)生成事件工單，對(duì)接自動(dòng)化系統(tǒng)實(shí)現(xiàn)故障自愈。

監(jiān)控可視化：基于監(jiān)控視圖的可視化展示，實(shí)時(shí)展現(xiàn)監(jiān)控對(duì)象的狀態(tài)信息以及告警事件的信息。

監(jiān)控場(chǎng)景

基于監(jiān)控指標(biāo)數(shù)據(jù)采集能力，以及監(jiān)控后臺(tái)的數(shù)據(jù)存儲(chǔ)和監(jiān)測(cè)分析能力，構(gòu)建各種運(yùn)維對(duì)象的監(jiān)控場(chǎng)景，如硬件監(jiān)控、云監(jiān)控、系統(tǒng)監(jiān)控、組件監(jiān)控、日志監(jiān)控，以及應(yīng)用服務(wù)和性能監(jiān)控等。

硬件設(shè)備監(jiān)控：監(jiān)控對(duì)象：網(wǎng)絡(luò)設(shè)備、存儲(chǔ)設(shè)備、物理機(jī)；采集方式：基于通用協(xié)議采集SNMP、IPMI。

云監(jiān)控：監(jiān)控對(duì)象：虛擬化、私有云公有云平臺(tái)健康性，以云產(chǎn)品的容量、性能監(jiān)控；采集方式：基于云平臺(tái)API采集插件。

系統(tǒng)組件監(jiān)控：采集方式：基于Agent、腳本、插件采集，支持持續(xù)擴(kuò)展。監(jiān)控對(duì)象：應(yīng)用網(wǎng)站服務(wù)、應(yīng)用協(xié)議服務(wù)以及C\S應(yīng)用可用性；采集方式：基于Selenium、RPA技術(shù)，持續(xù)擴(kuò)展腳本、協(xié)議以及模擬采集。

日志監(jiān)控：監(jiān)控對(duì)象：文本日志、系統(tǒng)日志，關(guān)鍵字的監(jiān)控；采集方式：基于系統(tǒng)層日志采集。

應(yīng)用性能監(jiān)控：監(jiān)控對(duì)象：應(yīng)用性能、調(diào)用鏈分析、接口調(diào)用分析等；采集方式：APM探針或應(yīng)用SDK。

智能監(jiān)控有效延展

運(yùn)維監(jiān)控的建設(shè)，從系統(tǒng)化 → 平臺(tái)化 → 智能化的演進(jìn)過程， 基于平臺(tái)化的集中監(jiān)控?cái)?shù)據(jù)管理，賦予運(yùn)維大數(shù)據(jù)平臺(tái)的數(shù)據(jù)分析、數(shù)據(jù)開發(fā)、數(shù)據(jù)建模的能力，實(shí)現(xiàn)體系化智能監(jiān)控場(chǎng)景，如動(dòng)態(tài)閾值、異常檢測(cè)、根因定位以及容量預(yù)測(cè)等。

企業(yè)統(tǒng)一監(jiān)控建設(shè)階段

第一階段：統(tǒng)一告警事件管理

基于企業(yè)現(xiàn)有運(yùn)維體系的建設(shè)現(xiàn)狀，多多少少都已經(jīng)有了各種監(jiān)控工具系統(tǒng)的建設(shè)，有些是采用傳統(tǒng)商用監(jiān)控系統(tǒng)，如IBM_Tivovi、HP_OVO、SCOM、SolarWinds、聽云、Dynatrace等，也有些是采用開源監(jiān)控系統(tǒng)，如Zabbix、Prometheus、Pinpoint等。

基于已建設(shè)監(jiān)控系統(tǒng)現(xiàn)狀，監(jiān)控系統(tǒng)覆蓋已經(jīng)達(dá)到一定程度，但運(yùn)維人員面臨的痛點(diǎn)問題更多是海量告警、無效告警等，因此可以優(yōu)先考慮告警事件的統(tǒng)一管理，實(shí)現(xiàn)告警事件的閉環(huán)管理。

告警源接入，支持各種常用監(jiān)控系統(tǒng)集成，以及標(biāo)準(zhǔn)告警事件API接口：

告警事件，集成企業(yè)ITSM系統(tǒng)，自動(dòng)創(chuàng)建事件工單：

實(shí)現(xiàn)整體告警事件的端到端閉環(huán)管理：

第二階段：集中監(jiān)控?cái)?shù)據(jù)處理

基于企業(yè)級(jí)監(jiān)控平臺(tái)的設(shè)計(jì)，通過可擴(kuò)展的統(tǒng)一監(jiān)控采集插件能力，持續(xù)建設(shè)監(jiān)控覆蓋面，同時(shí)基于平臺(tái)層的數(shù)據(jù)鏈路服務(wù)能力，建設(shè)集中多維度數(shù)據(jù)分析服務(wù)以及監(jiān)控?cái)?shù)據(jù)倉庫，從而支撐企業(yè)上層運(yùn)維端、用戶端的個(gè)性化監(jiān)控場(chǎng)景。

自有監(jiān)控平臺(tái)化數(shù)據(jù)鏈路能力：

監(jiān)控系統(tǒng)數(shù)據(jù)集成，構(gòu)建集中數(shù)據(jù)倉庫，實(shí)現(xiàn)數(shù)據(jù)智能分析和建模能力賦能：

基于后臺(tái)監(jiān)控?cái)?shù)據(jù)服務(wù)能力，構(gòu)架個(gè)性化場(chǎng)景監(jiān)控工具系統(tǒng)：

第三階段：一體化運(yùn)維監(jiān)控平臺(tái)

基于企業(yè)ITOM運(yùn)維管理一體化建設(shè)中，監(jiān)控平臺(tái)與周邊運(yùn)維系統(tǒng)，如配置管理、云資源管理、運(yùn)維流程管理以及自動(dòng)化管理，彼此相互依賴及融合。

Zabbix與Prometheus對(duì)比

這部分來自 dbaplus 社群特別邀請(qǐng)到美圖SRE負(fù)責(zé)人-石鵬(東方德勝) 作為主持人、 招商銀行技術(shù)經(jīng)理-蔡翔華 作為 Zabbix 使用方、 甜橙金融基礎(chǔ)技術(shù)架構(gòu)師-劉宇 作為 Prometheus 使用方，針對(duì) Zabbix 和 Prometheus 展開實(shí)用選型探討。

Q1：Zabbix和Prometheus分別適用于多大規(guī)模的監(jiān)控場(chǎng)景？超過5000以上監(jiān)控節(jié)點(diǎn)時(shí)怎么辦？高可用怎么解決？

蔡翔華：我們和Zabbix官方其實(shí)有溝通過，業(yè)內(nèi)他們有一些監(jiān)控到了40萬以上的節(jié)點(diǎn)數(shù)，當(dāng)然這個(gè)節(jié)點(diǎn)數(shù)也要根據(jù)你每個(gè)節(jié)點(diǎn)上監(jiān)控多少東西。Zabbix其實(shí)有一個(gè)指標(biāo)叫做NVPS（New Value Per Second），也就是每秒新增的值的指標(biāo)，來判斷你的監(jiān)控規(guī)模是不是合適的。

那么對(duì)于5000個(gè)節(jié)點(diǎn)以上的場(chǎng)景來說，其實(shí)Zabbix還是OK的，你可以通過多布署一些Proxy，去對(duì)后臺(tái)數(shù)據(jù)庫做一些性能調(diào)優(yōu)等等，以這些方式去提高整個(gè)監(jiān)控平臺(tái)的可承受、負(fù)載的性能。

另外關(guān)于高可用，我們的數(shù)據(jù)庫端是會(huì)有Mycat或者HAProxy高可用，但服務(wù)器端本身它其實(shí)沒有高可用，那么我們可以依賴于虛擬化平臺(tái)，或者是比如像我們有Vmotion等熱遷移這些技術(shù)。另外，在未來的5.x版本或者6版本以上的話，官方已經(jīng)將原生的高可用納入到Zabbix的Roadmap里面了，大家可以期待一下。

石鵬：好的，蔡老師的核心觀點(diǎn)其實(shí)就是我們需要關(guān)注核心的指標(biāo)，也就是NVPS，這個(gè)值是比較關(guān)鍵的。然后蔡老師之前您在實(shí)際的應(yīng)用中，見過這個(gè)系統(tǒng)的峰值可以達(dá)到多少嗎？是否可以給大家做個(gè)參考？

蔡翔華：在我們自己的環(huán)境里面，NVPS峰值達(dá)到過6000以上，但我們后面其實(shí)也做了一些優(yōu)化，把它調(diào)整到3000左右。主要目的是，因?yàn)橐婚_始我們做的時(shí)候是希望做到大而全，什么都監(jiān)控，但最后發(fā)現(xiàn)其實(shí)大而全不一定有用，因?yàn)楹芏啾O(jiān)控即使它是問題，你也不會(huì)care它。

劉宇：是的，蔡老師已經(jīng)講得比較詳細(xì)了，其實(shí)以多大的規(guī)模是取決于你的監(jiān)控目標(biāo)，還有就是采集的間隔，比如說5秒采集一次和1分鐘采集一次，這個(gè)規(guī)模都是支持著不一樣的目標(biāo)，所以還是要根據(jù)你的需求。

一般來說，我們會(huì)配置成30秒或者是一分鐘；如果是對(duì)于高頻的，會(huì)15秒。因?yàn)閱蝹€(gè)Prometheus性能已經(jīng)比較強(qiáng)了，一般來說，它每秒百萬個(gè)指標(biāo)都是沒什么問題的。Prometheus會(huì)根據(jù)你的指標(biāo)來計(jì)算，就是看你一個(gè)監(jiān)控點(diǎn)上有多少個(gè)指標(biāo)，這樣來換算。

如果你單個(gè)Prometheus的性能達(dá)不到它的要求時(shí)，也可以去做一些拆分，比如說我們把Prometheus根據(jù)它的功能來做區(qū)分，這個(gè)去監(jiān)控node exporter，那個(gè)去監(jiān)控Redis，這樣來做區(qū)分。

當(dāng)然，如果你單個(gè)的性能還是不夠的話，可以用分區(qū)，即用hash mod去多分幾個(gè)Prometheus來做監(jiān)控。

然后關(guān)于高可用這塊，其實(shí)社區(qū)Prometheus這部分做得也不是特別好，會(huì)用兩個(gè)Prometheus來同時(shí)監(jiān)控同樣的一個(gè)目標(biāo)，這樣來做到一個(gè)高可用。當(dāng)然，在容器環(huán)境，你也可以去通過K8S的deployment這種方式，來把高可用維護(hù)起來。

Q2：Zabbix和Prometheus怎么解決存儲(chǔ)問題？對(duì)于監(jiān)控信息是否有歷史存儲(chǔ)和分析，能從歷史信息中挖掘到哪些有價(jià)值的信息？

蔡翔華：的確，存儲(chǔ)這個(gè)問題因?yàn)楸O(jiān)控寫的東西最多就是寫到存儲(chǔ)里面去，Zabbix以前被吐槽最多的就是它不支持時(shí)序數(shù)據(jù)庫TSDB。其實(shí)在4.2以后，它就已經(jīng)開始支持TSDB了，當(dāng)然可能還沒有Prometheus那么成熟，它主要的數(shù)據(jù)庫還是MySQL為主。

如果就存儲(chǔ)問題的話，一方面你可以去嘗試TSDB的這種方式；另外一方面的話，你可以去通過增加SSD，或者說數(shù)據(jù)庫層面的一些性能提升，去解決它的問題。包括數(shù)據(jù)庫本身可以去分庫分表，去拆分一下，然后對(duì)歷史數(shù)據(jù)做一個(gè)歸檔……就是通過數(shù)據(jù)庫層面的優(yōu)化，來解決這個(gè)問題。

那么對(duì)于歷史存儲(chǔ)和分析這些信息，Zabbix提供了兩個(gè)維度，一個(gè)叫history，一個(gè)叫trend，也就是一個(gè)歷史數(shù)據(jù)和趨勢(shì)數(shù)據(jù)。它具體數(shù)值是可以自己設(shè)定的，它的邏輯是說，如果超過history的保留期限，比如說30天，它自動(dòng)會(huì)把數(shù)據(jù)歸檔成trend的數(shù)據(jù)，trend的數(shù)據(jù)就會(huì)只會(huì)保留最大值、最小值和平均值這三個(gè)指標(biāo)，而并不能像history數(shù)據(jù)可以看到每一秒鐘，甚至說每一個(gè)輪巡周期的指標(biāo)。

我們實(shí)際場(chǎng)景應(yīng)用的話，主要是用于我們的性能分析，因?yàn)槲覀冇泻芏嗷ヂ?lián)網(wǎng)應(yīng)用，會(huì)看一下這個(gè)業(yè)務(wù)增長(zhǎng)對(duì)我平臺(tái)的要求，會(huì)不會(huì)CPU比較緊張、內(nèi)存比較緊張等等。另外，我們會(huì)根據(jù)這些數(shù)據(jù)做一個(gè)分析，為我們后期的擴(kuò)容、決策提供一些參考性的依據(jù)。比方說我現(xiàn)在看到今年整體的使用率在多少，我們每年的增長(zhǎng)量是在20%還是30%，這樣我們后續(xù)做一些決策的時(shí)候，是需要多少的資源、多少的預(yù)算，就比較能有參考價(jià)值。

劉宇：Prometheus本身存儲(chǔ)如果存在本地的話，大概只能存15天，最多你也只能放到30天這樣子。官方其實(shí)也不建議你把所有的監(jiān)控?cái)?shù)據(jù)都存在Prometheus的一個(gè)本地的數(shù)據(jù)庫里。

我們是存在InfluxDB的，也有一些是可以存在比如說ES，通過remote_write的功能去存到ES或者是其它時(shí)序數(shù)據(jù)庫中，或者是比如說HBase這種大數(shù)據(jù)的也可以存。

石鵬：好的了解，其實(shí)關(guān)于存儲(chǔ)這個(gè)問題，我們還是更多應(yīng)該從需求出發(fā)。整體來看有一些比較通用的思路，最典型的就是這兩種：

第一種是數(shù)據(jù)的轉(zhuǎn)儲(chǔ)。比如像Prometheus，我們?cè)诒镜刂淮?周或者4周的數(shù)據(jù)，然后更多的話，就把它寫到遠(yuǎn)端。

第二種思路是做數(shù)據(jù)采樣。其實(shí)在很多監(jiān)控系統(tǒng)里面，是一個(gè)比較常規(guī)的思路，就像在Zabbix里的history、trend，開始可能是每30秒一個(gè)點(diǎn)，然后數(shù)據(jù)采樣之后，可能是每5分鐘一個(gè)點(diǎn)。就用這樣的方式，把這個(gè)數(shù)據(jù)量級(jí)減小，然后以此來做存儲(chǔ)問題的優(yōu)化。

Q3：Zabbix和Prometheus怎么應(yīng)對(duì)告警風(fēng)暴和誤報(bào)？

蔡翔華：首先誤報(bào)這個(gè)事情，其實(shí)在我理解里是不存在的。也就是說，之所以我們會(huì)覺得很多有誤報(bào)的東西存在，是因?yàn)槲覀儗?duì)于規(guī)則，比方說我監(jiān)控東西或者是我配置觸發(fā)器，本身是有問題的。

我碰到很多人說，打算監(jiān)控它的CPU使用率，很多人會(huì)直接記錄usage，它的使用率，也有很多人會(huì)監(jiān)控它的free的這個(gè)space。但有時(shí)候會(huì)由于配置錯(cuò)誤，導(dǎo)致原本監(jiān)控cpu usage的使用了cpu free的指標(biāo)。所以說，其實(shí)很多時(shí)候報(bào)警之所以會(huì)產(chǎn)生誤報(bào)，是因?yàn)榕渲帽旧聿皇呛苷_。

Zabbix的工作機(jī)制很簡(jiǎn)單：我去收集數(shù)據(jù)，去根據(jù)這個(gè)處罰規(guī)則去做比較，然后去發(fā)報(bào)警。當(dāng)中所有的邏輯其實(shí)本身是不會(huì)出任何問題，除非說收集數(shù)據(jù)配錯(cuò)了、觸發(fā)規(guī)則配錯(cuò)了、報(bào)警機(jī)制配錯(cuò)了……這些其實(shí)更多是人為的因素在里面。

所以說，更多的是要通過這種檢查來判斷一下你是否有配錯(cuò)。

另外一個(gè)減少誤報(bào)的方式是通過模板化。因?yàn)槲覀冎灰渲靡淮文０澹俏野阉械腖inux機(jī)型的監(jiān)控模板都統(tǒng)一起來，對(duì)于所有監(jiān)控Linux都套用同一個(gè)模板，那么就可以在一定程度上降低誤報(bào)。關(guān)鍵還是在于人的問題。

關(guān)于告警風(fēng)暴，其實(shí)Zabbix里有一個(gè)特性叫做依賴項(xiàng)目。就比方說我現(xiàn)在有一臺(tái)機(jī)器宕機(jī)，那么它可能里面的端口都會(huì)不通，然后ping也ping不通，CPU可能也拿不到，可能會(huì)有一堆的報(bào)警。那么我們可以把所有的這種依賴項(xiàng)關(guān)聯(lián)到ping上，一旦ping的機(jī)器都死了，上面肯定東西都是宕掉了，這樣子的話，它只會(huì)報(bào)ping的這一個(gè)問題，而不會(huì)把這堆機(jī)器上所有的東西都給報(bào)出來。就好比一個(gè)人如果死了，你跟他說這里有問題那里有問題，其實(shí)沒有任何意義。它就只會(huì)把你最終的Root Cause（根因）給報(bào)出來，去防范這種告警風(fēng)暴。

劉宇：是的，誤報(bào)我其實(shí)跟蔡老師的觀點(diǎn)是很像的，就是告警中其實(shí)是存在一個(gè)誤報(bào)率的，如果你的誤報(bào)率很高的話，運(yùn)維人員就很疲勞了，可能大家都會(huì)覺得狼來了，沒有辦法信任你的那種告警，反而你真正發(fā)生故障的告警就會(huì)被忽略掉。所以制定告警的規(guī)則就非常重要，需要想辦法把誤報(bào)率給它降低。

那這種規(guī)則的制定其實(shí)就比較不是那么具體，會(huì)比較抽象，可能比如說把必須要人工介入處理的這種，才把它定為告警；然后如果系統(tǒng)可以自己處理掉，就不要把它告出來，或者只是在后面做一個(gè)每天發(fā)一次的報(bào)告也就行了。這是我對(duì)誤報(bào)的一個(gè)看法。

關(guān)于告警風(fēng)暴，在Prometheus中，對(duì)告警風(fēng)暴的處理方式是這樣：可以通過靜默告警解決，或者是可以加入維護(hù)組，或者是也可以做一個(gè)聚合，也就是把告警給聚集，然后同類的告警合并，這樣來減少告警的條數(shù)，主要是這樣來做的。

當(dāng)然如果你有些機(jī)器需要維護(hù)，它也是可以支持的，就是可以把一些告警直接靜默掉。當(dāng)然還有就是測(cè)試環(huán)境，比如說這種告警，你就可以完全忽略掉，我覺得可以這樣來解決。

石鵬：好的，我總結(jié)一下，關(guān)于誤報(bào)這個(gè)問題，兩位老師的意見是比較一致的，我也是比較贊同的。誤報(bào)其實(shí)最根本的原因就是可能你的使用不合理，不管是你的配置還是說你的各種姿勢(shì)可能不合理，才會(huì)導(dǎo)致誤報(bào)。

然后針對(duì)告警風(fēng)暴，其實(shí)Zabbix和Prometheus也就是alert manager，它們都有提供一些相應(yīng)的功能、特性。在Zabbix這邊的話，可以像蔡老師說的用依賴項(xiàng)，然后也是可以加維護(hù)，也可以規(guī)避一些告警；然后Prometheus這邊是alert manager它里面有silent這個(gè)靜默規(guī)則，也是可以去做一些規(guī)避告警這種東西。

可能在很多公司，他們除了監(jiān)控平臺(tái)本身去做告警風(fēng)暴的抑制，還會(huì)有另外一層。比如說我們公司這邊是這樣：

我們有一個(gè)告警平臺(tái)，所有的告警都會(huì)匯集到這個(gè)告警平臺(tái)里，然后這個(gè)告警平臺(tái)會(huì)去做一層合并、收斂和抑制。這樣的話，就可以不用特別依賴監(jiān)控平臺(tái)本身來提供這些特性，而是由一個(gè)統(tǒng)一的平臺(tái)，在做最后發(fā)送動(dòng)作的時(shí)候，再來做一層cover?？赡茉诹考?jí)大的場(chǎng)景下，這種是比較推薦的一種思路。

蔡翔華：是的，因?yàn)檎嬲谋O(jiān)控當(dāng)中，其實(shí)還會(huì)納入很多比方說ES等其它監(jiān)控平臺(tái)，甚至是一些業(yè)務(wù)告警。當(dāng)平臺(tái)很多的時(shí)候，其實(shí)你需要有一層聚合的方式，去把告警做一個(gè)聚合收斂，然后通過在聚合平臺(tái)里配置一定規(guī)則之后，再去做后續(xù)的一些報(bào)警。

石鵬：沒錯(cuò)，并且你有這個(gè)平臺(tái)之后，就可以把一些告警的規(guī)則和策略做得更統(tǒng)一，這樣的話，給用戶的界面和體驗(yàn)也會(huì)更好。

蔡翔華：對(duì)，所以說其實(shí)看公司規(guī)模，因?yàn)檫@一塊會(huì)涉及到一些二次開發(fā)，如果公司沒有這個(gè)能力，那就可以把Zabbix全套或Prometheus全套都用上；如果后續(xù)有能力去做這種聚合的話，其實(shí)Zabbix也好，Prometheus也好，更多的角色定位會(huì)變成一個(gè)收集器的角色。然后后面的邏輯其實(shí)都交給事件管理平臺(tái)或聚合平臺(tái)去做。

劉宇：沒錯(cuò)，這里Zabbix其實(shí)也可以把它的報(bào)警發(fā)送到alert manager里，也可以做一些靜默處理，因?yàn)閆abbix本身它的靜默功能確實(shí)不是特別多，還是alert manager會(huì)做的更好一點(diǎn)。所以兩個(gè)工具其實(shí)可以結(jié)合起來使用。

Q4：在智能監(jiān)控和自動(dòng)治愈方面是否有可借鑒的實(shí)踐？基于什么算法或策略？怎么進(jìn)行故障預(yù)判和預(yù)處理？

蔡翔華：首先我們是有嘗試過智能監(jiān)控，但是包括我看到的很多書籍里面，包括Prometheus的一些書籍里面，也說設(shè)這種固定的預(yù)知是一個(gè)很蠢的方法。

根據(jù)我這邊實(shí)際的應(yīng)用，其實(shí)你要做到智能監(jiān)控，肯定要有一些大數(shù)據(jù)的東西，比方說我有這種規(guī)律：

例如，按照我們的實(shí)際操作里有很多互聯(lián)網(wǎng)的應(yīng)用，有些東西它就是會(huì)有高并發(fā)高搶購(gòu)，可能每個(gè)月固定的時(shí)候，比如每個(gè)月10號(hào)放一個(gè)活動(dòng)，活動(dòng)時(shí)它的量是平時(shí)的10倍甚至100倍；但也可能有時(shí)候，業(yè)務(wù)會(huì)不停地在不同的時(shí)間放，你很難去判斷這個(gè)點(diǎn)到底是不是一個(gè)故障點(diǎn)。

也就是說，你用戶數(shù)從10變成了1萬，這1萬到底是因?yàn)楣收狭耍€是說是因?yàn)闃I(yè)務(wù)的一些邏輯導(dǎo)致的，很難判斷。所以目前來說，我們嘗試以后，還是用了一些比較固定的報(bào)警預(yù)知去做。

那么回到這個(gè)話題，Zabbix本身它提供了一些預(yù)測(cè)的功能，它會(huì)預(yù)測(cè)現(xiàn)在我的磁盤消耗大約什么時(shí)候會(huì)消耗到20%以下，或某個(gè)閾值以下，它本身是提供了這個(gè)功能的。還有一些內(nèi)置函數(shù)可以去做這個(gè)計(jì)算。但是目前來說，我個(gè)人還是建議使用一個(gè)比較固定的閾值，可以方便我們有一個(gè)明確判斷，否則你早期會(huì)有很多的誤報(bào)，甚至可能你都會(huì)覺得這東西很正常。

預(yù)測(cè)的數(shù)據(jù)也是基于現(xiàn)狀的，如果可以對(duì)預(yù)測(cè)數(shù)據(jù)進(jìn)行判斷報(bào)警，理論上，也可以針對(duì)現(xiàn)有的數(shù)據(jù)進(jìn)行判斷報(bào)警。

劉宇：這塊我們實(shí)踐的案例倒不是特別多，我主要還是對(duì)數(shù)據(jù)庫的監(jiān)控比較熟，所以就說一下我們?cè)跀?shù)據(jù)庫的自動(dòng)治愈上是怎么實(shí)現(xiàn)的吧。

比如說告警，它發(fā)送出來的同時(shí)，也會(huì)發(fā)送給數(shù)據(jù)庫的一個(gè)自動(dòng)化平臺(tái)，這個(gè)平臺(tái)會(huì)有一個(gè)程序根據(jù)告警內(nèi)容來調(diào)一些自動(dòng)治愈的程序來處理這種簡(jiǎn)單的故障。但這個(gè)其實(shí)做的也比較有限，就是說我的這種能夠自愈的程序，都是根據(jù)具體場(chǎng)景的，并不是所有的東西都可以做。比如說清理日志、殺讀庫大查詢，以及需要加一些表空間這些場(chǎng)景，類似這種比較固定的會(huì)采用自愈來做，其他的嘗試倒不是太多。

石鵬：嗯嗯，這個(gè)問題其實(shí)比較前沿，并且涉獵的范圍是比較廣的。像自動(dòng)治愈，其實(shí)Zabbix也有一些相關(guān)的功能，它可以去配置action，當(dāng)發(fā)現(xiàn)告警，有問題，我就可以綁定腳本去做一下處理。

但這個(gè)東西要做到什么程度，或者說要用什么技術(shù)來打造這個(gè)底座，可能都會(huì)有些差別。

蔡翔華：是的，因?yàn)槲矣X得Prometheus和Zabbix或者說其他平臺(tái)，都支持調(diào)action、調(diào)腳本去做一些重啟，但是我覺得關(guān)鍵問題的點(diǎn)是在于你敢不敢做這個(gè)事情。

因?yàn)槲覀冎牢覀兊沫h(huán)境其實(shí)是很復(fù)雜的。比方說，我發(fā)覺數(shù)據(jù)庫宕了，服務(wù)停了，我敢不敢通過這個(gè)服務(wù)自己切過去。因?yàn)楹芏鄷r(shí)候并不是數(shù)據(jù)庫本身的問題，是網(wǎng)絡(luò)的問題，網(wǎng)絡(luò)抖動(dòng)了，監(jiān)控?cái)?shù)據(jù)拿不到了。這個(gè)是非常依賴于整個(gè)整體環(huán)境的，你可能要想到方方面面，這個(gè)規(guī)則會(huì)非常復(fù)雜。你可能在做服務(wù)自愈的時(shí)候，還要去對(duì)其他的東西做一個(gè)完全的檢查，確保其他東西是沒有問題的。

所以不說服務(wù)自愈，哪怕在我們?nèi)粘５墓收咸幚懋?dāng)中，也很依賴于經(jīng)驗(yàn)。就是說這個(gè)東西是能做的，但是我們不太敢，因?yàn)橐紤]的要素很多，就不太敢去直接做自愈這一塊。

石鵬：沒錯(cuò)，本身其實(shí)它是一個(gè)體系化的工程，不僅僅是跟監(jiān)控相關(guān)。我這邊的一個(gè)想法是這樣，關(guān)于自動(dòng)治愈這塊，我們可能還是要更多去依靠業(yè)務(wù)側(cè)的能力。就是說，業(yè)務(wù)側(cè)要具備一些這種架構(gòu)設(shè)計(jì)上的考量，比如說架構(gòu)的柔性，可以自己去做限流、降級(jí)、做熔斷，這要求業(yè)務(wù)側(cè)有這樣的能力才可以，而不是說僅僅依靠監(jiān)控系統(tǒng)去做某些動(dòng)作觸發(fā)。

至于說一些算法和策略的話，之前美圖這邊也是有過一些簡(jiǎn)單的嘗試，應(yīng)用不算非常廣泛。但業(yè)界的話，DataOps、AIOps的概念也是比較火熱，這些東西在像BAT這些公司其實(shí)也有一些實(shí)際的應(yīng)用已經(jīng)在落地了。

之前我們做的話，有做這么幾個(gè)小東西，關(guān)于故障預(yù)測(cè)是有這么幾個(gè)算法：有同期的數(shù)據(jù)比較、同期的振幅比較、有一個(gè)移動(dòng)平均算法、然后再有一個(gè)變點(diǎn)監(jiān)測(cè)。然后這幾個(gè)的話，可以簡(jiǎn)單說一下思路，其實(shí)也比較好理解。

同期數(shù)據(jù)，是我按照周期，比如說今天某個(gè)時(shí)間點(diǎn)這個(gè)數(shù)據(jù)，我去比較昨天這個(gè)點(diǎn)是什么樣子的，去比較數(shù)據(jù)；

振幅，其實(shí)它就相對(duì)更柔性一點(diǎn)，里面會(huì)給你加上一個(gè)權(quán)重，加上一個(gè)比例，比如正態(tài)分布里邊的3-sigma，作為振幅系數(shù)去比較同期的數(shù)據(jù)，看在算上振幅之后，你是不是已經(jīng)超出了，去做一個(gè)預(yù)測(cè)；

變點(diǎn)監(jiān)測(cè)，就是說我整體的數(shù)據(jù)曲線是什么樣子的，突然出現(xiàn)了一個(gè)離我正常預(yù)測(cè)曲線偏離非常遠(yuǎn)的一個(gè)點(diǎn)，這種的話會(huì)有一個(gè)這樣的算法來做這個(gè)事情。

然后這塊相對(duì)比較成熟的工具的話，像騰訊之前有開源的運(yùn)維學(xué)件METIS，它里面集成了非常多的算法模型，這個(gè)有興趣的同學(xué)可以去做一些了解。

Q5：監(jiān)控大屏是怎么設(shè)計(jì)的？

蔡翔華：首先從技術(shù)本身來說，5.0版本可以看到Zabbix的UI都很不錯(cuò)，可以很多的組、主機(jī)都往大屏里面去拖。大屏的話，我們大概會(huì)分幾塊：

第一塊是整個(gè)系統(tǒng)運(yùn)行狀態(tài)。我可能整個(gè)系統(tǒng)有從用戶登錄到用戶支付，包括到購(gòu)物車等等，有一個(gè)鏈路。我對(duì)于每個(gè)鏈路其實(shí)都會(huì)有一個(gè)監(jiān)控，它每一個(gè)S組 Service的組，那么Service的組里面包括它的應(yīng)用、數(shù)據(jù)庫緩存、應(yīng)用系統(tǒng)甚至硬件服務(wù)器，一旦這里有任何東西出問題之后，直接會(huì)在大屏上顯示一個(gè)警告，那么我就會(huì)知道現(xiàn)在整個(gè)生產(chǎn)環(huán)節(jié)哪個(gè)系統(tǒng)是有問題的。

那么另外就是一個(gè)summary，一個(gè)overview的全局的導(dǎo)覽，因?yàn)橐坏┪抑肋@個(gè)有問題，我就希望更加細(xì)化知道這個(gè)東西哪里有問題。那么在下面就會(huì)有一個(gè)trigger list的問題列表，就是說有哪些觸發(fā)器被觸發(fā)了，我會(huì)看到比方說，數(shù)據(jù)庫端口不通了，還是說磁盤空間已經(jīng)滿了。下面會(huì)有trigger list，然后這個(gè)trigger list會(huì)按照故障等級(jí)是disaster還是warning，同時(shí)對(duì)應(yīng)的管理員或者運(yùn)維人員也會(huì)收到這個(gè)短信，就知道要立即去處理了。

所以我們盡可能就在大屏里從兩方面來把控，一方面從大的來講，有一個(gè)over view看到全局，從小的來講，我要知道我的故障發(fā)生在哪里。基本上保證這兩個(gè)要素在大屏里面就OK了。

劉宇：我們這邊大屏其實(shí)主要還是應(yīng)用的維度以及網(wǎng)絡(luò)流量的維度為主。比如說從公網(wǎng)的一個(gè)出口和入口的流量來看會(huì)不會(huì)有大面積的一個(gè)問題。如果發(fā)現(xiàn)已經(jīng)達(dá)到外面防火墻或者它流量的一個(gè)閾值了，就可以迅速定位問題。

如果是細(xì)節(jié)的話，我們會(huì)在大型活動(dòng)前夕，梳理活動(dòng)鏈路上的所有應(yīng)用，根據(jù)應(yīng)用的維度來設(shè)計(jì)這樣一個(gè)大屏。大屏可以看到鏈路上所有應(yīng)用、數(shù)據(jù)庫或者是中間件的情況，一旦哪個(gè)應(yīng)用的QPS高了，或者是其他壓力的情況，就可以第一時(shí)間定位到問題出現(xiàn)在哪里，是這樣一個(gè)思路來做。

石鵬：監(jiān)控大屏做得好，確實(shí)可以輔助我們技術(shù)同學(xué)去更快地定位和排查問題，還有一個(gè)比較重要的點(diǎn)，我是這么想的，就是老板會(huì)關(guān)注。有些公司會(huì)把大屏設(shè)計(jì)得非常有科技感，讓老板看的話，可能老板也覺得我的技術(shù)團(tuán)隊(duì)還挺牛的。當(dāng)然這是一個(gè)題外話。

前面蔡老師和劉老師都給了一些建設(shè)上的思路，就是你應(yīng)該去包含哪些數(shù)據(jù)，應(yīng)該怎么去做。這方面的話，我的一個(gè)思考是你可能要去做服務(wù)的梳理，然后可以以分塊、分業(yè)務(wù)或者說按照分層的方式來做。

分塊的話，就是你按照業(yè)務(wù)線來分。你公司可能有很多塊業(yè)務(wù)，然后按照不同的業(yè)務(wù)去提供一個(gè)視角。在每個(gè)業(yè)務(wù)里，你可以去做分層，分層的意思就是說可以把整個(gè)鏈路，從客戶端一直到CDN、 DNS鏈路，然后到LB入口層，以及應(yīng)用這一層是什么樣的，再關(guān)聯(lián)到后面的一些后端資源，像數(shù)據(jù)庫、緩存這些東西，還有一些其他的周邊依賴，按照這樣分層的方式來做。

關(guān)于技術(shù)實(shí)現(xiàn)方面，我簡(jiǎn)單贅述兩句。我們公司的監(jiān)控大屏是用了Grafana來做的，Grafana可能已經(jīng)成為了事實(shí)上的監(jiān)控UI、數(shù)據(jù)可視化的標(biāo)準(zhǔn)了，它可以后面去接各種各樣的數(shù)據(jù)源，然后你各個(gè)監(jiān)控系統(tǒng)、各種數(shù)據(jù)原理的數(shù)據(jù)可以統(tǒng)一來展示。

這里需要感謝一個(gè)社區(qū)的插件，叫Flow Charting，這個(gè)插件可以非常好地去做監(jiān)控鏈路的事情，就是你可以用這個(gè)插件去把整個(gè)鏈路關(guān)鍵環(huán)節(jié)，以這種圖的方式繪制出來，然后給每一個(gè)點(diǎn)、每一條線綁定上監(jiān)控?cái)?shù)據(jù)，最后生成的圖就動(dòng)起來了，就可以看到一個(gè)全局性的鏈路狀態(tài)：從入口一直到后端資源，包括各種依賴，當(dāng)前它的狀態(tài)是什么樣子的。

當(dāng)然這個(gè)前提是，你整個(gè)鏈路的監(jiān)控?cái)?shù)據(jù)是要完備的，然后你才可以借助這個(gè)插件去把它呈現(xiàn)出來，大概是這個(gè)樣子的，在這個(gè)圖上就一目了然了。

Q6：自動(dòng)化運(yùn)維管理是Zabbix和Prometheus同時(shí)使用還是二選一更合適？

蔡翔華：如果是個(gè)純?nèi)萜骰?，就說你環(huán)境里面全是Docker，那么說實(shí)話我也不推薦你去使用Zabbix。

因?yàn)閆abbix對(duì)容器的監(jiān)控，雖然官方已經(jīng)開始重視了，甚至說現(xiàn)在也支持了Prometheus的很多metrics和exporter這種方式去做監(jiān)控，就是它也可以原生的去支持Prometheus這些東西，但相對(duì)來說，Prometheus在容器化監(jiān)控這邊還是會(huì)更好一些。

如果你的監(jiān)控需求是又要監(jiān)控硬件服務(wù)器，又要監(jiān)控中間件，又要監(jiān)控業(yè)務(wù)指標(biāo)，那么我推薦使用Zabbix，因?yàn)閆abbix覆蓋的面會(huì)更廣一些。

的確我覺得任何需求Zabbix和Prometheus都可以去做，但是從實(shí)現(xiàn)成本來說，相對(duì)于Prometheus，你的服務(wù)環(huán)境越復(fù)雜，Zabbix可能就越適合這種比較復(fù)雜的異構(gòu)的環(huán)境。

劉宇：我們目前公司情況是兩個(gè)都在用，的確是偏容器的會(huì)往Prometheus優(yōu)先考慮，如果是舊的，比如說是有偏服務(wù)化的這種監(jiān)控，也會(huì)慢慢地往Prometheus做一些遷移。

如果你的環(huán)境是一種就可以滿足的話，建議還是一種，因?yàn)楫吘怪恍枰S護(hù)一種技術(shù)棧就可以了?；蛘呤悄憧梢宰鲆恍┢?，比如說把一些不變的放在一種上面，經(jīng)常會(huì)變的放在另外一種上面。盡量去減少你維護(hù)的技術(shù)棧。如果你的環(huán)境比較簡(jiǎn)單的話，只用一種，當(dāng)然是最好了。

石鵬：其實(shí)還是看場(chǎng)景，美圖跟劉老師這邊比較類似，我們也是多種監(jiān)控工具在用，不過我們現(xiàn)在沒有在用Zabbix，是用了Open-Falcon、Prometheus、InfluxDB，還有很多基于大數(shù)據(jù)的一些流式處理的組件，我們都是混合在用。

主要還是看你具體的需求和場(chǎng)景，沒有銀彈，沒有說一個(gè)工具可以非常合適去搞定所有事情。當(dāng)然它有可能有能力，但是它并不一定特別合適。至于具體的選擇上，還是要看具體場(chǎng)景。比較明確的一個(gè)思路可能就是要看你的監(jiān)控對(duì)象到底是容器還是非容器，它是這種易變的還是比較穩(wěn)定態(tài)的。這兩個(gè)思路的話，也是跟蔡老師和劉老師比較一致的。

Q7：分布式鏈路的可觀測(cè)性和端到端診斷怎么做？

蔡翔華：分布式鏈路其實(shí)我們沒有用Zabbix，因?yàn)榉植际芥溌芬紤]上下游的關(guān)系，所以我們會(huì)基于APM去做?，F(xiàn)在像業(yè)內(nèi)比較流行的CAT，可以參考這些去做。

端到端的偵測(cè)的話，其實(shí)Zabbix也支持，它支持兩種方式：

一個(gè)是它可以在本地跑一些腳本去做，就是說我這個(gè)檢測(cè)是從Zabbix某個(gè)Agen端出發(fā)，到另外一臺(tái)目標(biāo)機(jī)器，而不是通過Zabbix server去做檢測(cè)。所以說這是Zabbix 提供的另外一種方式，Zabbix active的一種方式，它可以去實(shí)現(xiàn)這種端到端的偵測(cè)。Zabbix active的監(jiān)控方式也是比較好的一種方式，可以減輕Zabbix server端的壓力，或proxy端的壓力，能提供更豐富的一些監(jiān)控。

劉宇：這塊因?yàn)镻rometheus是一個(gè)基于數(shù)值的監(jiān)控，對(duì)于這種全鏈路的話，一般不太會(huì)用Prometheus來做，基本上會(huì)用APM的一些分布式鏈路追蹤的工具，比如skywalking等來做。

還會(huì)通過一些日志系統(tǒng)來做分布式的監(jiān)控，在鏈路上，提前寫入一些標(biāo)簽，這樣從始至終都可以拿到整個(gè)鏈路上的一個(gè)關(guān)系，就可以做一些分布式鏈路上的監(jiān)控的東西。

石鵬：是的，這也就回到我們前面討論的，沒有銀彈，沒有一種技術(shù)?？梢越鉀Q所有需求的。包括Zabbix和Prometheus，其實(shí)更關(guān)注的還是在偏服務(wù)端，如果是應(yīng)用端的話，其實(shí)還是要依賴一些APM的工具。就像劉老師說的Apache的skywalking，還有像鷹眼、基于open tracing的其他工具。這些東西其實(shí)都是一種思路。

還有一些有技術(shù)能力的公司，會(huì)選擇自研一些APM工具，需要自己去開發(fā)各種SDK，然后需要遷到客戶端，去上報(bào)數(shù)據(jù)，是這個(gè)樣子的。

其實(shí)端到端整體的建設(shè)思路應(yīng)該是分段的，客戶端的是一段，中間鏈路是一段，服務(wù)端又是另外一側(cè)。所以想做端到端，很難說用一個(gè)工具就可以完全覆蓋起來。

現(xiàn)在基于云原生、微服務(wù)這些發(fā)展的比較火熱，可能會(huì)有一些各個(gè)服務(wù)之間調(diào)用鏈路的服務(wù)治理相關(guān)的監(jiān)控需求，可能也不是說通過Prometheus或Zabbix就可以很好地去完成。還是要看需求場(chǎng)景，選擇更合適的工具，并且組合起來使用。

Q8：大規(guī)模場(chǎng)景下，Prometheus和Zabbix的性能和成本哪個(gè)比較低？

蔡翔華：首先我覺得還是看應(yīng)用場(chǎng)景，因?yàn)榇笠?guī)模場(chǎng)景下，要看這個(gè)場(chǎng)景是容器多還是非容器環(huán)境多，這是一個(gè)主要依據(jù)。

Zabbix性能的話，其實(shí)瓶頸主要是在數(shù)據(jù)庫，只要把數(shù)據(jù)庫的優(yōu)化做得足夠好，其實(shí)開頭也說了，業(yè)內(nèi)也有做到40萬NVPS的這種案例，已經(jīng)是比較變態(tài)了。那無非就是說，去做數(shù)據(jù)庫分區(qū)分庫拆表、加SSD存儲(chǔ)，通過這種方式。

成本的話，我個(gè)人覺得在底層資源滿足的前提下，成本應(yīng)該都OK。因?yàn)镻rometheus是基于exporter，Zabbix是基于Agent，通過Zabbix agent，配合自動(dòng)發(fā)現(xiàn)和低級(jí)別發(fā)現(xiàn)的這種方式去實(shí)現(xiàn)自動(dòng)化。

配置成本可能Zabbix會(huì)低很多，因?yàn)槎际腔赨I去做，而Prometheus是基于配置文件去做，這個(gè)可能Zabbix會(huì)更好些。所以我綜合成本，覺得Zabbix稍微會(huì)好一些，但還是取決于你的場(chǎng)景里有多少虛擬化。

劉宇：我覺得如果是性能的話，通過一些分區(qū)的手段都能解決。但如果是非常大的規(guī)模，通過Zabbix，其實(shí)它的數(shù)據(jù)庫瓶頸還是比較嚴(yán)重的，這塊還是需要一些比較好優(yōu)化手段才能解決。

監(jiān)控采集的agent的方式而言，我覺得Prometheus的exporter做得非常全面，像我們以前用Zabbix，基本上有很多東西監(jiān)控都是自己去開發(fā)的；而現(xiàn)在用Prometheus，基本上對(duì)于這種采集器的開發(fā)都沒有了，用社區(qū)的就可以全部解決了。所以在采集的層面上，去實(shí)現(xiàn)它最底層和服務(wù)的一個(gè)數(shù)據(jù)采集，我感覺Prometheus的成本會(huì)更低一點(diǎn)。

當(dāng)然因?yàn)镻rometheus相對(duì)來說還是一個(gè)微服務(wù)的架構(gòu)，它的所有組件都是分開的，在搭建成本、學(xué)習(xí)成本會(huì)稍微高一點(diǎn)。

石鵬：其實(shí)還是要針對(duì)個(gè)性化的場(chǎng)景去做一些選擇。成本的話，如果說你的環(huán)境是一個(gè)比較純粹的，要么是全容器，要么是虛擬化或者物理環(huán)境，你就選一種就好了。如果說你是異構(gòu)的話，可能就不可避免的要選兩種同時(shí)維護(hù)。這兩種里如果有所側(cè)重的話，成本其實(shí)就會(huì)有所側(cè)重，所以還是看你的具體需求。