日志收集系統技術方案

本發明專利技術公開了一種日志收集系統，屬于互聯網技術領域。本發明專利技術的方案包括：服務器端和部署于不同生產服務器上的多個客戶端，所述客戶端，適于獲取生產服務器所產生的對應不同類別業務的數據，并將特定標識的數據歸并為一條數據后發送給所述服務器端；所述服務器端，適于從各客戶端接收數據，并進行存儲或轉發。本發明專利技術的技術方案，可以傳送包含任意個數字段的數據，使得數據的傳送不再有諸多限制，并在客戶端對數據進行了歸并處理，因此避免了因傳輸大量的相同或類似的數據，造成網絡堵塞和延遲的問題。

【技術實現步驟摘要】
本專利技術涉及互聯網
，具體涉及一種日志收集系統。
技術介紹
互聯網時代的后臺數據非常重要而且龐大，比如日志數據和統計數據。這些后臺數據可能是后臺工程師分析程序運行狀況的第一手資料，也可能是業務運營決策所依賴的第一參考。然而大流量的網站一般都有上千萬臺生產服務器，且分布于各個不同的機房。日志文件或統計數據就會存放在這些網絡異構且分布零散的生產服務器上，給日志的收集、傳輸、匯總及分析帶來很大的困難。目前有一些開源的軟件可以用來收集這些日志，但也存 在著很多不能解決的情況。目前較為常用的一些開源軟件例如Scribe，可以達到簡單收集日志數據的目的。Scribe是當前的一個大型的社交網絡服務網站的開源的日志收集系統，在該大型的社交網絡服務網站內部已經得到大量的應用。它能夠從各種日志源上收集日志，存儲到一個中央存儲系統(可以是NFS，分布式文件系統HDFS等)上，以便于進行集中統計分析處理。它為日志的“分布式收集，統一處理”提供了一個可擴展的，高容錯的方案。當中央存儲系統的網絡或者機器出現故障時，scribe會將日志轉存到本地或者另一個位置，當中央存儲系統恢復后，scribe會將轉存的日志重新傳輸給中央存儲系統。其通常與Hadoop結合使用，scribe用于向HDFS中push日志，而Hadoop通過MapReduce作業進行定期處理。圖I是現有的Scribe收集日志的示意圖。如圖I所示，Scribe從作為種數據源的各應用上收集數據，放到一個共享隊列上，然后push到后端的中央存儲系統上。當中央存儲系統出現故障時，scribe可以暫時把日志寫到本地文件中，待中央存儲系統恢復性能后，scribe把本地日志續傳到中央存儲系統上。各個數據源須通過THRIFT (由于采用了 THRIFT，客戶端可以采用各種語言編寫向scribe傳輸數據，每條數據記錄包含一個category和一個message )。可以在scribe配置用于監聽端口的THRIFT線程數(默認為3)。在后端，scribe可以將不同category的數據存放到不同目錄中，以便于進行分別處理。后端的日志存儲方式可以是各種各樣的store，包括file (文件),buffer (雙層存儲,一個主儲存,一個副存儲),network (另一個scribe服務器)等。但是scribe存在如下缺點(I) scribe的一個缺點是前端組織數據不靈活，只能使用兩個字段，即catagory和message，在生產服務器的應用程序中，如果想用scribe發送數據，則每條數據只能有catagory和message兩個字段，如果想傳送多個字段，則必須自己組織數據，將要傳送的多個數據合并到message里面。在后期分析數據時還要自己解析message,得到原來的多個字段。這給數據的傳輸造成了諸多的限制和不便。(2)另一個缺點是，scribe會接收每一條數據，并把它們忠實地記錄在本地緩存，以一定頻率批量發送數據，即便兩條數據的category和message是一模一樣的。這在數據傳輸量很大、傳輸頻率很高時，容易造成嚴重的網絡堵塞和延遲。
技術實現思路
鑒于上述問題，提出了本專利技術以便提供一種克服上述問題或者至少部分地解決上述問題的日志收集系統。依據本專利技術，提供了一種日志收集系統，該系統包括服務器端和部署于不同生產服務器上的多個客戶端，所述客戶端，適于獲取生產服務器所產生的對應不同類別業務的數據，并將特定標識的數據歸并為一條數據后發送給所述服務器端；所述服務器端，適于從各客戶端接收數據，并進行存儲或轉發。可選地，該客戶端包括數據獲取單元、歸并處理單元和多個存儲單元，所述多個 存儲單元分別對應不同類別的業務，且每個存儲單元都有一個對應的定時周期；所述數據獲取單元，適于從生產服務器獲取對應不同類別業務的數據，將所獲取的數據按照對應的不同類別的業務分發到對應的存儲單元進行保存；其中，每條數據包含一個以上的字段，不同的字段具有不同的類型，且每條數據的至少一個字段標識有關鍵碼；每個存儲單元，適于保存來自數據獲取單元的數據；所述歸并處理單元，適于在每個存儲單元對應的定時周期結束時，將該存儲單元所保存的數據中的標識有關鍵碼的字段的值相同的數據歸并為一條數據后發送給服務器端。可選地，所述歸并處理單元，進一步適于在每種類別業務對應的定時周期結束時，將所保存的該類別業務的數據中的標識有關鍵碼的字段的值相同的數據歸并為一條數據時，對沒有標識關鍵碼的字段，按照不同的類型進行不同的歸并處理。可選地，歸并處理單元，進一步適于在按照不同的類型對沒有標識關鍵碼的字段進行不同的歸并處理時，采用以下一種或多種的組合對于求和類型的字段，將標識有關鍵碼的字段的值相同的各數據的該字段上的數值相加，其和作為歸并后該字段的值；對于求平均類型的字段，將標識有關鍵碼的字段的值相同的各數據的該字段上的數值求平均，其均值作為歸并后該字段的值；對于最大值類型的字段，從標識有關鍵碼的字段的值相同的各數據的該字段上的值中找出最大值，作為歸并后該字段的值；對于常字符類型的字段，從標識有關鍵碼的字段的值相同的各數據中取第一條數據的該字段上的值，作為歸并后該字段的值；對于累加字符類型的字段，將標識有關鍵碼的字段的值相同的各數據的該字段上的字符按指定順序串接后，作為歸并后該字段的值。可選地，所述服務器端，適于將所接收的數據轉發給其它的服務器，或轉發到數據庫設備，或保存成本地文件。根據本專利技術的這種在不同的生產服務器上分別部署客戶端，各客戶端將收集的數據發給服務器端，其中客戶端將所獲取的數據按照對應的不同類別的業務分類存放，每條數據包含一個以上的不同類型的字段，在每種類別業務對應的定時周期結束時，將所保存的該類別業務的數據中的，標識有關鍵碼的字段的值相同的數據歸并為一條數據后發送給服務器端的技術方案，可以傳送任意個字段的數據，且在客戶端就進行了數據歸并處理，由此解決了現有的scribe只允許每條數據只能有catagory和message兩個字段,從而使得數據的傳送有諸多限制的問題，以及解決了現有的scribe在前端只是忠實地記錄數據，不進行歸并處理，導致數據傳輸量大、傳輸頻率高，容易造成網絡堵塞和延遲的問題。上述說明僅是本專利技術技術方案的概述，為了能夠更清楚了解本專利技術的技術手段，而可依照說明書的內容予以實施，并且為了讓本專利技術的上述和其它目的、特征和優點能夠更明顯易懂，以下特舉本專利技術的具體實施方式。附圖說明通過閱讀下文優選實施方式的詳細描述，各種其他的優點和益處對于本領域普通技術人員將變得清楚明了。附圖僅用于示出優選實施方式的目的，而并不認為是對本專利技術的限制。而且在整個附圖中，用相同的參考符號表示相同的部件。在附圖中 圖I是現有的Scribe收集日志的示意圖；圖2示出了根據本專利技術一個實施例的一種日志收集系統的框圖；圖3示出了根據本專利技術一個實施例的一種日志收集系統的客戶端的結構圖；圖4示出了根據本專利技術一個實施例的一種收集數據的方法的流程圖。具體實施例方式下面將參照附圖更詳細地描述本公開的示例性實施例。雖然附圖中顯示了本公開的示例性實施例，然而應當理解，可以以各種形式實現本公開而不應被這里闡述的實施例所限制。相反，提供這些實施例是為了能夠更透徹地理解本公開，本文檔來自技高網...

【技術保護點】
一種日志收集系統，包括：服務器端和部署于不同生產服務器上的多個客戶端，所述客戶端，適于獲取生產服務器所產生的對應不同類別業務的數據，并將特定標識的數據歸并為一條數據后發送給所述服務器端；所述服務器端，適于從各客戶端接收數據，并進行存儲或轉發。

【技術特征摘要】
1.一種日志收集系統，包括服務器端和部署于不同生產服務器上的多個客戶端， 所述客戶端，適于獲取生產服務器所產生的對應不同類別業務的數據，并將特定標識的數據歸并為一條數據后發送給所述服務器端； 所述服務器端，適于從各客戶端接收數據，并進行存儲或轉發。2.如權利要求I所述的系統，其中，所述客戶端包括數據獲取單元、歸并處理單元和多個存儲單元，所述多個存儲單元分別對應不同類別的業務，且每個存儲單元都有一個對應的定時周期； 所述數據獲取單元，適于從生產服務器獲取對應不同類別業務的數據，將所獲取的數據按照對應的不同類別的業務分發到對應的存儲單元進行保存；其中，每條數據包含一個以上的字段，不同的字段具有不同的類型，且每條數據的至少一個字段標識有關鍵碼；每個存儲單元，適于保存來自數據獲取單元的數據； 所述歸并處理單元，適于在每個存儲單元對應的定時周期結束時，將該存儲單元所保存的數據中的標識有關鍵碼的字段的值相同的數據歸并為一條數據后發送給服務器端。3.如權利要求2所述的系統，其中， 所述歸并處理單元，進一步適于在每種類別業務對應的定時周期結束時，將所保存的該類別業務...

【專利技術屬性】
技術研發人員：張珂，郝國梁，
申請(專利權)人：北京奇虎科技有限公司，奇智軟件北京有限公司，
類型：發明
國別省市：