網站運維技術與實踐之資料採集、傳輸與過濾
一、採集點的取捨
說到資料分析，首先當然是資料越全面越詳細越好。因為這有助於分析得出比較正確的結果，從而做出合理的決策。
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）
二、收集傳輸
在實時性要求不是特別高的環境下，通常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，用於儲存的SQL/">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本身的協議資訊。
二、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協議的基礎上完成的。
三、日誌收集系統框架
作為運維人員，我們一般都可以通過Shell或者Perl指令碼來自動化收集一些資訊，我個人用Shell比較多。但是隨著資料來源的種類越來越多，或者傳輸後的分析平臺越來越多，自己動手寫指令碼會是一件越來越不自動化的麻煩事情。這個時候，我們就需要足夠智慧的開框架，替代我們來做這些事情。
事實上，近幾年來，各大網際網路公司和主要開源組織陸續釋出自己的資料收集傳輸處理框架，比如Storm、KafKa等等。
不過，以上專案大多數由開發人員結合自身環境逐步改進出來的，大多數有以下兩個特點，讓運維人員難以下手:
(1)使用Java、Scala語言編寫。運維人員比較熟悉Python、Perl、PHP等解釋性語言；
(2)依賴Hadoop生態環境。這些框架大多需要提供後期的處理分析功能，基本上都採用了HDFS儲存資料、Map/Reduce處理、Zookeeper保證高可用的一套解決辦法。這導致整個框架結構相當複雜，初始規模也異常龐大，運維成本也比較高。
之前我在ofollow,noindex" target="_blank">談談運維人員謹慎作業系統環境和管理 文章說過，作為運維人員有的時候為了適應未來業務的需要和團隊的更好協作有必要了解相關的工作(比如作為運維熟悉開發、測試、產品等等那套),或許在有的朋友看來越界了，但是從個人發展層面看來並沒有。