早在1997年本人擔任Linux管理員時，搭建集中式系統日志服務器是最先要完成的真正的系統管理任務之一。我當時的上司想獲取來自眾多硬件設備的日志文件，要求我使用正則表達式（regexp），搜索日志文件尋找某些關鍵詞。當年Linux還處于初期階段，而我在空閑時一直在搗鼓Linux。于是，我不失時機地把Linux引入到了當時效力的那家公司。Linux行不行？當然行！本文要介紹的不僅僅是如何搭建集中式syslog-ng（下一代系統日志工具）服務器，還要介紹為什么你要著手搭建這樣一臺服務器。

那么，系統日志是什么東西？系統日志在Linux中用于將系統消息記入日志。下一代系統日志工具在1998年開發而成，只是對早期的系統日志工具作了改寫。截至2010年，下一代系統日志工具仍由BalaBit IT Security公司在積極開發，擁有的功能特性要多得多，其中包括更好的TCP處理、對消息采取TLS加密以及將消息發送到數據庫等等。一些Linux發行版允許你安裝系統日志工具、rsyslog或者下一代系統日志工具。本文重點介紹下一代系統日志工具，因為這個工具更新穎；如果讀者愿意，可以在之后選擇擁有下一代系統日志工具軟件的公司的企業版，以獲得“支持”。

剛才簡要介紹了下一代系統日志工具，接下來談談你為何要用集中式下一代系統日志工具服務器。我就說說兩個主要的理由。第一個是出于安全目的。如果你的路由器、防火墻、交換機、Linux服務器及/或其他硬件指向一臺安全可靠的集中式下一代系統日志工具服務器，要是有人的確企圖攻擊上述的其中一個設備，可以把日志文件安全地存放到讓人放心的異地位置。如果系統日志文件存放在設備上，這無異于讓攻擊者能夠抹掉痕跡。誠然，攻擊者能夠禁用將日志文件發送到外部下一代系統日志工具服務器的功能，但是在此之前的所有連接都將位于集中式系統日志服務器上。另一個理由是為了方便起見。比如說，如果你有一臺服務器崩潰了，毫無反應，你就可以檢查集中式系統日志服務器上的內核錯誤日志。如果你想檢查在一段較長時間內不同日期之間的系統日志模式，只要使用正則表達式，搜索來自集中式系統日志服務器的日志文件。

那么，我平時怎么做的呢？實際上，這兩種方法我在家里都用。我的設備和服務器不但把它們的所有系統日志文件轉發到某個集中式位置，而且這個位置嚴加保護起來。所說的那臺機器是一個虛擬機，只有1個端口開著（系統日志端口），只能從本地機器來訪問，系統日志文件而放在外部驅動器上。這么做是不是過于小心謹慎？也許有點吧。但我的確知道，在我家這個環境中，如果外部驅動器裝滿了太多的系統日志文件，它不會導致虛擬機崩潰。要是虛擬機果真出現了什么岔子，主機操作系統也不會受到影響。如果有人果真可以訪問我的其中一個設備，他也沒有辦法訪問我的系統日志服務器。沒錯，要是我的主機操作系統遇到了什么問題，那么訪客虛擬機就會有問題；但是我們總是無法做到事事都能防備。我得承認，這么做太過小心謹慎了；對大多數人來說，這么做可能有些過了。

開始入手之前，有必要先聲明一下。首先，與我之前寫的所有文章一樣，這里的所有測試是用Debian來完成的。本文中，我針對Debian 6.0.1設置了虛擬機，因而你的情況可能不一樣。另外，我不會深入探討如何合理保護你的服務器、把系統日志文件放在哪里最合適，或者如何設置除下一代系統日志工具之外的一切。本文就介紹集中式下一代系統日志工具服務器的基本方面。

#p# 服務器端的安裝和配置

安裝下一代系統日志工具實際上并不難，如果從軟件包來安裝更是如此。如果是Debian，運行apt-get install syslog-ng；如果是紅帽系統，運行yum install syslog-ng。訪問http://www.balabit.com/downloads/files?path=/syslog-ng/sources/3.2.4/source/syslog-ng_3.2.4.tar.gz，即可安裝該工具。接下來是下載、解包、配置、編譯和安裝。一旦安裝好了下一代系統日志工具，我們就可以配置服務器端了。

全局選項

你要做的頭一件事就是找到下一代系統日志工具的配置文件。默認安裝文件（針對Debian變種版本）是/etc/syslog-ng/syslog-ng.conf。在編輯任何配置文件之前，進行變更之前先拷貝一份原始配置文件是個好方法。這完全是為了以免出現問題，你需要找回原始配置文件。我往往把自己的原始配置文件標以.orig（這里是syslog-ng.conf.orig）。你已備份好了配置文件，現在就用自己喜歡的編輯器打開它，可以入手了。

long_hostnames（默認值：off）——我在本文中使用下一代系統日志工具OSE版本3.1，我其實在全局配置指南中找不到long_hostname。我會使用默認值為off的long hostnames（長主機名），使用完全符合標準的域名。

flush_lines（默認值：0）——設置一次向目的地發送幾行消息。如果設成0，一收到消息就發送，但是要牢記：如果這個值設得偏高，會增加消息延遲。這個選項在下一代系統日志工具的客戶端上很有用。在發送到目的地之前，你要將XX條消息保留在客戶端上，那樣即使收到來自服務器的眾多流量，也不至于擁塞那臺主要的下一代系統日志工具服務器。

use_dns（默認值：no）——選項包括：yes、no和persist_only。這個選項的選擇取決于你和你的環境。如果你的下一代系統日志工具在防火墻后面，無法訪問外界，那么選擇‘yes’很合適。如果可以訪問外界，就設置成‘no’，以便阻止可能出現的拒絕服務（DoS）攻擊。 我將該選項設成了‘persist_only’，因而會檢查我那臺下一代系統日志工具服務器上的/etc/hosts文件，以解析主機名，又不依賴DNS服務器。

use_fqdn（默認值：no）——你的選擇是設為“完全符合標準的域名”。由于使用家庭網絡，我只有一個內部域名。于是我設置為默認值‘no’。如果設置成‘yes’，你的客戶端主機名會顯示為‘hostA.domain.com’，而不是‘hostA’。

owner（默認值：root）——輸出文件的所有人
group（默認值：adm）——輸出文件群組
perm（默認值：0640）——輸出文件的權限。設置為默認值640，所有人有權讀寫，群組有權讀取，其他人沒有權限。
stats_freq（默認值：0）——兩個STATS（關于丟失日志消息的統計消息）消息之間間隔的時間（以秒為單位）。0表示禁用發送STATS消息。
bad_hostname（默認值：^gconfd$）——含有不該作為hostnames來處理的主機名的正則表達式，本文中是gconfd。如果你有好多臺服務器，我會建議hostnames，當然除非你記得域中的每一個IP地址。
這些是“默認”的全局配置選項，但你還可以使用其他眾多選項。我還使用下列選項：
normalize_hostnames（yes）——該選項把所有主機名轉換成小寫。我的一些設備使用大寫主機名，有時候我會迷上某個新主機，并把主機名的第一個字母轉換成大寫。該選項可以把所有字符轉換成小寫，以便閱讀。
keep_hostname（yes）——如果要進行轉發或透過外部服務器傳送，該選項就會保留主機名，那樣主機最終到達中央服務器后，主機名會一并到達，而不是依賴DNS（或/etc/hosts）。如果你使用$HOST宏指令，應該啟用該選項。

在更大、更重要的環境（不是小型辦公環境）下，我會設置stats_freq（600）和stats_level（2），以便從服務器獲取統計消息。在大多數小型辦公環境下，你可能搜索來自三五個設備的系統日志數據；這種情況下，實際丟失數據的可能性相當小。在更龐大的企業環境下，可能有幾百個設備向中央系統日志服務器報告，啟用統計功能讓系統管理員能夠檢查統計消息和可能丟失的消息。

你的全局配置選項看起來如下：
options {(off);
flush_lines(0);
use_dns(persist_only);
use_fqdn(no);
owner("root");
group("adm");
perm(0640);
stats_freq(0);
bad_hostname("^gconfd$");
normalize_hostnames(yes);
keep_hostname(yes);
};

#p# 設置監聽器

為下一代系統日志工具設置監聽器實際上只需要在配置文件中添加幾行。典型的監聽器行看起來像這樣：

source s_net { tcp((ip(127.0.0.1) port(1000) max-connections 5000)); udp (); };
source s_net = Network listener，表示網絡監聽器
tcp(ip(127.0.0.1) = Listen on localhost，表示監聽本地主機。如果你有多塊網卡，或者想指定某個IP地址與某塊網卡進行綁定，將127.0.0.1更改成那塊特定網卡的IP地址。
port (1000) = Listen to TCP port 1000，表示監聽TCP端口1000。
max connections = Allow 5000 simultaneous connections (stops the dreaded 'run away server' syndrome) ，表示允許5000個同時連接（杜絕可怕的‘失控服務器’綜合征）
udp () = Some devices send their syslog messages via udp，表示一些設備通過udp發送系統日志消息，所以如果你無法指定TCP和端口號，就請啟用udp。
encrypt(allow) = This could be an entire blog post in itself，表示這本身可能是整篇博文。下一代系統日志工具允許對系統日志消息采用加密（基于TLS/證書）。
示例看起來像這樣：
# Listen on TCP Port 1000 and UDP Port 514, Max 500
Connections source s_net {
tcp(port(1000) max-connections(500)); udp(););
目的地——有發就有收。在這里，發出去的必須在某個地方接收。一旦收到來自下一代系統日志工具服務器的消息，它就要發送到某地。因而syslog-ng.conf文件就有目的地這個部分。正如你所見，默認值包括本地機器上服務器消息的*nix目的地。但是入站消息又如何呢？它們發送到哪里？問得好！默認情況下，入站消息會將系統日志消息發送到在下一代系統日志工具指定的子系統。比如說，如果這個消息被歸類成驗證消息（/var/log/auth），那么它會把消息轉儲到下一代系統日志工具的/var/log/auth.log文件中，附有相關信息（主機名和日期/時間等）。

如果這實際上是你想要實現的，一堆服務器轉儲到與主服務器同一個文件上，那么我想任務完成了。但是下一代系統日志工具的功能絕不僅僅局限于此。目的地可能是平面文件、進入其他應用程序的管道、SQL數據庫（mysql、MS SQL和Oracle等）、遠程日志服務器和Terminal Windows。我將著重探討平面文件，假設你現在用的也是平面文件。

我搭建集中式系統日志服務器的方式可能與你的搭建方式不一樣。我有一個文件夾含有每個主機名，來自主機名的系統日志位于該文件夾中。比如：/mount/syslog/macha和/mount/syslog/beag等等。Logrotate工具負責日志文件的壓縮、刪除（將舊文件備份到遠程服務器，以防萬一）和清理。

我的目的地命令看起來像這樣：
destination d_net_auth {
file("/var/log/syslog/remote/$HOSTNAME/auth.log"); }; destination d_net_cron {
file("/var/log/syslog/remote/$HOSTNAME/cron.log"); }; destination d_net_daemon
{ file("/var/log/syslog/remote/$HOSTNAME/daemon.log"); }; destination
d_net_kern { file("/var/log/syslog/remote/$HOSTNAME/kern.log"); }; destination
d_net_lpr { file("/var/log/syslog/remote/$HOSTNAME/lpr.log"); }; destination
d_net_mail { file("/var/log/syslog/remote/$HOSTNAME/mail.log"); }; destination
d_net_syslog { file("/var/log/syslog/remote/$HOSTNAME/syslog.log"); };
destination d_net_user { file("/var/log/syslog/remote/$HOSTNAME/user.log"); };
destination d_net_user { file("/var/log/syslog/remote/$HOSTNAME/uucp.log"); };
destination d_net_debug { file("/var/log/syslog/remote/$HOSTNAME/debug"); };
destination d_net_error { file("/var/log/syslog/remote/$HOSTNAME/error"); };
destination d_net_messages { file("/var/log/syslog/remote/$HOSTNAME/messages");
}; destination d_net_mailinfo {
file("/var/log/syslog/remote/$HOSTNAME/mail/mail.info"); }; destination
d_net_mailwarn { file("/var/log/syslog/remote/$HOSTNAME/mail/mail.warn"); };
destination d_net_mailerr {
file("/var/log/syslog/remote/$HOSTNAME/mail/mail.err"); };

從理論上來說，現在下一代系統日志工具服務器應該可以創建存放文件所必需的目錄了（在全局策略中已有指定），但有時我會遇到問題：目錄無法順利創建，下一代系統日志工具中的錯誤卻在/var/log/errors中報告。為了以后減少麻煩和痛苦，我往往順便創建好主機和日志文件，我丟失的任何信息會最后出現在/var/log/errors中。

如果你是資深的下一代系統日志工具用戶，可能會想：我為何把本地主機目的地和遠程（異地客戶端）目的地分開來，而從理論上來說我本該創建d_auth，把常用本地主機過濾器也放入到文件夾中。這么做的原因是，我想把本地主機系統日志流量與遠程流量分開來——雖然配置行更多了，但對我來說更省事了。另外，當Linux子系統尋找把常用日志文件放在何處，就不會受到干擾。

過濾——下一代系統日志工具能夠過濾消息，而這項功能標志著系統日志工具是否成熟。過濾功能讓下一代系統日志工具與眾不同。有了過濾功能，我就可以做下列事：過濾防火墻日志可以尋找某些關鍵詞（比如端口掃描），轉儲到單單一個文件夾，將分布式拒絕服務（DDOS）攻擊過濾到另一個文件夾中。我的VOIP適配器發送系統日志事件，我根據那些消息過濾到了每一個文件，而不是過濾到單個文件。過濾還讓你可以指定根據哪幾個主機進行過濾，過濾到多個目的地。不僅如此，你還可以在過濾時使用正則表達式。

可以像這樣來創建過濾表達式：filter <identifier> { expression; };
<identifier>是你為過濾器賦予的名稱。<expression>含有函數和布爾操作符（and、or和not）。
就我的防火墻而言，示例如下：
filter firewall_ddos_filter { host("10.1.1.1") and match("Denial of Service"
value("MESSAGE")); };
該過濾器名為‘firewall_ddos_filter’，它監聽來自10.1.1.1的入站系統日志消息，消息為‘Denial of Service’（拒絕服務攻擊）。為了完成過濾器，你需要一個日志語句：
log firewall_ddos_filter { source(s_net); filter
(firewall_ddos_filter);
destination(d_net_firewall_ddos); };

在上述目的地中，我為防火墻DDOS攻擊、端口掃描等添加目的地。這樣一來，把日志文件與不使用標準*nix日志功能的服務器/設備分離開來，或者讓統管理員更容易過濾從防火墻出來的日志（或者把許多防火墻過濾到一個日志）。

如果你想使用多個‘firewall’主機（如示例），就不要添加它們，使用布爾操作符‘and’來創建日志/過濾器規則。這不管用。而是應該使用‘or’布爾操作符，就像這樣：

filter firewall_ddos_filter { host("10.1.1.1") or host
("10.1.1.2") and match("Denial of Service" value("MESSAGE")
((; };
我的‘Default’過濾命令看起來像這樣：
filter f_dbg { level(debug); };
filter f_info { level(info); };
filter f_notice{ level(notice); };
filter f_warn { level(warn); };
filter f_err { level(err);  };
filter f_crit { level(crit .. emerg); };

filter f_debug { level(debug) and not facility(auth,
authpriv, news, mail); };
filter f_error { level(err .. emerg) ; };
filter f_messages { level(info,notice,warn) and not
facility(auth,authpriv,cron,daemon,mail,news);
};

filter f_auth { facility(auth, authpriv) and not filter
(f_debug); };
filter f_cron { facility(cron) and not filter(f_debug); };
filter f_daemon { facility(daemon) and not filter
(f_debug); };
filter f_kern { facility(kern) and not filter(f_debug); };
filter f_lpr { facility(lpr) and not filter(f_debug);};
filter f_local { facility(local0, local1, local3, local4,
local5, local6, local7) and not filter(f_debug); };
filter f_mail { facility(mail) and not filter(f_debug); };
filter f_news { facility(news) and not filter(f_debug); };
filter f_syslog3 { not facility(auth, authpriv, mail) and
not filter(f_debug); };
filter f_user { facility(user) and not filter(f_debug); };
filter f_uucp { facility(uucp) and not filter(f_debug); };

filter f_cnews { level(notice, err, crit) and facility
(news); };
filter f_cother { level(debug, info, notice, warn) or
facility(daemon, mail); };

filter f_ppp { facility(local2) and not filter
(f_debug); };
filter f_console { level(warn .. emerg); };

#p# 統計消息

沒有什么比一些詳細的統計消息更讓我高興的了。只要運行任何服務器或服務，無論在家里還是在辦公室，我都想看看服務器一段時間內在處理什么。從版本3.1開始，下一代系統日志工具現在有了一個syslog-ng-ctl統計實用程序，它大大簡化了獲取日志文件的任務。版本3.1之前，想獲取統計文件，你就得運行echo STATS | nc -U /var/run/syslog-ng.ctl。

由于我喜歡用正則表達式，對于syslog-ng-ctl統計消息的輸出結果中的分號習以為常，因而我運行syslog-ng-ctl stats | sed 's|;|\t|g'，以清理輸出。

你輸入上述命令行后有6列：SourceName、SourceID、SourceInstance、State、Type和 Number。

SourceName——來源的名稱，比如：目的地、來源、全局或中央。
SourceID——你為來源賦予的識別號（之前的例子是firewall_ddos_filter，其他例子會是d_mail和d_net_user等）
SourceInstance——來源實例的目的地，如文件名；或者程序來源（sql）或目的地的應用程序名稱。
State——對象的狀態：a（活動—目前處于活動狀態，接收數據），d（動態—目前沒有持續可用），或o（曾經活動，但停止接收孤立對象等消息）。
Type——統計消息的類型，比如：Processed，表示到達目的地的消息數量；Dropped，指丟失消息的數量；Stored，指存儲在等待發送到目的地的消息列隊中的消息數量；Suppressed（not sent），指被抑制消息的數量；Stamp，指上一個發送消息的時間戳。下一代系統日志工具服務重置后，這些統計類型也被重置。
Number——消息數量。

日志輪詢，日志輪詢，日志輪詢

該日志消息對你來說是不是夠清楚？從長遠來看，輪詢消息日志可以讓你避免麻煩。如果你不對日志輪詢，日志磁盤空間只會越來越擠，最后把整個硬盤都塞滿。日志輪詢不但可以節省空間，還會使得搜索特定日期的日志文件更容易；如果你把沒有設成日志輪詢的50MB日志文件調出來，搜索特定日期的內容，就會很麻煩。logrotate位于/etc/logrotate.conf，具體要看使用的Linux發行版。因為本文不是介紹logrotate，最終配置是啥樣因人而宜，下面給出的例子表明我怎樣輪詢日志文件：

/var/log/remote/*/ { rotate 5 weekly missingok create }

這會每個星期檢查/var/log/remote/*/，輪詢日志。日志輪詢1個月；1個月后，我會使用cronjob實用工具，對舊日志進行TAR壓縮，把它們轉移到備份位置；舊日志會在那里再保存一個月，之后輪換掉。當然在公司環境下，按照管理或法規要求，日志會保存相應的很長時間；但是對于家庭環境而言，我覺得日志保存2個月夠長了，足以為在此期間可能出現的任何問題排錯。

#p# 系統日志客戶端

由于每個服務器和設備的情況不一樣，我不會過于深入地探討這方面。系統日志經由UDP端口514來通信，但是我在前面提到，我還為其他設備設置了主系統日志服務器，經由TCP端口1000通信。這讓下一代系統日志工具服務器可以監聽兩個端口：514 UDP用于無法更改其端口的設備，TCP 1000則用于指定了端口號的服務器。為何我設置TCP 1000，而不設置TCP 514？因為Linux使用tcp 514 用于rsh（遠程外殼），這會導致我（及別人）的主機系統出現一些問題。如果你打算面向外界運行下一代系統日志工具（假設你已設置了驗證，并使用TLS加密），那么設置不常見的TCP端口將是最穩妥的。

1. 針對設備，你要做的就是讓設備指向主機名，并確保UDP 514或TCP 1000是目的地。
2. 針對rsyslog客戶端，添加下面這一行：
如果是TCP：*.* @@ipaddress:1000
如果是UDP：*.* @ipaddress:514
3. 針對下一代系統日志工具客戶端，添加下面這一行：
*New syslog Protocol* syslog(host tranport [options];

*old syslog protocol* destination d_tcp { syslog(ip
("remoteip")
transport("tcp") port(1000) localport(999)}; };

destination d_udp { syslog(ip("remoteip") transport("udp")
port(514)
localport(999)}; };

結論

上面概要介紹了下一代系統日志工具。下一代系統日志工具方面還有許多東西要了解，我只是介紹了基本的方面。你可以在此基礎上了解宏指令、更嚴格的過濾以及對系統日志消息采用基于TLS/證書的加密。如果你把系統日志消息發送到集中式系統日志服務器，并且備份該系統日志服務器，就大可放心：你需要系統消息時，可以安全而輕松地獲取這些消息。

原文鏈接：http://www.linuxjournal.com/content/creating-centralized-syslog-server