共计 3726 个字符，预计需要花费 10 分钟才能阅读完成。
| 导读 | Syslog 服务器可以用作一个网络中的日志监控中心，所有能够通过网络来发送日志的设施（包含了 Linux 或 Windows 服务器，路由器，交换机以及其他主机）都可以把日志发送给它。通过设置一个 syslog 服务器，可以将不同设施 / 主机发送的日志，过滤和合并到一个独立的位置，这样使得你更容易地查看和获取重要的日志消息。 |
Rsyslog 作为标准的 syslog 守护进程，预装在了大多数的 Linux 发行版中。在客户端 / 服务器架构的配置下，rsyslog 同时扮演了两种角色：1. 作为一个 syslog 服务器，rsyslog 可以收集来自其他设施的日志信息；2. 作为一个 syslog 客户端，rsyslog 可以将其内部的日志信息传输到远程的 syslog 服务器。
在此，我们演示了在 linux 上如何通过 rsyslog 来配置一个中心化 syslog 服务器。在进入详解之前，先温习一下 syslog 标准。
当通过 syslog 机制来收集日志时，有 3 个必须要考虑到的重要事情：
•设施层级: 监听何种类型的进程
•严重性（优先）级别: 收集何种级别的日志消息
•目标: 发送或记录日志消息到何处
现在我们更加深入地了解一下配置是如何定义的。
设施层级定义了一种用来对内部系统进程进行分类的方法，linux 中的一些常见的设施包括:
•auth: 身份验证相关的消息（登录时）
•cron: 进程或应用调度相关的消息
•daemon: 守护进程相关的消息（内部服务器）
•kernel: 内核相关的消息
•mail: 内部邮件服务器相关的消息
•syslog: syslog 守护进程本身相关的消息
•lpr: 打印服务相关的消息
•local0 – local7: 用户自定义的消息（local7 通常被 Cisco 和 Windows 服务器 使用）
严重性（优先）级别有固定的标准缩写和指代的值，其中的数字 7 具有最高的级别，这些级别包含了：
•emerg: Emergency（紧急）- 0
•alert: Alerts（报警）- 1
•crit: Critical (关键）- 2
•err: Errors（错误）- 3
•warn: Warnings（警告）- 4
•notice: Notification（通知）- 5
•info: Information（消息）- 6
•debug: Debugging（调试）- 7
最后，目标语句会让一个 syslog 客户端来执行以下三个任务之一：
1. 保存日志消息到一个本地文件；
2. 通过 TCP/UDP 将消息路由到远程的 syslog 服务器中；
3. 将其发送到一个标准输出中，例如控制台。
在 rsyslog 里, syslog 的配置是基于以下模式进行结构化的。
1.[facility-level].[severity-level] [destination]在我们理解 syslog 之后，现在可以通过 rsyslog 来将一个 Linux 服务器配置为一个中心 syslog 服务器了，另外我们也将看到如何在一个 Windows 的系统上配置一个 syslog 客户端来发送内部日志到该 syslog 服务器中。
要将 linux 主机设置为一个中央日志服务器，我们需要创建一个分离的 /var 分区，并分配足够大的磁盘空间或者创建一个特殊的 LVM 卷组。这样就会使得 syslog 服务器能够承担在日积月累收集日志所带来的潜在增长。
rsyslog 守护进程来自于当前的 linux 发布版本的预装模块，但是默认并没有启动。为了能够让 rsyslog 守护进程能够接受外部的消息，需要编辑其配置文件 /etc/rsyslog.conf.
打开文件进行编辑，查找到下面的两行所在的位置，通过删除其行首的 #字符来取消注释。
1.$ModLoad imudp
2.$UDPServerRun 514这会使得 rsysolog 守护进程能够在 UDP 端口 514 上接受日志消息了 —UDP 是一种比 TCP 速度快，但是并不具有 TCP 一样的数据流的可靠性。所以如果你需要使用可靠的传送机制，就可以通过取消以下行的注释。
1.$ModLoad imtcp
2.$InputTCPServerRun 514需要注意的是，TCP 和 UDP 可以被同时生效来监听 TCP/UDP 连接。
接下来的这步，需要我们来为远程消息创建模板，并告知 rsyslog 守护进程如何记录从其他客户端机器所接受到的消息。
使用文本编辑器来打开 /etc/rsyslog.conf，然后在 GLOBAL DIRECTIVE 块前追加以下的模板。
1.$template RemoteLogs,"/var/log/%HOSTNAME%/%PROGRAMNAME%.log" *
2.*.* ?RemoteLogs
3.& ~在此对该模板进行简单解释，$template RemoteLogs（这里“RemoteLogs”字符串可以为任何其他的描述性的名称）指令使 rsyslog 后台进程将日志消息写到 /var/log 下的单独的本地日志文件中，其中日志文件的名称是基于远程日志发送机器的主机名以及生成该日志的应用程序名进行定义的。其中第二行暗示了我们将 RemoteLogs 模板应用到所有接收到的日志上。
符号 ”& ~” 表示了一个重定向规则，被用来告知 rsyslog 守护进程停止对日志消息的进一步处理，并且不要在本地写入。如果没有使用该重定向规则，那么所有的远程消息都会在写入上述描述的日志文件之外同时被写入到本地日志文件，这就意味着日志消息实际上被写了两次。使用该规则的另外一个结果就是 syslog 服务器本身的日志消息只会被以该机器主机名命名的专有文件中。
如果你想要的话，也可以使用下面的模式对特定的设备或严重性级别使用新的模板直接来记录日志消息。
1.[facility-level].[severity-level] ?RemoteLogs例如：
将全部优先级别的所有内部用户验证消息指定为 RemoteLogs 模板：
1.authpriv.* ?RemoteLogs将所有系统进程中除开 mail、用户验证和 cron 消息之外的进程产生的消息级别的日志指定为 RemoteLogs 模板：
1.*.info,mail.none,authpriv.none,cron.none ?RemoteLogs如果我们想要将所有从远程客户端接受到的消息写入到一个以它们的 IP 地址命名的单个文件中，可以使用以下的模板。在此我们为该模板赋予了“IpTemplate”名称。
1.$template IpTemplate,"/var/log/%FROMHOST-IP%.log"
2.*.* ?IpTemplate
3.& ~在我们启用 rsyslog 守护进程并编辑好配置文件之后，需要重启该守护进程。
在 Debian，Ubuntu 或 CentOS/RHEL 6 中：
1.$ sudo service rsyslog restart在 Fedora 或 CentOS/RHEL 7 中：
1.$ sudo systemctl restart rsyslog我们可以通过 netstat 命令来验证 rsyslog 守护进程是否正常工作。
1. $ sudo netstat -tulpn | grep rsyslog在 UDP 监听端口下工作的 rsyslog 守护进程会有类似下面的输出。
1.udp 0 0 0.0.0.0:514 0.0.0.0:* 551/rsyslogd
2.udp6 0 0 :::514 :::* 551/rsyslogd如果 rsyslog 守护进程被设置在 TCP 连接端口，那么应该有类似下面所示的输出。
1.tcp 0 0 0.0.0.0:514 0.0.0.0:* LISTEN 1891/rsyslogd
2.tcp6 0 0 :::514 :::* LISTEN 1891/rsyslogd要将一个 Windows 客户端的日志消息转发到我们的 rsyslog 服务器，需要一个安装 Windows syslog 代理。当然，有许多的 syslog 代理可以在 windows 上运行，在此我们可以使用一个自由软件程序 Datagram SyslogAgent.
在下载安装该 syslog 代理后，需要将其配置为作为服务运行。指定使用何种协议来发送数据，以及远程 rsyslog 服务器的 IP 地址和端口，最后指定应该传输的事件日志类型，如下所示。
在我们完成所有的这些配置之后，我们就可以启动该服务并且在中央 rsyslog 服务器中使用命令行工具 tail - f 来查看日志文件了。
通过创建一个可以收集本地和远程主机的中央 rsyslog 服务器，我们可以更好地了解在这些系统内部究竟发生着什么，而且可以更加容易地调试它们的问题，是否在它们之间有任何延迟或崩溃存在。
via: http://devzum.com/2015/01/28/top-12-best-free-network-monitoring-tools/
作者：Caezsar M 译者：theo-l 校对：wxy 本文由 LCTT 原创编译，Linux 中国 荣誉推出
