網站運維技術與實踐之數據採集、傳輸與過濾

1、採集點的取捨

說到數據分析，首先固然是數據越全面越詳細越好。由於這有助於分析得出比較正確的結果，從而作出合理的決策。

1.服務器數據

採集的服務器數據主要圍繞着這麼幾個？

(1)服務器負載

(2)磁盤讀寫

(3)網卡流量

如何採集這些數據，能夠經過zabbix監控獲取。

關於zabbix學習，能夠參考個人這篇博客:

zabbix學習小結:https://www.cnblogs.com/youcong/p/7887074.html

篇幅雖然很多特別長，可是要點把握的比較好。

 

2.訪問日誌

訪問日誌與服務器數據又有何不一樣:每條訪問日誌都是有意義的，並且訪問日誌一般會在相隔比較久以後被要求重放（由於這時候出現的問題大可能是「偶然」性、不影響服務器自己性能的、難以快速反饋的隱藏Bug,因此在有條件的狀況下，應該保留所有的訪問日誌至少三個月以上）。

記得在上家公司的時候，每隔一段時間服務器都會自動備份最近幾天的日誌而後傳輸到專門備份的服務器上。以備不時之需。

 

3.系統日誌Syslog

Syslog是介於日誌和服務器數據之間的另外一部分。一方面是做爲Linux服務器最重要的OS層面的信息集中地，另外一方面Syslog自己做爲一種快速傳輸日誌的協議，也常常用於用戶應用輸出。並由此產生了Syslog-ng、Rsyslog等一系列成規模的Syslog收集分析系統。

這裏暫時僅針對Linux自己的Syslog作採樣分析介紹。由於大部分狀況下，用戶程度選擇輸出到Syslog時，就會針對性地採集分析辦法。

對於Syslog協議內容，最權威的天然是RFC文檔。涉及Syslog的RFC文檔很多，不過最基本並且最重要的內容格式在RFC3164（http://www.ietf.org/rfc/rfc3164.txt）

 

2、收集傳輸

在實時性要求不是特別高的環境下，一般scp或者rsync定時任務，進行集中收集，是廣大Linux運維人員最經常使用的手段。可是一旦有了較高的實時性要求，scp和rsync就不足以很好的完成任務，這時咱們就須要專門的數據傳輸中間件。

 

1.Rsyslog

Syslog的集中收集，是大規模集羣運維中必備的部分。在以往的Syslog介紹中，通常以Syslog-ng和Rsyslog兩個系統的出現最爲頻繁。惋惜Syslog-ng卻沒有真正成爲Syslog的ng-CentOS6中正式替代Syslog出現的是Rsyslog。鑑於Rsyslog已經成爲CentOS6的標配，Rsyslog自己也兼容Syslog的配置。

關於Rsyslog安裝，建議參考這個網址:https://www.cnblogs.com/redheat/p/7069765.html

 

Rsyslog的模塊分佈以下:

(1)Input Modules

IM模塊是改動最少的，基本上只有File、TCP、UDP、UNIX Socket以及在TCP基礎上的TLS和GSSAPI等更安全的協議。

(2)Output Modules

狹義的OM模塊，除了最基本的File之外，還有用於中轉的FWD，Pipe,Snmptrap，用於存儲的MySQL、PgSQL、Libdbi、HDFS、MongoDB等。此外社區還有Redis、ZeroMQ、ElasticSearch和Solr的OM模塊補丁。

(3)Parser Modules

這個模塊是在5.3.4版本以後新加入的。在以前的Rsyslog中，對Syslog協議格式的解析工做是直接在覈心代碼中完成，不可變動。不過到目前爲止，狹義的概念的PM模塊很少，除了RFC解析的意外，只有一個pmlastmsg模塊，專門用來解析Syslog中常見的那句「last messages repated in times」。

(4)Message Modification Modules

MM模塊其實就是在廣義的PM或OM上實現的。目前和Rsyslog代碼一塊兒分發的MM模塊有:Anon模塊，用來轉換具體的IP地址到A類地址;Normalize模塊，用來將Syslog格式的content轉換成爲CEE/Lumberjack格式，目的也和normalize模塊同樣，不過由於Lumberjack格式其實就是JSON，因此這個直接就解析爲JSON了；Snmptrapd模塊，在im的基礎上，提供對嚴重性位數據的替換修改功能。

(5)String Generator Module

SG模塊的做用是爲Rsyslog的file和forward提供template功能。咱們能夠經過template定義本身想要的內容樣式。注意這不會影響到Syslog自己的協議信息。

 

2、Message Queue（消息隊列）

Syslog雖好，但不是沒有缺點，具體以下:

(1)運行在UDP模式下的Syslog是會丟數據的。

(2)即便運行在TCP模式下解決了丟包的問題，Syslog的PRI包括TAG的方式依然沒法充分知足大多數狀況下對不一樣業務不一樣數據的隔離需求。

 

這種狀況下，消息隊列的優點就體現出來了。相似RabbitMQ、ZeroMQ、StoMQ、Q4MQ等，這些已經在業務線上普遍運用的MQ組件，也就順勢進入了運維繫統的範疇。

消息隊列，是軟件工程領域，用以進程間，甚至線程通訊的組件，不少時候都是操做系統或者應用內部在使用。不過咱們這裏要說的，是計算機之間、跨網頁的、狹義的消息隊列中間件。

 

消息隊列提供的是一個異步通訊協議，消息生成的一方和消費的一方不要求同步交互，而是將消息內容經過隊列來進行轉交，也就是說，隊列自己就須要具備存儲能力。

開源的消息隊列中間件有不少，有名的就有，JBoss Messaging、ActiveMQ、Qpid、RabbitMQ、Q4M等等。

 

最先的消息隊列中間件，Sun公司的JMS規範只有JAVA的API，可讓開發者像寫SQL同樣使用消息隊列，不過目前這種作法再也不主流，當前主流的消息隊列中間件標準有三個:

1.AMQP

AMQP和JMS的區別在於，AMQP定義的是以8字節爲單位的數據流格式。在AMQP中，數據的基本單位是幀。AMQP中一共有九種幀:open、begin、attach、tranfer、flow、disposition、detach、end和close。

數據傳輸以attach幀開始，detach幀結束；消息經過transfer幀建連在一個惟一的direction上；flow幀用於管理主題,方便訂閱;消息兩端的傳輸狀態變化，則經過disposition幀來交互。

上面這5個幀類型都與數據傳輸相關，其餘4個則偏重端點之間的鏈接。前面說到一個transfer幀是固定在一個direction上的。可是端點和端點之間，能夠有多個direction,這些direction合在一塊兒叫session,由begin和end幀來控制雙向session的初始化和終止。更高一層，多個session,還能夠以多路複用的鏈接形式，各自獨立地存在在相同的兩個端點之間，這個鏈接，是由open和close幀控制的。

AMQP的主要實現，有RabbitMQ、Qpid、ActiveMQ等，也是消息隊列中間件的主流。

 

2.MQTT

MQTT定義傳輸的，是遙測型數據，主要用於低帶寬的小型設備場合。MQTT的實現中，大多數是IBM等廠商的商業化產品，如WebSphereMQ等。

 

3.STOMP

STOMP是基於文本的消息傳輸協議。它在TCP層定義了一個相似HTTP的方法，數據傳輸一共包括十種:

CONNECT、SEND、SUBSCRIBE、UNSUBSCRIBE、BEGIN、COMMIT、ABORT、ACK、NACK、DISCONNECT等。

 

數據傳輸一樣以幀爲單位的。不過STOMP的幀，其實就是多行文本。第一行是具體指令名，第二行開始是以Key:value格式存在的headers，和HTTP同樣每一個Header一行。

而後一個附加空行後是詳細的內容體。最後以一個NULL字符結束。

 

服務器和客戶端之間的通訊，則經過另外三種幀完成，它們是MESSAGE、RECEIPT、ERROR。幀格式和數據傳輸幀格式同樣。

 

三種標準的實現都和HTTP工做在同一層面，即TCP基礎上。不過也有一些實現，好比Amazon的SQS，是在HTTP協議的基礎上完成的。

 

3、日誌收集系統框架
做爲運維人員，咱們通常均可以經過Shell或者Perl腳原本自動化收集一些信息，我我的用Shell比較多。可是隨着數據來源的種類愈來愈多，或者傳輸後的分析平臺愈來愈多，本身動手寫腳本會是一件愈來愈不自動化的麻煩事情。這個時候，咱們就須要足夠智能的開框架，替代咱們來作這些事情。

事實上，近幾年來，各大互聯網公司和主要開源組織陸續發佈本身的數據收集傳輸處理框架，好比Storm、KafKa等等。

不過，以上項目大多數由開發人員結合自身環境逐步改進出來的，大多數有如下兩個特色，讓運維人員難如下手:

(1)使用Java、Scala語言編寫。運維人員比較熟悉Python、Perl、PHP等解釋性語言；

(2)依賴Hadoop生態環境。這些框架大多須要提供後期的處理分析功能，基本上都採用了HDFS存儲數據、Map/Reduce處理、Zookeeper保證高可用的一套解決辦法。這致使整個框架結構至關複雜，初始規模也異常龐大，運維成本也比較高。

 

以前我在談談運維人員謹慎操做系統環境和管理文章說過，做爲運維人員有的時候爲了適應將來業務的須要和團隊的更好協做有必要了解相關的工做(好比做爲運維熟悉開發、測試、產品等等那套),或許在有的朋友看來越界了，可是從我的發展層面看來並無。