Linux System Log Collection、Log Integration、Log Analysis System Building Learning

目錄

1. 為什麼要構建日誌系統
2. 通用日誌系統的總體架構
3. 日誌系統的後設資料來源：data source
4. 日誌系統的子安全域日誌收集系統：client Agent
5. 日誌系統的中心日誌整合系統：log server
6. 日誌系統的後端儲存系統：log DB
7. 日誌系統搭建學習

 

1. 為什麼要構建日誌系統

log是管理員每日需要檢視的檔案記錄。裡面記載了大量系統正常和不正常的執行資訊，這些資訊對管理員分析系統的狀況、監視系統的活動、發現系統入侵行為是一個相當重要的部分
對於安全研究員來說，如何有效的利用系統的log來分析和定位攻擊成為構建一個完整的IDS、IPS的關鍵問題

Relevant Link:

http://elf8848.iteye.com/blog/2083306

 

2. 通用日誌系統的總體架構

0x1: 日誌系統特徵

在一個大型的平臺每天會產生大量的日誌(一般為流式資料，如: 搜尋引擎的pv，查詢等)，處理這些日誌需要特定的日誌系統，一般而言，這些系統需要具有以下特徵：

1. 構建應用系統和分析系統的橋樑，並將它們之間的關聯解耦 
2. 支援近實時的線上分析系統和類似於Hadoop之類的離線分析系統 
3. 具有高可擴充套件性。即: 當資料量增加時，可以通過增加節點進行水平擴充套件

0x2: 各類日誌分析系統的對比

1. FaceBook的Scribe

Scribe是facebook開源的日誌收集系統，在facebook內部已經得到大量的應用。它能夠從各種日誌源上收集日誌，儲存到一箇中央儲存系統(例如NFS，分散式檔案系統等)上，以便於進行集中統計分析處理。它為日誌的"分散式收集，統一處理"提供了一個可擴充套件的，高容錯的方案
它最重要的特點是容錯性好。當後端的儲存系統crash時，scribe會將資料寫到本地磁碟上，當儲存系統恢復正常後，scribe將日誌重新載入到儲存系統中

架構：
scribe的架構比較簡單，主要包括三部分，分別為scribe agent、scribe、儲存系統

1. scribe agent
scribe agent實際上是一個thrift client。向scribe(中心server)傳送資料的唯一方法是使用thrift client， scribe內部定義了一個thrift介面，使用者(scribe agent)使用該介面將資料傳送給server(scribe)

2. scribe
scribe接收到thrift client傳送過來的資料，根據配置檔案，將不同topic的資料傳送給不同的物件。scribe提供了各種各樣的store，如 file， HDFS等，scribe可將資料載入到這些store中。

3. 儲存系統
儲存系統實際上就是scribe中的store，當前scribe支援非常多的store，包括
    1) file(檔案)
    2) buffer(雙層儲存: 一個主儲存、一個副儲存)
    3) network(另一個scribe伺服器)
    4) bucket(包含多個store，通過hash的將資料存到不同store中)
    5) null(忽略資料)
    6) thriftfile(寫到一個Thrift TFileTransport檔案中)
    7) multi(把資料同時存放到不同store中) 

2. Apache的Chukwa

chukwa是一個非常新的開源專案，由於其屬於hadoop系列產品，因而使用了很多hadoop的元件(用HDFS儲存，用mapreduce處理資料)，它提供了很多模組以支援hadoop叢集日誌分析

特點：

1. 靈活的，動態可控的資料來源
2. 高效能，高可擴充套件的儲存系統
3. 合適的框架，用於對收集到的大規模資料進行分析

架構：
Chukwa中主要有3種角色，分別為: adaptor、agent、collector

1. Adaptor資料來源
可封裝其他資料來源，如file，unix命令列工具等
目前可用的資料來源有:
    1) hadoop logs
    2) 應用程式度量資料
    3) 系統引數資料(如linux cpu使用流率)

2. HDFS儲存系統
Chukwa採用了HDFS作為儲存系統，對於Chukwa使用的HDFS的這個業務場景，存在幾個問題
    1) HDFS的設計初衷是支援大檔案儲存(hadoop的特點)和小併發高速寫的應用場景
    2) 而日誌系統的特點恰好相反，它需支援高併發低速率的寫和大量小檔案的儲存

3. Collector和Agent
為了克服HDFS儲存系統和Chukwa日誌採集速率不相容的問題，增加了agent和collector階段。
    3.1 Agent的作用: 給adaptor提供各種服務，包括
        1) 啟動和關閉adaptor
        2) 將資料通過HTTP傳遞給Collector
        3) 定期記錄adaptor狀態，以便crash後恢復 
    3.2 Collector的作用: 
        1) 對多個資料來源發過來的資料進行合併，然後載入到HDFS中
        2) 隱藏HDFS實現的細節，如，HDFS版本更換後，只需修改collector即可 

4. Demux和achieving
直接支援利用MapReduce處理資料。它內建了兩個mapreduce作業，分別用於獲取data和將data轉化為結構化的log。儲存到data store(可以是資料庫或者HDFS等)中

3. LinkedIn的Kafka

Kafka是2010年12月份開源的專案，採用scala語言編寫，使用了多種效率優化機制，整體架構比較新穎(push/pull)，更適合異構叢集
特點：

1. 資料在磁碟上的存取代價為O(1)
2. 高吞吐率，在普通的伺服器上每秒也能處理幾十萬條訊息
3. 分散式架構，能夠對訊息分割槽
4. 支援將資料並行的載入到hadoop

架構：

Kafka實際上是一個訊息釋出訂閱系統。producer向某個topic釋出訊息，而consumer訂閱某個topic的訊息，進而一旦有新的關於某個topic的訊息，broker會傳遞給訂閱它的所有consumer
在kafka中，訊息是按topic組織的，而每個topic又會分為多個partition，這樣便於管理資料和進行負載均衡。同時，它也使用了zookeeper進行負載均衡。
Kafka中主要有三種角色，分別為producer、broker、consumer

1. Producer
Producer的任務是向broker傳送資料。Kafka提供了兩種producer介面
    1) low_level介面:
    使用該介面會向特定的broker的某個topic下的某個partition傳送資料
    2) high level介面: 
    該介面支援同步/非同步傳送資料
基於zookeeper的broker自動識別和負載均衡(基於Partitioner)
producer可以通過zookeeper獲取可用的broker列表，也可以在zookeeper中註冊listener，該listener在以下情況下會被喚醒：
    a．新增一個broker
    b．刪除一個broker
    c．註冊新的topic
    d．broker註冊已存在的topic
當producer得知以上時間時，可根據需要採取一定的行動 

2. Broker
Broker採取了多種策略提高資料處理效率，包括sendfile和zero copy等技術 

3. Consumer
consumer的作用是將日誌資訊載入到中央儲存系統上。kafka提供了兩種consumer介面
    1) low level介面: 
    它維護到某一個broker的連線，並且這個連線是無狀態的，即，每次從broker上pull資料時，都要告訴broker資料的偏移量
    2) high-level介面
    它隱藏了broker的細節，允許consumer從broker上push資料而不必關心網路拓撲結構。更重要的是，對於大部分日誌系統而言，consumer已經獲取的資料資訊都由broker儲存，而在kafka中，由consumer自己維護所取資料資訊

4. Cloudera的Flume

Flume是cloudera於2009年7月開源的日誌系統。它內建的各種元件非常齊全，使用者幾乎不必進行任何額外開發即可使用
特點：

1. 可靠性
當節點出現故障時，日誌能夠被傳送到其他節點上而不會丟失。Flume提供了三種級別的可靠性保障，從強到弱依次分別為        1) end-to-end(收到資料agent首先將event寫到磁碟上，當資料傳送成功後，再刪除；如果資料傳送失敗，可以重新傳送)
    2) Store on failure(這也是scribe採用的策略，當資料接收方crash時，將資料寫到本地，待恢復後，繼續傳送)
    3) Best effort(資料傳送到接收方後，不會進行確認)
2. 可擴充套件性
Flume採用了三層架構，分別為agent，collector和storage，每一層均可以水平擴充套件。其中，所有agent和collector由master統一管理，這使得系統容易監控和維護，且master允許有多個(使用ZooKeeper進行管理和負載均衡)，這就避免了單點故障問題
3. 可管理性
所有agent和colletor由master統一管理，這使得系統便於維護。使用者可以在master上檢視各個資料來源或者資料流執行情況，且可以對各個資料來源配置和動態載入。Flume提供了web和shell script command兩種形式對資料流進行管理 
4. 功能可擴充套件性
使用者可以根據需要新增自己的agent，colletor或者storage。此外，Flume自帶了很多元件，包括各種agent(file， syslog等)，collector和storage(file，HDFS等) 

架構：
Flume採用了分層架構，由三層組成，分別為agent，collector和storage。其中，agent和collector均由兩部分組成：source和sink，source是資料來源，sink是資料去向

1. agent
agent的作用是將資料來源的資料傳送給collector
    1.1 source: 資料來源
    Flume自帶了很多直接可用的資料來源(source)，如：
        1) text("filename"): 將檔案filename作為資料來源，按行傳送
        2) tail("filename"): 探測filename新產生的資料，按行傳送出去
        3) fsyslogTcp(5140): 監聽TCP的5140埠，並且接收到的資料傳送出去
    1.2 sink 
        1) console[("format")]: 直接將將資料顯示在桌面上
        2) text("txtfile"): 將資料寫到檔案txtfile中
        3) dfs("dfsfile"): 將資料寫到HDFS上的dfsfile檔案中
        4) syslogTcp("host", port): 將資料通過TCP傳遞給host節點

2. collector
collector的作用是將多個agent的資料彙總後，載入到storage中。它的source和sink與agent類似。從本質上來說，也可以把collector看成是一個agent，只是它所處的網路架構的位置為中心彙總的位置，負責將所有子安全域的agent上報的資訊進行整理彙總
 
3. storage
storage是儲存系統，可以是一個普通file，也可以是HDFS，HIVE，HBase等 

0x3: 日誌系統架構的通用特點

根據這四個系統的架構設計，可以總結出典型的日誌系統需具備三個基本元件，分別為

1. agent(封裝資料來源，將資料來源中的資料傳送給collector)：日誌採集
2. collector(接收多個agent的資料，並進行彙總後匯入後端的store中)：日誌綜合彙總、整理
3. store(中央儲存系統，應該具有可擴充套件性和可靠性，應該支援當前非常流行的HDFS)：日誌儲存

Relevant Link:

http://dongxicheng.org/search-engine/log-systems/

 

3. 日誌系統的後設資料來源：data source

0x1: syslog

syslog是Linux系統提供的一個系統服務程式，預設執行監聽在514埠，syslog服務是Linux提供的一個統一的日誌整合介面，原則上來說，Linux系統下的所有的系統常規行為資訊都可以通過syslog得到

關於Linux系統日誌、syslog的相關知識，請參閱另一篇文章

http://www.cnblogs.com/LittleHann/p/3892465.html

syslog預設有兩個守護程式

1. klogd
klogd程式是記錄系統執行的過程中核心生成的日誌,而在系統啟動的過程中核心初始化過程中生成的資訊記錄到控制檯(/dev/console)當系統啟動完成之後會把此資訊存放到/var/log/dmesg檔案中，我可以通過cat /var/log/dmesg檢視這個檔案,也可以通過dmesg命令來檢視

2. syslogd
syslogd 程式是記錄非核心以外的資訊

Relevant Link:

http://fanqiang.chinaunix.net/a1/b5/20011011/1200021437.html
http://ant595.blog.51cto.com/5074217/1080922

0x2: snoopy logger

syslog只能記錄一些簡單的系統操作指令、SSH/FTP登入失敗等安全事件，如果需要一些更深層次的系統事件，例如系統呼叫，網路連線狀態等資訊，就需要藉助一些第三方的軟體進行日誌源獲取了，snoopy logger就是一個很優秀的系統監控軟體

snoopy logger的基本工作原理是將自己的.so插入到/etc/ld.so.preload中(類似windows中的DLL注入)，以監視exec系統呼叫

Relevant Link:

http://bbs.gxnu.edu.cn/nForum/#!article/Programming/1386
http://blog.sina.com.cn/s/blog_704836f40101kyys.html
http://mewbies.com/how_to_use_snoopy_logger_tutorial.htm

0x3: kprobe

kprobe是Linux系統原生提供的一個系統呼叫監控機制，kprobe允許程式設計人員對Linux系統的某個系統呼叫函式的執行流上的"前pre_handler"、"後after_handler"、"錯誤fault_handler"進行回撥註冊，當程式碼邏輯流到達預定位置的時候，自動觸發程式設計師註冊的回撥函式。

在回撥函式中，程式設計師可以獲取到當前執行系統呼叫的引數、程式環境相關引數、呼叫執行結果等資訊從本質上來講，入侵檢測的感知模組就是一個系統行為的監控系統，kprobe的這種特性使得它能很好的充當日誌資料來源provider的角色

關於kprobe的相關原理，請參閱另外2篇文章

http://www.cnblogs.com/LittleHann/p/3854977.html
http://www.cnblogs.com/LittleHann/p/3920387.html

0x4: syslog-ng

syslog-ng可以簡單的看成取代syslog的企業級的日誌伺服器
syslog-ng可執行於"server"和"agent"模式，分別支援UDP、可靠的TCP和加密的TLS協議
syslog-ng可以用來在混合複雜的環境裡建立靈活的、可靠的日誌伺服器
syslog-ng開源版本的特性還有：

1. 支援SSL/TSL協議
2. 支援將日誌寫入資料庫中,支援的資料庫有MySQL, Microsoft SQL (MSSQL), Oracle, PostgreSQL, and SQLite.
3. 支援標準的syslog協議
4. 支援filter、parse以及rewrite
5. 支援更多的平臺
6. 更高的負載能力

syslog-ng對效能進行了優化，可以處理巨大的資料量。一般的硬體，在正確的配置下，可以實時地處理75000個訊息每秒鐘，超過24GB的RAW日誌每小時

Relevant Link:

http://www.php-oa.com/2012/01/13/linux-syslog-ng.html

0x5: 程式執行產生的執行日誌

除了系統原生的日誌和系統呼叫日誌之外，程式執行中產生的執行日誌也可以作為一個日誌資料來源，通過將執行資訊輸出到Linux下指定檔案中，可以獲得更加定製化的日誌資訊

 

4. 日誌系統的子安全域日誌收集系統：client Agent

在client agent的方案設計和具體實現上，我們需要重點考慮幾個問題

1. 如何對異構的客戶端日誌資料來源進行收集、轉換、整合
2. 客戶端的日誌provider(產生日誌的資料來源)的日誌產生速率並不一致，有的應用的日誌產生方式是低速大檔案、有的是高速小檔案。如何在這些異構、異速的日誌源之間進行日誌採集是一個需要考慮的問題
3. client agent充當的是日誌採集的客戶端，在從客戶端上獲得原始日誌資料後，必然要通過網路方式同步到一箇中心的日誌server上，這是個1:N的訊息集中，為了防止出現效能瓶頸，一個好的思路是採用非同步訊息queue的方式將日誌訊息push到中心log server上

0x1: Fluentd

Fluentd is a fully free and fully open-source log collector that instantly enables you to have a "Log Everything" architecture

Fluentd treats logs as JSON, a popular machine-readable format. It is written primarily in C with a thin-Ruby wrapper that gives users flexibility. 

Fluentd的特點

1. Unified Logging with JSON
Fluentd tries to structure data as JSON as much as possible: this allows Fluentd to unify all the collect, filter, buffer, and output mechanisms across multiple sources and destinations (Unified Logging Layer). The downstream data processing is much easier with JSON, since you don't have to maintain any adhoc scripts.
通過JSON的方式，在clinet agent這一層提供了一個統一的日誌源抽象層

2. Pluggable Architecture
Fluentd has a flexible plugin system that allows community to extend its functionality. Community contributed 300+ plugins makes it compatible with dozens of data sources and data outputs, and let you immediately utilize the data.

3. Minimum Resources Required
Fluentd is written in a combination of C language and Ruby, and requires very little system resource. The vanilla instance runs on 30-40MB of memory and can process 13,000 events/second/core.

4. Built-in Reliability
Fluentd supports memory- and file-based buffering to prevent inter-node data loss. Fluentd also support robust failover and can be set up for high availability. 2,000+ data-driven companies rely on Fluentd to differentiate their products and services through a better use and understanding of their log data.

Relevant Link:

http://docs.fluentd.org/articles/quickstart

 

5. 日誌系統的中心日誌整合系統：log server

log server在架構上位於所有client agent的網路中心節點的位置，通常來說是一個分散式叢集，通過前端負載均衡將來自client agent的日誌彙集流量平均分配到後端的log server叢集上。

0x1: TimeTunnel

TimeTunnel(簡稱TT)是一個基於thrift通訊框架搭建的實時資料傳輸平臺，準確地來說，TT應該是一個log client agent(日誌收集客戶端)和log server(日誌服務端整合模組)的集合體，TT在日誌生產者和日誌消費者之間搭建了一個基於非同步訊息佇列的通訊橋樑，具有如下特點

1. 高效能
2. 實時性
3. 順序性
4. 高可靠性
5. 高可用性
6. 可擴充套件性等特點(基於Hbase)

TT非常適合在流式資料實時接入的業務場景，可應用於

1. 日誌收集
2. 資料監控
3. 廣告反饋
4. 量子統計
5. 資料庫同步等領域

使用TimeTunnel的業務場景架構圖如下

TimeTunnel邏輯架構圖如下

Time Tunnel大概有幾部分組成

1. TTmanager
    1) 負責對外提供佇列申請、刪除、查詢和叢集的管理介面
    2) 對內故障發現，發起佇列遷移
2. Client
一組訪問timetunnel的API，主要有三部分組成
    1) 安全認證api
    2) 釋出api
    3) 訂閱api
目前client支援java，python，php三種語言 

3. Router
客戶端提供路由資訊，找到為訊息佇列提供服務的Broker。Router是訪問timetunnel的門戶，主要負責路由、安全認證和負載均衡        
　　 1) Client訪問timetunnel的第一步是向Router進行安全認證
    2) 如果認證通過，Router根據Client要釋出或者訂閱的topic對Client進行路由，使Client和正確的Broker建立連線
    3) 路由的過程包含負載均衡策略，Router保證讓所有的Broker平均地接收Client訪問 

4. Zookeeper
Zookeeper是hadoop的開源專案，其主要功能是狀態同步，Broker和Client的狀態都儲存在這裡

5. Broker 
Broker是timetunnel的核心，負責訊息的儲存轉發，承擔實際的流量，進行訊息佇列的讀寫操作

Relevant Link:

http://blog.csdn.net/pelick/article/details/26265663
http://code.taobao.org/p/TimeTunnel/wiki/index/
http://code.taobao.org/p/TimeTunnel/src/
http://www.oschina.net/question/3307_14476

 

6. 日誌系統的後端儲存系統：log DB

日誌系統的業務場景是一個以儲存、呈現為主的需求，並不需要十分高的實時性需求

Relevant Link:

 

7. 日誌系統搭建學習

瞭解了日誌系統的基本原理和架構後，我們接下來嘗試自己在搭建一個日誌demo系統

0x1: HAProxy + Keepalived + Flume

Relevant Link:

http://my.oschina.net/pzh0819/blog/143800

0x2: Fluentd + MongoDB

1. 安裝

//You can easily do this via rubygems (beware it requires at least ruby 1.9.2):
$ gem install fluentd

//When you’re done you can create a setup file:
$ fluentd -s ~/.fluentd
This will create the file ~/.fluentd/fluent.conf and setup the ~/.fluent/plugins folder. 

2. 配置Fluentd：fluentd.conf file

example

## built-in TCP input
## $ echo <json> | fluent-cat <tag>
<source>
  type forward
  port 24224
</source>
 
## match tag=fluentd.test.** and dump to console
<match fluentd.test.**>
  type stdout
</match>
 
<match mongo.**>
  type mongo
  host 127.0.0.1
  port 27017
  database fluentd
  collection test
 
  # for capped collection
  capped
  capped_size 1024m
 
  # flush
  flush_interval 1s
</match>

修改完配置檔案後，我們可以重啟Fluentd

$ fluentd -c ~/.fluent/fluent.conf

3. Logging from log datasource

配置完fluentd之後，我們就可以使用fluentd進行異構日誌收集，並將日誌彙總到後端的儲存系統中了

Logging from bash to STDOUT

#!/bin/sh
 
fluent_log(){
  local project="$1"
  local script_name="$2"
  local message="$3"
  echo "{\""project\"":\""$project"\",\""script_name\"":\""$script_name"\",\""message\"":\""$message\""}" | fluent-cat fluentd.test.log
}
 
fluent_log "Library" "Reload books" "Started"

Relevant Link:

http://metalelf0.github.io/tools/2013/08/09/fluentd-usage-example-with-bash-and-ruby/
http://blog.nosqlfan.com/html/3521.html
http://bbs.linuxtone.org/home.php?mod=space&uid=15973&do=blog&id=3492

 

Copyright (c) 2014 LittleHann All rights reserved