本文主要用于介绍CoreDNS用来记录日志的几种方式以及在生产环境中遇到的一些问题和解决方案。
1、log插件
coredns的日志输出并不如nginx那么完善(并不能在配置文件中指定输出的文件目录,但是可以指定日志的格式),默认情况下不论是log插件还是error插件都会把所有的相关日志输出到程序的standard output
中。使用systemd来管理coredns之后,默认情况下基本就是由rsyslog
和systemd-journald
这两个服务来管理日志。
1.1 log插件配置
前面的文章里我们有简单的介绍过coredns的日志处理,对于log插件也是类似的操作。考虑到CentOS8已经结束支持,这里仅介绍CentOS7的配置方法,更高版本的systemd
可以参考之前的文章。
对于centos7等系统而言,是不支持在高版本的systemd中的unit
文件中使用append
和file
两个参数的,并且对于这种方式输出的日志缺少了前面的时间和主机名等信息,相对而言还是修改rsyslog的方式要更加的可靠。那么在开启了rsyslog.service
服务的情况下,日志就会输出到/var/log/messages
文件中,或者可以使用journalctl -u coredns
命令来查看全部的日志。
如果想要将coredns的日志全部集中到一个文件进行统一管理,我们可以对负责管理systemd
的日志的rsyslog
服务的配置进行修改,然后再重启rsyslog服务即可生效。
# 注意这段配置需要添加在其他日志配置规则之前
# 否则日志会在/var/log/messages和/home/coredns/logs/coredns.log都写入一份
[root@tiny-server coredns]# vim /etc/rsyslog.conf
if $programname == 'coredns' then /home/coredns/logs/coredns.log
& stop
[root@tiny-server coredns]# systemctl restart rsyslog.service
但是有两点需要额外注意:
- CoreDNS在开启日志记录之后的性能要差于不开启日志记录,这个很容易理解,因为记录日志需要耗费额外的资源,尤其是当QPS增大之后,记录日志组件的压力也会增大,需要注意两个服务对资源的抢占和分配是否合理;如果遇到写入日志占用大量资源的情况,可以考虑将其配置为只写入部分类型日志(如只写入错误日志)
rsyslog
和systemd-journald
这两个服务默认情况下都会对日志的写入频率进行限制,当QPS增大之后,记录的日志会不完整;当然这个问题可以通过调整rsyslog的参数解决
1.2 rsyslog配置
下面具体介绍一下如何配置rsyslog
和systemd-journald
解除相关的日志限制。
默认情况下我们查看systemd-journald.service
的日志或者是查看/var/log/messages
文件,如果看到类似下面的提示信息,就说明日志的输出频率太高被抑制了
[root@tiny-server coredns]# systemctl status systemd-journald.service
● systemd-journald.service - Journal Service
Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service; static; vendor preset: disabled)
Active: active (running) since Wed 2021-12-01 09:30:03 CST; 3 weeks 6 days ago
Docs: man:systemd-journald.service(8)
man:journald.conf(5)
Main PID: 709 (systemd-journal)
Status: "Processing requests..."
CGroup: /system.slice/systemd-journald.service
└─709 /usr/lib/systemd/systemd-journald
Dec 28 15:36:27 tiny-server systemd-journal[709]: Suppressed 13174 messages from /system.slice/coredns.service
Dec 28 15:36:57 tiny-server systemd-journal[709]: Suppressed 13185 messages from /system.slice/coredns.service
Dec 28 15:37:27 tiny-server systemd-journal[709]: Suppressed 11600 messages from /system.slice/coredns.service
Dec 28 15:37:57 tiny-server systemd-journal[709]: Suppressed 13896 messages from /system.slice/coredns.service
Dec 28 15:38:27 tiny-server systemd-journal[709]: Suppressed 13653 messages from /system.slice/coredns.service
Dec 28 15:38:57 tiny-server systemd-journal[709]: Suppressed 16503 messages from /system.slice/coredns.service
Dec 28 15:39:27 tiny-server systemd-journal[709]: Suppressed 13300 messages from /system.slice/coredns.service
Dec 28 15:39:57 tiny-server systemd-journal[709]: Suppressed 10491 messages from /system.slice/coredns.service
Dec 28 15:40:27 tiny-server systemd-journal[709]: Suppressed 12079 messages from /system.slice/coredns.service
Dec 28 15:40:57 tiny-server systemd-journal[709]: Suppressed 17182 messages from /system.slice/coredns.service
[root@tiny-server coredns]# tail -f /var/log/messages
Dec 28 15:43:55 tiny-server rsyslogd: imjournal: begin to drop messages due to rate-limiting
解决方案也比较简单,我们对这两个服务的配置参数进行调整,将限制日志写入频率和写入时间间隔都设为0(即不做限制),然后重启服务即可。
echo "RateLimitInterval=0" >> /etc/systemd/journald.conf
echo "RateLimitBurst=0" >> /etc/systemd/journald.conf
systemctl restart systemd-journald.service
echo "\$imjournalRatelimitInterval 0" >> /etc/rsyslog.conf
echo "\$imjournalRatelimitBurst 0" >> /etc/rsyslog.conf
systemctl restart rsyslog.service
需要特别注意的是:上述两个参数对所有使用rsyslog的服务都会生效,如果有其他大量写入日志的服务,建议调整日志文件输出目录,同时关注/var/log
等目录的硬盘空间情况。
2、dnstap插件
CoreDNS的原生日志功能对于一个DNS服务器的绝大部分应用场景来说是足够使用的,如果有更进阶的需求,可以考虑使用dnstap
插件来实现。
dnstap是一个基于谷歌的缓冲区协议(Protocol buffers)实现的用于DNS的灵活的、结构化的、二进制日志格式记录软件,目前已经获得了bind9、unbound、coredns、knot等几乎所有主流dns软件的支持。dnstap目前支持二进制日志格式、text日志格式、yaml日志格式和json日志格式。
CoreDNS官网对于dnstap插件的介绍比较简单,不过官网页面有比较详细的介绍。
dnstap
is a flexible, structured binary log format for DNS software. It uses Protocol Buffers to encode events that occur inside DNS software in an implementation-neutral format.Currently
dnstap
can only encode wire-format DNS messages. It is planned to support additional types of DNS log information.
Protocol buffers are Google’s language-neutral, platform-neutral, extensible mechanism for serializing structured data – think XML, but smaller, faster, and simpler. You define how you want your data to be structured once, then you can use special generated source code to eas