ASPIRE

用Rsyslog进行可靠的日志转发

=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 /rsyslog/work # 设置默认的存放路径
# ...
$ActionQueueType LinkedList # use asynchronous processing
$ActionQueueFileName srvrfwd # 设置磁盘上的文件名
$ActionResumeRetryCount -1 # infinite retries on insert failure
$ActionQueueSaveOnShutdown on # save in-memory data if rsyslog shuts down
# ...
如何转发至多台机器：

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

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

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

=END=

admin

, ,

《 “用Rsyslog进行可靠的日志转发” 》 有 10 条评论

  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/

    回复

  3. 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
    & ~
    `

    回复

  4. `
    默认情况下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/

    回复

  6. 请自查！这些优秀日志实践准则，你做到了几点？
    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编程规范-日志部分

    回复

  7. 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 不足、系统负载过高等）
    四、应用丢包
    五、查找包丢在什么地方
    `

    回复

  8. 如何判断是否丢掉用户请求
    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则不会输出对应的行。
    `

    回复

  10. https://www.rsyslog.com/doc/v8-stable/configuration/converting_to_new_format.html#converting-action-chains
    `
    # 如果msg中包含 error 字符串，则把该消息转发到另一台服务器10.11.12.13上
    ## 历史写法1
    :msg, contains, “error” @10.11.12.13
    & ~

    ## 历史写法2
    :msg, contains, “error” @10.11.12.13
    & stop

    ## 现代写法(推荐)
    if $msg contains “error” then {
    action(type=”omfwd” target=”10.11.12.13″ protocol=”udp”)
    stop
    }
    `

    回复

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注