網站運維技術與實踐之數據分析與報警
對於日益積累的監控數據，顯然需要有規劃地進行存儲和分析，做到“故障沒來時有預防，故障來臨時有提示，故障到來時有解決方案”。
一、時間序列存儲
對於大多數監控數據，都有一個天然的類似數據庫主鍵的屬性，那就是時間。所以，通常情況下，各類監控系統的後臺數據庫都可以認為是時間序列的數據存儲，並由此誕生了一批針對監控數據存儲開發的數據庫，其中最有代表性是RRDtool和Graphite。
1.RRDtool(Round-Robin DataBase Tool)
Round-Robin(循環)在運維人員眼裏是一個很熟悉的詞匯。負載均衡中最基礎的算法就是Round-Robin,意即逐一循環。這個詞很形象地描繪了RRD數據庫的內部結構。
RRD數據庫是一個固定空間大小的文件，其內部可以看做一個固定刻度的圓形表盤，每個刻度存儲一個時間點的數據。表上有一個指針，永遠指向最新寫入數據的位置。指針隨著數據寫入轉動，轉完一圈後，就覆蓋掉之前的數據從頭繼續。
上面這段描述中，有一點需要單獨拿出來支出，即"指針歲隨數據寫入轉動"。這個數據寫入，並不等同於運維人員調用rrdtool命令插入數據。這也是RRD數據庫和普通數據庫一個明顯的不同-在指定的時間間隔後，如果RRD每個收到明確的數據插入請求，它依然會自行發起一次“空”數據寫入，占據這個刻度空間。這也是我們一般用鐘表比喻RRD的原因，指針實際是定時轉動的。
2.Graphite
相對1999年誕生的RRD，2006年才出生的Graphite通過與Statsd實時監控系統的結合，在最近幾年大數據的浪潮中得到迅速普及和發展。
Graphite項目包括三部分:展示圖形的graphite-web，接收和寫入數據的carbon，數據存儲引擎whisper。這裏我們先不談論graphite-web而專註於數據部分。
Graphite與RRD一脈相承，事實上，最開始的Graphite就是打算通過額外的Python腳本存取分布式的RRD文件(看起來更類似於Cacti的角色)。
但最終Graphite沒有選擇RRD而是自己用Python實現存儲引擎whisper，主要原因如下:
(1)Graphite的設計更傾向於展示數據而不是各種算法
在實際運用中，類似"網站訪問500錯誤數統計"是Graphite常見的典型需求之一。而在網站一切正常的情況下，500錯誤肯定是具有偶發性質的。這與RRD數據結構設想的“有規律的定時記錄數據”是相互沖突的。
(2)性能問題
在Graphite項目開始的時候，RRD在同一時刻，只允許往一個數據庫裏寫入一個數值，而whisper可以合並多個數值批量寫入。這樣在高負載情況下，同時操作大量文件時，Graphite就不會被“磁盤IOPS“的瓶頸限制住。不過RRDtool現在已經解決了性能問題。但是在在第一點沒有解決之前，雖然Python寫的whisper性能比C寫的rrdtool慢2~5倍，Graphite也會繼續使用自己的whisper引擎。
3.OpenTSDB
時間序列數據庫家族裏還有一個新加入的成員:HBase社區的OpenTSDB。OpenTSDB只存儲最基本的<timestamp,value>鍵值對，其余功能都依賴於HBase集群完成。有興趣的讀者可以參閱其官網，地址:http://opentsdb.net。
總的來說，從RRDtool到Graphite再到OpenTSDB,數據庫中內置的數據類型和聚合算法越來越少，數據存儲的可靠性和可擴展性越來越強。具體如何選擇，就取決於數據量大小和運維團隊二次開發能力。
二、全文搜索引擎ElasticSearch
前面說到的RRD、Graphite、OpenTSDB等，都只能存儲數值型數據，這需要我們提前先整理好數據，因此不足以應對突發性的需求。比如，網站新出現的熱門話題，我們需要關註這個話題的相關監控數據，這時候再動手創建數據庫，然後寫腳本過濾日誌，最後導入庫中繪圖，不過等到這個過程完了，恐怕就晚了。
或許大家在應對這個問題的時候，都通過搜索引擎知道了Spluck這個工具，可惜的是這不是一個開源軟件，它只提供每天索引500MB的免費試用版本。有些運維人員只好先行裁剪數據，只導入所需的部分來進行查詢，倒可以算是一種臨時抱佛腳的解決辦法。
1.簡介
ElasticSearch是一個分布式的Lucene全文搜索引擎，提供RestFul的API接口，也是最近相當流行的日誌存儲分析平臺。它提供更加強大的搜索和統計功能。
關於全文搜索的基礎原理，不了解的讀者可以參考《大規模Web服務開發技術》中的》第九章挑戰全文搜索技術 電子書的下載地址為:http://vdisk.weibo.com/s/zmzzSciGaVonL(感恩互聯網時代為我們學習提供很多渠道)
目前ElasticSearch幾個著名的客戶如下:
(1)Mozilla,自動構建和測試集群，通過Flume發送ES。
(2)Sony,采用ES進行娛樂項目的使用數、用戶評分、標題和說明等的存儲和搜索。
(3)StumbleUpon，著名社交內容推薦引擎公司，用ES索引HBase數據方便不熟悉Hadoop編程的開發人員完成搜索功能，稱上手快，1小時內搞定。
(4)Infochimps,著名大數據分析服務公司，通過ES索引超過2.5億個對象，4TB以上的Hadoop數據。
(5)Ataxo Social Inside,捷克斯洛伐克的一家社交輿情監控分析公司，從網頁數據庫到後臺分析都用ES。
(6)MetaCPAN和Github，都是代碼托管網站，用ES做開源項目代碼搜索。
ElasticSearch中文社區:https://elasticsearch.cn/
ElasticSearch權威指南下載:http://www.java1234.com/a/javaziliao/shuji/2016/0104/5478.html
2.安裝
ElaticSearch官網提供了各個版本的deb安裝包。因為ES是一個Java項目，沒有什麽動態庫依賴，所以我們可以很容易地根據deb生成rpm安裝包。
ES源代碼托管:https://github.com/elastic/elasticsearch/
也可以選擇直接下載代碼後運行./bin/elasticsearch即可
Linux安裝教程:https://blog.csdn.net/sinat_28224453/article/details/51134978
Windows安裝教程:https://www.cnblogs.com/zhangchenliang/p/4214408.html
3.集群
ES集群的部署可謂是“傻瓜式”的，唯一需要自定義的地方就是/etc/elasticsearch/elasticsearch.yml裏的cluster.name。然後，在Discovery可達的範圍內，所有的elasticsearch node會自動尋找和自己有相同cluster.name的兄弟，然後按照最樸素的先來後到的規則確定master。到此，集群就完成了。
在ES集群中，存在多種角色,如下:
(1)master node：有資格被選舉成為master的node。但是和MySQL的master-slave結構不同，ES中master的作用只是負責維護整個cluster的state,也就是nodes和shards的列表，然後通知其他所有的API，也就是常說的CRUD，都是可以直接發給集群裏任何一個master node的，這個node會自動根據請求來操作整個集群。
(2)data node：存儲數據的node。ES中，data node上有index和shard兩級實際存在的目錄。但邏輯上,index一旦創建，其shards數就不能再變更，因為ES的shard方法就是簡單的取余；而replica數是可以隨時通過API調整的。
(3)client node：如果一個node 不存儲數據，那麽它在接收到請求的時候，只能從master上獲取shards列表，然後把請求轉發給相應的data node，最後再把結果轉發回去。但本質上，client node也是cluster的一部分。在這種配置時，通常是cluster內部采用9300端口的transport通信，只留幾個client node開放9200端口的HTTP接口對外接收RestFul請求。
關於ES的基礎操作在此就不列舉了，感興趣的可以參照前面的ES權威指南下載地址，下載下來仔細研究，畢竟我這裏只是普及和稍微講講理論知識和對應的應用場景罷了。
另外關於數據可視化分析工具，在此說兩個，一個是Gnuplot，另外一個是AmCharts。另外聲明一下，可視化工具絕非這兩個，還有很多，大家可以根據自己的需求百度或Google搜索找找。
三、報警
對於運維工作來說，還剩下一個更需要實時性的功能-報警。報警的方式有很多種，最常見的就是電子郵件、短信等。隨著通信的發達，很多工具支持像微信告警等手段，比如我上家公司就通過Zabbix加微信聯合報警。
1.SendMail
郵件發送是產品運維乃至運營工作中的很重要部分。sendEmail和postFix的配置部署也是Linux運維人員的必備技能之一。不過在監控系統中，我們可以用更簡潔易用的命令來快速完成工作。
sendEmail就是這樣一個工具。下載地址:http://caspian.dotconf.net
2.WebSocket
在工作時間段，運維人員更經常停留在瀏覽器界面而不是郵件客戶端界面，至於手機等設備，離視線更加遙遠，所以在這種情況下，我們可以通過瀏覽器的幫助，使用成本極低的網頁報警，同樣可以獲得很好的效果。
網頁實時刷新，是近年來最流行的技術話題之一。從運維的實際需求出發，我們不用考慮太多並發的性能問題，更需要考慮的是快捷開發，簡單上手。就此，這裏推薦開發社區的小軟件:Juggernaut。下載地址:https://github.com/maccman/juggernaut
3.手機推送
運維人員下班之後，尤其是在下班路上，除了傳統的短信報警，在移動互聯網時代，也有了更加“時髦”的處理方式，那就是:用手機APP來收報警。
手機推送消息，是很多APP都有的基礎功能。我們不需要自己從頭研究推送原理，然後實現全套系統，直接使用JPush極光推送，可以極簡單地實現這個報警功能。極光推送APP的示例:
註冊賬戶->新建應用(純頁面操作，填寫應用名稱,獲取對應的Key和master secret)->下載Example包->用adt eclipse打開eclipse項目並生成APK文件
4.分級和歸並
前面三種工具，以及其他還沒有提到的各種信息傳送渠道，都只解決了一個問題:把信息傳遞到運維人員身邊。但這個信息是否能有效讓運維人員對故障作出判斷並解決問題呢?
實際的工作中，並不缺乏這樣的情況:半夜被報警叫醒，只是一個磁盤85%的小問題，支持到明早上上班再解決肯定沒問題，於是繼續睡覺。結果早上一看，在昨晚半小時重復一次磁盤報警，還夾著一條宕機。
這就是告警設計的另一個重要方向:如何提高信息的有效傳遞。歸納起來，就是要”有多又少"-不同意義的信息要多，一點不能遺漏；相同的信息要少，每條都可以引起運維人員的快速響應。
一般來說，做到這點有兩個辦法:分級和歸並。
其實分級告警和歸並過濾在Nagios報警設計中都有所體現，比如WARNING、CRITICAL和RECOVERY狀態的區別，主機和服務的dependency關系，報警的escalations變更等。只要用好Nagios的細節控制，就可以減少很多無謂的報警。
對於非Nagios體系的監測告警，我們則需要自己動手完成。設計思路上，完全可以參考Nagios項目。實現辦法上則可以完全從告警出口處控制。一般我們使用的短信網關，都會采用MySQL作為短信存儲。我們可以限制MySQL數據庫的權限，自己編寫一個簡單的HTTP服務作為短信告警的統一接收入口。這樣，在HTTP服務接收到信息之後，可以先對MySQL中的近期數據進行查詢統計，一旦經過邏輯計算認為應該被歸並過濾掉，那麽在最後信息入庫的時候，直接將SQL中是否發生的列標記為已發送，或者自定義代表被過濾的其他數字-請註意，雖然信息最後被過濾，但千萬不能直接丟棄掉。“被過濾”也是一種記錄，也有價值。
網站運維技術與實踐之數據分析與報警