用Rsyslog进行可靠的日志转发

本文最后更新于2016年12月17日,已超过 1 年没有更新,如果文章内容失效,还请反馈给我,谢谢!

=Start=

缘由:

最近在学习研究rsyslog的配置和使用,看着这个功能挺实用的,就想着翻译成中文,方便自己参考。

英文地址:http://www.rsyslog.com/doc/v8-stable/tutorials/reliable_forwarding.html

正文:

参考解答:
摘要:

在本文中,我会描述如何(非常)可靠的通过rsyslog转发syslog日志到一个中央日志服务器上去。这需要在client机器上安装有rsyslog,同时也推荐在server机器上安装rsyslog。需要注意的是:工业标准的plain-TCP-syslog协议并不是完全可靠的。如果你需要一个真的非常可靠的解决方案,可以试试rsyslog支持的 RELP 协议。

目标:

只要2个系统通过网络进行通信,错误就可能会发生。比如:通信链路可能会down掉,客户端或服务器端可能会终止,即便是在常规场景中,服务器也可能因为例行维护而停止服务一段时间。

一个可靠的日志系统应该在server端不可达的时候保证日志不丢失,为了做到这点,在server端不可用的时候,未发送的数据就应该被缓存在client上。因此当server端重启之后,消息又能够被重新发送出去。

通过rsyslog你可以轻易地做到这一点。在rsyslog中,每一个Action都是运行在自己的queue中的,而且每个queue在Action没有准备好的时候都能够缓存数据。需要注意的是,只能通过plain-tcp-rsyslog协议和RELP协议做到这一点(检测Action准备好了没有)。

我们这在讲的内容是rsyslog的特性,所以在client上必须要装有rsyslog。

日志内容先是会被缓存到内存里面,queue的内存不够用了之后才会缓存至磁盘。这么做是出于性能的考虑。

如何设置:

如何转发至多台机器:

一个转发目标对应一个转发规则(除了WorkDirectory之外,其它都需要写全)

关于可靠性还有一点要说的是:

使用plain-tcp-syslog协议会比普通的UDP-syslog协议可靠很多,但是,它也不是完全可靠的,如果你需要完全可靠,请使用 RELP 协议。原因的话可以参考文章:http://blog.gerhards.net/2008/04/on-unreliability-of-plain-tcp-syslog.html 。

=END=

声明: 除非注明,ixyzero.com文章均为原创,转载请以链接形式标明本文地址,谢谢!
https://ixyzero.com/blog/archives/3069.html

《用Rsyslog进行可靠的日志转发》上有8条评论

  1. Shell:logger -t "Security" -p local1.debug "$(date +'%F_%T')@$HOSTNAME"
    Python:https://docs.python.org/2/library/syslog.html
    Java:http://syslog4j.org/

  2. Linux的rsyslog配置
    http://cn.linux.vbird.org/linux_basic/0570syslog.php#syslogd_conf

    服务名称[.=!]信息等级 信息记录的档名或装置或主机

    mail.info /var/log/maillog_info
    # 上面这一行说明:mail 服务产生的「大于等于」 info 等级的信息,都记录到 /var/log/maillog_info 文件中的意思。
    mail.* -/var/log/maillog
    # 上面这一行说明:mail 服务产生的信息,都记录到 /var/log/maillog_info 文件中的意思。在记录的文件 /var/log/maillog 前面还有个减号『 - 』是干嘛用的?由于邮件所产生的信息比较多,因此我们希望邮件产生的信息先储存在速度较快的内存中 (buffer) ,等到数据量够大了才一次性的将所有数据都写入磁盘中,这样将有助于提升文件的存取性能。只不过由於信息是缓存在内存内,因此若不正常关机导致登录资讯未回填到登录文件中,可能会造成部分数据的遗失。

    local6.notice @192.168.10.199:514
    # 上面这一行说明:local6 服务产生的大于等于 notice 等级的信息,都以 UDP 协议转发到 192.168.10.199 机器上的 514 端口上。

    local6.notice @@192.168.10.199:514
    # 上面这一行说明:local6 服务产生的大于等于 notice 等级的信息,都以 TCP 协议转发到 192.168.10.199 机器上的 514 端口上。

    # rsyslog支持在转发至远程服务器的同时也在本地存一份,示例如下:
    local6.notice @@192.168.10.199:514
    local6.notice /var/log/local6_notice
    & ~

    # rsyslog根据服务名称和tag进行分类处理
    if $syslogfacility-text == 'local6' and $syslogtag == 'Security:' then -/var/log/Security.log
    & ~


  3. 默认情况下glibc中的syslog()函数是先将日志写入/dev/log这个UNIX域套接字中,然后由syslogd/rsyslogd进行消费:
    syslog() -> /dev/log -> rsyslogd -> local file/remote server

    但syslog()这个函数是阻塞式的,所以可能存在rsyslogd进程hang住导致syslog()调用卡住,整个系统hang住的可能:
    syslog()[blocked] <- /dev/log[buffer filled up] <- rsyslogd[hang]

    http://www.linuxquestions.org/questions/red-hat-31/sshd-hangs-rsyslog-related-4175550947/
    http://b.kl3in.com/2011/10/ubuntu-server-slowly-stops-responding/

  4. 请自查!这些优秀日志实践准则,你做到了几点?
    https://mp.weixin.qq.com/s/1NS-Yp4bz7t_Mk9DT9htbg

    一、重新认识日志
    1、日志级别概述
    2、记录日志的时机
    3、警惕日志性能代价

    二、优秀的INFO、DEBUG实践
    1、使用场景
      线上问题跟踪
      场景还原
      监控调优
    2、日志内容
    3、INFO和DEBUG的选择
    4、注意事项

    三、优秀的WARN、ERROR实践
    1、使用时机和思路
    2、几个成长阶段
    3、方法和准则
    4、使用WARN和统计报警
    5、强调ERROR报警
    6、ERROR日志目标
    7、实用模板
    8、注意事项

    参考:
    https://www.slf4j.org/manual.html
    http://logging.apache.org/log4j/2.x/
    阿里java编程规范-日志部分

  5. linux 系统 UDP 丢包问题分析思路
    http://cizixs.com/2018/01/13/linux-udp-packet-drop-debug

    首先介绍一下 Linux 系统接收网络报文的过程:
    ① 首先网络报文通过物理网线发送到网卡
    ② 网络驱动程序(Network Driver)会把网络中的报文读出来放到 ring buffer 中,这个过程使用 DMA(Direct Memory Access),不需要 CPU 参与
    ③ 内核从 ring buffer 中读取报文进行处理,执行 IP 和 TCP/UDP 层的逻辑,最后把报文放到应用程序的 socket buffer 中
    ④ 应用程序从 socket buffer 中读取报文进行处理
    在接收 UDP 报文的过程中,以上任何一个过程都可能会主动或者被动地把报文丢弃,因此丢包可能发生在网卡和驱动,也可能发生在系统和应用。

    一、确认有 UDP 丢包发生
    二、网卡或者驱动丢包
    三、Linux 系统丢包(常见的有:UDP 报文错误、防火墙、UDP buffer size 不足、系统负载过高等)
    四、应用丢包
    五、查找包丢在什么地方

  6. 如何判断是否丢掉用户请求
    http://blog.sina.com.cn/s/blog_5374d6e30101lex3.html
    http://blog.sina.cn/dpool/blog/s/blog_5374d6e30101lex3.html
    http://carlosfu.iteye.com/blog/2253904

    下面是可能丢数据包的点:
    1、交换机
    上连和下连端口的流量跑满或链路有问题,有些数据包会被交换机丢掉,抓对应端口的丢包计数值就可以获得这方面的数据。当然,不会每次都丢建立连接的syn数据包,另外,客户端也重传数据包,所以这一块不一定会导致请求数据的丢失,但可以作为参考。

    2、负载均衡设备
    这个跟上面的交换机类似,但除了有出错的数据包方面的数据,还有出错的连接方面的数据。抓取方法呢,完全设备相关,不在这里说了。

    3、操作系统处理不过来,丢弃数据
    这里有两部分,一是网卡见操作系统处理不过来,丢数据包,可以读取下面的文件:
    /proc/net/dev
    每个网络接口一行统计数据,4列是接收出错的数据包数量,5列是接收不过来丢弃的数量。
    第二部分是传统非NAPI接口实现的网卡驱动,每个cpu有一个队列,当在队列中缓存的数据包数量超过netdev_max_backlog(sysctl -w net.core.netdev_max_backlog可以修改)限制时,网卡驱动程序会丢掉数据包,这个见下面的文件:
    /proc/net/softnet_stat
    每个cpu有一行统计数据,第二列是对应cpu丢弃的数据包数量。

    4、应用程序处理不过来,操作系统丢弃
    内核中记录了两个计数器:ListenOverflows,ListenDrops
    ListenOverflows:对应socket的listen queue已满的情况下,需要新增一个连接时的情况,一般是应用程序处理不过来的情况;
    ListenDrops:包含上面的情况,也就是说当出现ListenOverflows时,它也会增加1;除此之外,当内存不够无法为新的连接分配socket相关的数据结构时,也会增加1,当然还有别的异常情况下会增加1。
    对应的数据在下面的文件中:
    /proc/net/netstat
    第21列是ListenOverflows值,22列是ListenDrops值。
    用下面命令,可以直接显示这两个数:
    cat /proc/net/net stat | awk '/TcpExt/ { print $21,$22 }'
    如果是netstat命令,则看“times the listen queue of a socket overflowed”, “SYNs to LISTEN sockets ignored”对应行前面的数字。如果没有对应的行,则表明对应的数值为0。如果是0,netstat则不会输出对应的行。

发表评论

电子邮件地址不会被公开。 必填项已用*标注