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