管理日志的一个好做法是将你的日志集中或整合到一个地方，特别是在你有许多服务器或多层级架构时。我们将告诉你为什么这是一个好主意，然后给出如何更容易的做这件事的一些小技巧。
　　集中管理日志的好处
　　如果你有很多服务器，查看某个日志文件可能会很麻烦。现代的网站和服务经常包括许多服务器层级、分布式的负载均衡器，等等。找到正确的日志将花费很长时间，甚至要花更长时间在登录服务器的相关问题上。没什么比发现你找的信息没有被保存下来更沮丧的了，或者本该保留的日志文件正好在重启后丢失了。
　　集中你的日志使它们查找更快速，可以帮助你更快速的解决产品问题。你不用猜测那个服务器存在问题，因为所有的日志在同一个地方。此外，你可以使用更强大的工具去分析它们，包括日志管理解决方案。一些解决方案能转换纯文本日志为一些字段，更容易查找和分析。
　　集中你的日志也可以使它们更易于管理：
　　它们更安全，当它们备份归档到一个单独区域时会有意无意地丢失。如果你的服务器宕机或者无响应，你可以使用集中的日志去调试问题。
　　你不用担心ssh或者低效的grep命令在陷入困境的系统上需要更多的资源。
　　你不用担心磁盘占满，这个能让你的服务器死机。
　　你能保持你的产品服务器的安全性，只是为了查看日志无需给你所有团队登录权限。给你的团队从日志集中区域访问日志权限更安全。
　　随着集中日志管理，你仍需处理由于网络联通性不好或者耗尽大量网络带宽从而导致不能传输日志到中心区域的风险。在下面的章节我们将要讨论如何聪明的解决这些问题。
　　流行的日志归集工具
　　在 Linux 上常见的日志归集是通过使用 syslog 守护进程或者日志代理。syslog 守护进程支持本地日志的采集，然后通过syslog 协议传输日志到中心服务器。你可以使用很多流行的守护进程来归集你的日志文件：
　　rsyslog 是一个轻量后台程序，在大多数 Linux 分支上已经安装。
　　syslog-ng 是第二流行的 Linux 系统日志后台程序。
　　logstash 是一个重量级的代理，它可以做更多高级加工和分析。
　　fluentd 是另一个具有高级处理能力的代理。
　　Rsyslog 是集中日志数据流行的后台程序，因为它在大多数 Linux 分支上是被默认安装的。你不用下载或安装它，并且它是轻量的，所以不需要占用你太多的系统资源。
　　如果你需要更多先进的过滤或者自定义分析功能，如果你不在乎额外的系统负载，Logstash 是另一个流行的选择。
　　配置 rsyslog.conf
　　既然 rsyslog 是广泛使用的系统日志程序，我们将展示如何配置它为日志中心。它的全局配置文件位于 /etc/rsyslog.conf。它加载模块，设置全局指令，和包含位于目录 /etc/rsyslog.d 中的应用的特有的配置。目录中包含的 /etc/rsyslog.d/50-default.conf 指示 rsyslog 将系统日志写到文件。在 rsyslog 文档中你可以阅读更多相关配置。
　　rsyslog 配置语言是是RainerScript。你可以给日志指定输入，像将它们输出到另外一个位置一样。rsyslog 已经配置标准输入默认是 syslog ，所以你通常只需增加一个输出到你的日志服务器。这里有一个 rsyslog 输出到一个外部服务器的配置例子。在本例中，BEBOP 是一个服务器的主机名，所以你应该替换为你的自己的服务器名。
　　action(type="omfwd" protocol="tcp" target="BEBOP" port="514")
　　你可以发送你的日志到一个有足够的存储容量的日志服务器来存储，提供查询，备份和分析。如果你存储日志到文件系统，那么你应该建立日志轮转来防止你的磁盘爆满。
　　作为一种选择，你可以发送这些日志到一个日志管理方案。如果你的解决方案是安装在本地你可以发送到系统文档中指定的本地主机和端口。如果你使用基于云提供商，你将发送它们到你的提供商特定的主机名和端口。
　　日志目录
　　你可以归集一个目录或者匹配一个通配符模式的所有文件。nxlog 和 syslog-ng 程序支持目录和通配符(*)。
　　常见的 rsyslog 不能直接监控目录。作为一种解决办法，你可以设置一个定时任务去监控这个目录的新文件，然后配置 rsyslog 来发送这些文件到目的地，比如你的日志管理系统。举个例子，日志管理提供商 Loggly 有一个开源版本的目录监控脚本。
　　哪个协议: UDP、TCP 或 RELP?
　　当你使用网络传输数据时，有三个主流协议可以选择。UDP 在你自己的局域网是常用的，TCP 用在互联网。如果你不能失去（任何）日志，要使用更高级的 RELP 协议。
　　UDP 发送一个数据包，那只是一个单一的信息包。它是一个只外传的协议，所以它不会发送给你回执（ACK）。它只尝试发送包。当网络拥堵时，UDP 通常会巧妙的降级或者丢弃日志。它通常使用在类似局域网的可靠网络。
　　TCP 通过多个包和返回确认发送流式信息。TCP 会多次尝试发送数据包，但是受限于 TCP 缓存的大小。这是在互联网上发送送日志常用的协议。
　　RELP 是这三个协议中可靠的，但是它是为 rsyslog 创建的，而且很少有行业采用。它在应用层接收数据，如果有错误会重发。请确认你的日志接受位置也支持这个协议。
　　用磁盘辅助队列可靠的传送
　　如果 rsyslog 在存储日志时遭遇错误，例如一个不可用网络连接，它能将日志排队直到连接还原。队列日志默认被存储在内存里。无论如何，内存是有限的并且如果问题仍然存在，日志会超出内存容量。
　　警告：如果你只存储日志到内存，你可能会失去数据。
　　rsyslog 能在内存被占满时将日志队列放到磁盘。磁盘辅助队列使日志的传输更可靠。这里有一个例子如何配置rsyslog 的磁盘辅助队列：
　　$WorkDirectory /var/spool/rsyslog # 暂存文件（spool）放置位置
　　$ActionQueueFileName fwdRule1     # 暂存文件的名字前缀
　　$ActionQueueMaxDiskSpace 1g       # 1gb 空间限制（尽可能大）
　　$ActionQueueSaveOnShutdown on     # 关机时保存日志到磁盘
　　$ActionQueueType LinkedList       # 异步运行
　　$ActionResumeRetryCount -1        # 如果主机宕机，不断重试
　　使用 TLS 加密日志
　　如果你担心你的数据的安全性和隐私性，你应该考虑加密你的日志。如果你使用纯文本在互联网传输日志，嗅探器和中间人可以读到你的日志。如果日志包含私人信息、敏感的身份数据或者政府管制数据，你应该加密你的日志。rsyslog 程序能使用 TLS 协议加密你的日志保证你的数据更安全。
　　建立 TLS 加密，你应该做如下任务：
　　生成一个证书授权(CA)。在 /contrib/gnutls 有一些证书例子，可以用来测试，但是你需要为产品环境创建自己的证书。如果你正在使用一个日志管理服务，它会给你一个证书。
　　为你的服务器生成一个数字证书使它能启用 SSL 操作，或者使用你自己的日志管理服务提供商的一个数字证书。
　　配置你的 rsyslog 程序来发送 TLS 加密数据到你的日志管理系统。
　　这有一个 rsyslog 配置 TLS 加密的例子。替换 CERT 和 DOMAIN_NAME 为你自己的服务器配置。
　　$DefaultNetstreamDriverCAFile /etc/rsyslog.d/keys/ca.d/CERT.crt
　　$ActionSendStreamDriver gtls
　　$ActionSendStreamDriverMode 1
　　$ActionSendStreamDriverAuthMode x509/name
　　$ActionSendStreamDriverPermittedPeer *.DOMAIN_NAME.com
　　应用日志的佳管理方法
　　除 Linux 默认创建的日志之外，归集重要的应用日志也是一个好主意。几乎所有基于 Linux 的服务器应用都把它们的状态信息写入到独立、专门的日志文件中。这包括数据库产品，像 PostgreSQL 或者 MySQL，网站服务器，像 Nginx 或者 Apache，防火墙，打印和文件共享服务，目录和 DNS 服务等等。
　　管理员安装一个应用后要做的第一件事是配置它。Linux 应用程序典型的有一个放在 /etc 目录里 .conf 文件。它也可能在其它地方，但是那是大家找配置文件首先会看的地方。
　　根据应用程序有多复杂多庞大，可配置参数的数量可能会很少或者上百行。如前所述，大多数应用程序可能会在某种日志文件写它们的状态：配置文件是定义日志设置和其它东西的地方。
　　如果你不确定它在哪，你可以使用locate命令去找到它：
　　[root@localhost ~]# locate postgresql.conf
　　/usr/pgsql-9.4/share/postgresql.conf.sample
　　/var/lib/pgsql/9.4/data/postgresql.conf
　　设置一个日志文件的标准位置
　　Linux 系统一般保存它们的日志文件在 /var/log 目录下。一般是这样，但是需要检查一下应用是否保存它们在 /var/log 下的特定目录。如果是，很好，如果不是，你也许想在 /var/log 下创建一个专用目录？为什么？因为其它程序也在 /var/log 下保存它们的日志文件，如果你的应用保存超过一个日志文件 – 也许每天一个或者每次重启一个 – 在这么大的目录也许有点难于搜索找到你想要的文件。
　　如果在你网络里你有运行多于一个的应用实例，这个方法依然便利。想想这样的情景，你也许有一打 web 服务器在你的网络运行。当排查任何一个机器的问题时，你很容易知道确切的位置。
　　使用一个标准的文件名
　　给你的应用新的日志使用一个标准的文件名。这使一些事变得容易，因为你可以监控和追踪一个单独的文件。很多应用程序在它们的日志文件上追加一种时间戳。它让 rsyslog 更难于找到新的文件和设置文件监控。一个更好的方法是使用日志轮转给老的日志文件增加时间。这样更易去归档和历史查询。
　　追加日志文件
　　日志文件会在每个应用程序重启后被覆盖吗？如果这样，我们建议关掉它。每次重启 app 后应该去追加日志文件。这样，你可以追溯重启前后的日志。
　　日志文件追加 vs. 轮转
　　要是应用程序每次重启后写一个新日志文件，如何保存当前日志？追加到一个单独的、巨大的文件？Linux 系统并不以频繁重启或者崩溃而出名：应用程序可以运行很长时间甚至不间歇，但是也会使日志文件非常大。如果你查询分析上周发生连接错误的原因，你可能无疑的要在成千上万行里搜索。
　　我们建议你配置应用每天半晚轮转（rotate）它的日志文件。
　　为什么？首先它将变得可管理。找一个带有特定日期的文件名比遍历一个文件中指定日期的条目更容易。文件也小的多：你不用考虑当你打开一个日志文件时 vi 僵住。第二，如果你正发送日志到另一个位置 – 也许每晚备份任务拷贝到归集日志服务器 – 这样不会消耗你的网络带宽。后第三点，这样帮助你做日志保留。如果你想剔除旧的日志记录，这样删除超过指定日期的文件比用一个应用解析一个大文件更容易。
　　日志文件的保留
　　你保留你的日志文件多长时间？这可以归结为业务需求。你可能被要求保持一个星期的日志信息，或者管理要求保持一年的数据。无论如何，日志需要在一个时刻或其它情况下从服务器删除。
　　在我们看来，除非必要，只在线保持近一个月的日志文件，并拷贝它们到第二个地方如日志服务器。任何比这更旧的日志可以被转到一个单独的介质上。例如，如果你在 AWS 上，你的旧日志可以被拷贝到 Glacier。
　　给日志单独的磁盘分区
　　更好的，Linux 通常建议挂载到 /var 目录到一个单独的文件系统。这是因为这个目录的高 I/O。我们推荐挂载 /var/log 目录到一个单独的磁盘系统下。这样可以节省与主要的应用数据的 I/O 竞争。另外，如果一些日志文件变的太多，或者一个文件变的太大，不会占满整个磁盘。
　　日志条目
　　每个日志条目中应该捕获什么信息？
　　这依赖于你想用日志来做什么。你只想用它来排除故障，或者你想捕获所有发生的事？这是一个捕获每个用户在运行什么或查看什么的规则条件吗？
　　如果你正用日志做错误排查的目的，那么只保存错误，报警或者致命信息。没有理由去捕获调试信息，例如，应用也许默认记录了调试信息或者另一个管理员也许为了故障排查而打开了调试信息，但是你应该关闭它，因为它肯定会很快的填满空间。在低限度上，捕获日期、时间、客户端应用名、来源 ip 或者客户端主机名、执行的动作和信息本身。