【Logtail最佳实践】使用Logtail采集和解析Syslog数据

本文涉及的产品
对象存储 OSS,20GB 3个月
日志服务 SLS,月写入数据量 50GB 1个月
云备份 Cloud Backup,100GB 3个月
简介: Syslog是一种行业标准的协议,可用来记录设备的日志。常见的应用场景是网络管理工具、安全管理系统、日志审计系统。本文档介绍如何使用Logtail采集和解析Syslog数据。

目标读者

数字化系统开发运维(DevOps)工程师、稳定性工程师(SRE)、可观测平台运维人员等。

使用场景

Syslog是一种行业标准的协议,可用来记录设备的日志。常见的应用场景是网络管理工具、安全管理系统、日志审计系统。

本文档介绍如何使用Logtail采集和解析Syslog数据。

相关概念

Logtail

Logtail是日志服务提供的日志采集Agent,用于采集阿里云ECS、自建IDC、其他云厂商等服务器上的日志。本文介绍Logtail的功能、优势、使用限制及配置流程等信息。

Syslog

目前业界存在常见两种Syslog日志协议,一个是2009年的RFC5424协议,另外一个是2001年的RFC3164协议。以下介绍这两种协议的不同之处,以便在后续实践中能够灵活应用Logtail插件解析Syslog日志。

RFC5424协议

PRI VERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID SP MSGID

RFC5424协议包含以下字段信息,具体信息请参见官方协议

"""

Example1:

<34>1 2019-07-11T22:14:15.003Z aliyun.example.com ali - ID47 - BOM'su root' failed for lonvick on /dev/pts/8

"""

PRI -- 34

VERSION -- 1

TIMESTAMP -- 2019-07-11T22:14:15.003Z

HOSTNAME -- aliyun.example.com

APP-NAME -- ali

PROCID -- 无

MSGID -- ID47

MESSAGE -- 'su root' failed for lonvick on /dev/pts/8

"""

Example2:

<165>1 2019-07-11T22:14:15.000003-07:00 192.0.2.1 myproc 8710 - - %% It's time to make the do-nuts.

"""

PRI -- 165

VERSION -- 1

TIMESTAMP -- 2019-07-11T05:14:15.000003-07:00

HOSTNAME -- 192.0.2.1

APP-NAME -- myproc

PROCID -- 8710

STRUCTURED-DATA -- “-”

MSGID -- “-”

MESSAGE -- "%% It's time to make the do-nuts."

"""

Example3: - with STRUCTURED-DATA

<165>1 2019-07-11T22:14:15.003Z aliyun.example.com

          evntslog - ID47 [exampleSDID@32473 iut="3" eventSource=

          "Application" eventID="1011"] BOMAn application

          event log entry...

"""

PRI -- 165

VERSION -- 1

TIMESTAMP -- 2019-07-11T22:14:15.003Z

HOSTNAME -- aliyun.example.com

APP-NAME -- evntslog

PROCID -- "-"

MSGID -- ID47

STRUCTURED-DATA -- [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"]

MESSAGE -- An application event log entry...


RFC3164协议

PRI HEADER[TIME HOSTNAME] MSG

RFC3164协议包含以下字段信息,具体信息请参见官方协议

"""

<30>Oct 9 22:33:20 hlfedora auditd[1787]: The audit daemon is exiting.

"""

PRI -- 30

HEADER

- TIME -- Oct 9 22:33:20

- HOSTNAME -- hlfedora

MSG

- TAG -- auditd[1787]

- Content --The audit daemon is exiting.


方案架构

通过Logtail插件对指定的地址和端口进行监听后,Logtail开始采集数据,包括通过rsyslog采集的系统日志以及通过syslog客户端转发的日志。

方案实施

前提条件

  • 已部署好rsyslog
  • rsyslog目标IP的机器上已安装Logtail
  • 开通阿里云日志服务

操作步骤

场景一:采集Linux系统Syslog


步骤1:为rsyslog添加一条转发规则

  1. 在syslog所在的服务器上修改rsyslog的配置文件/etc/rsyslog.conf,在配置文件的最后添加一行转发规则。添加转发规则后,rsyslog会将syslog转发至指定IP地址和端口上。

UDP转发配置格式:

*.* @${日志服务器的ip}:{日志服务器的端口}  

TCP转发配置格式:

*.* @@${日志服务器的ip}:{日志服务器的端口}  


例如以下配置表示将所有的日志都通过TCP转发至127.0.0.1:9000,配置文件详细说明请参见RSyslog Documentation

*.* @@127.0.0.1:9000

ps:

  • 如果通过当前服务器采集本机syslog,配置转发地址为127.0.0.1,端口为任意非知名的空闲端口。
  • 如果通过其他服务器采集本机syslog,配置转发地址为其他服务器的公网IP,端口为任意非知名的空闲端口。
  1. 执行以下命令重启rsyslog,使日志转发规则生效。

sudo service rsyslog restart

步骤2:创建采集配置

1. 创建Project、Logstore

a. 登录日志服务控制台,在Project列表页面,选择已有的Project或者创建新的Project。

b. 在日志库标签页,选择已有Logstore或者单击+图标创建新的Logstore。

2. 创建/选择机器组

a. 在数据接入-> Logtail配置,点击+,接入数据

b. 快速数据接入页面,选择自定义数据插件。

c. 创建/选择机器组。

  • 如果您已有可用的机器组,请单击使用现有机器组
  • 如果您还没有可用的机器组,请执行以下操作(以ECS为例)。在ECS机器页签中,通过手动选择实例方式选择目标ECS实例,单击立即执行安装完成后,单击确认安装完毕
  • 创建机器组页面,输入名称,单击下一步。日志服务支持创建IP地址机器组和用户自定义标识机器组
3.  配置插件

同时监听UDP和TCP的示例配置如下:

{

    "inputs": [

        {

            "type": "service_syslog",

            "detail": {

                "Address": "tcp://127.0.0.1:9000",

                "ParseProtocol": "rfc3164"

            }

        },

        {

            "type": "service_syslog",

            "detail": {

                "Address": "udp://127.0.0.1:9001",

                "ParseProtocol": "rfc3164"

            }

        }

    ]

}

配置项

类型

是否必选

说明

type

string

数据源类型,固定为service_syslog

Address

string

指定Logtail插件监听的协议、地址和端口,Logtail插件会根据Logtail采集配置进行监听并获取日志数据。格式为[tcp/udp]://[ip]:[port]。不配置时,默认为tcp://127.0.0.1:9999


ParseProtocol

string

指定解析日志所使用的协议,默认为空,表示不解析。其中:

    • rfc3164:指定使用RFC3164协议解析日志。
    • rfc5424:指定使用RFC5424协议解析日志。
    • auto:指定插件根据日志内容自动选择合适的解析协议。

IgnoreParseFailure

boolean

指定解析失败后的操作,不配置时,默认为true,表示放弃解析,直接填充所返回的content字段。配置为false,表示解析失败时丢弃日志。


步骤3:验证采集结果



场景二:采集Windows系统Syslog

通过Windos的事件查看器,我们可以看到Windows系统的Syslog分成了两部分,一部分是Windows日志,一部分是应用程序和服务日志。

步骤1:  安装配置Rsyslog Windows Agent

安装步骤参考官网

通过Event Channels,我们可以选择rsyslog需要采集的日志

通过Rsyslog的配置,可以选择发送的目标地址(ip和端口)和发送的协议(TCP/UDP)

在Syslog Message Options的选项里,可以选择数据格式的协议,目前Logtail只支持解析rfc3164和rfc5424协议的数据。


步骤2:  创建采集配置

具体操作步骤同上,注意插件的配置需要和agent的配置相匹配:

{

   "inputs": [

       {

           "detail": {

               "ParseProtocol": "rfc3164",

               "Address": "tcp://192.168.0.171:1514"

           },

           "type": "service_syslog"

       }

   ]

}

步骤3: 验证采集结果

Syslog Test Message 工具

Rsyslog Windows agent提供了test message工具,可以将测试数据发送到指定的地址,用来确认网络的连通性。如果Logstore中没有成功采集到数据,使用此工具,可以验证是否有网络问题。

发送成功的样例

发送失败的样例

常见问题

  • 网络不通问题排查思路
  1. 端口是否被其他服务占用
  2. 是否有安全组配置或者防火墙等网络安全配置
  • 跨服务器转发syslog应该如何配置

例如有A(linux,192.168.0.171)和B(linux,192.168.0.172)两台服务器,Logtail可以只安装在其中一台上。

  • A和B的rsyslog 都使用如下配置,表示将所有的日志都通过TCP转发至192.168.0.171:1514即A 服务器上

*.* @@192.168.0.171:1514

  • 采集配置如下,即可监听192.168.0.171:1514端口,收集来自A和B两条机器上的数据

{

   "inputs": [

       {

           "detail": {

               "ParseProtocol": "rfc3164",

               "Address": "tcp://192.168.0.171:1514"

           },

           "type": "service_syslog"

       }

   ]

}




参考

目录
相关文章
|
1月前
|
消息中间件 存储 缓存
十万订单每秒热点数据架构优化实践深度解析
【11月更文挑战第20天】随着互联网技术的飞速发展,电子商务平台在高峰时段需要处理海量订单,这对系统的性能、稳定性和扩展性提出了极高的要求。尤其是在“双十一”、“618”等大型促销活动中,每秒需要处理数万甚至数十万笔订单,这对系统的热点数据处理能力构成了严峻挑战。本文将深入探讨如何优化架构以应对每秒十万订单级别的热点数据处理,从历史背景、功能点、业务场景、底层原理以及使用Java模拟示例等多个维度进行剖析。
55 8
|
1月前
|
数据采集 自然语言处理 搜索推荐
基于qwen2.5的长文本解析、数据预测与趋势分析、代码生成能力赋能esg报告分析
Qwen2.5是一款强大的生成式预训练语言模型,擅长自然语言理解和生成,支持长文本解析、数据预测、代码生成等复杂任务。Qwen-Long作为其变体,专为长上下文场景优化,适用于大型文档处理、知识图谱构建等。Qwen2.5在ESG报告解析、多Agent协作、数学模型生成等方面表现出色,提供灵活且高效的解决方案。
158 49
|
26天前
|
存储 缓存 监控
后端开发中的缓存机制:深度解析与最佳实践####
本文深入探讨了后端开发中不可或缺的一环——缓存机制,旨在为读者提供一份详尽的指南,涵盖缓存的基本原理、常见类型(如内存缓存、磁盘缓存、分布式缓存等)、主流技术选型(Redis、Memcached、Ehcache等),以及在实际项目中如何根据业务需求设计并实施高效的缓存策略。不同于常规摘要的概述性质,本摘要直接点明文章将围绕“深度解析”与“最佳实践”两大核心展开,既适合初学者构建基础认知框架,也为有经验的开发者提供优化建议与实战技巧。 ####
|
22天前
|
监控 数据管理 测试技术
API接口自动化测试深度解析与最佳实践指南
本文详细介绍了API接口自动化测试的重要性、核心概念及实施步骤,强调了从明确测试目标、选择合适工具、编写高质量测试用例到构建稳定测试环境、执行自动化测试、分析测试结果、回归测试及集成CI/CD流程的全过程,旨在为开发者提供一套全面的技术指南,确保API的高质量与稳定性。
|
20天前
|
PHP 开发者 容器
PHP命名空间深度解析及其最佳实践####
本文深入探讨了PHP中引入命名空间的重要性与实用性,通过实例讲解了如何定义、使用及别名化命名空间,旨在帮助开发者有效避免代码冲突,提升项目的模块化与可维护性。同时,文章还涉及了PHP-FIG标准,引导读者遵循最佳实践,优化代码结构,促进团队协作效率。 ####
24 1
|
23天前
|
XML JSON JavaScript
HttpGet 请求的响应处理:获取和解析数据
HttpGet 请求的响应处理:获取和解析数据
|
24天前
|
Java 数据库连接 开发者
Java中的异常处理机制:深入解析与最佳实践####
本文旨在为Java开发者提供一份关于异常处理机制的全面指南,从基础概念到高级技巧,涵盖try-catch结构、自定义异常、异常链分析以及最佳实践策略。不同于传统的摘要概述,本文将以一个实际项目案例为线索,逐步揭示如何高效地管理运行时错误,提升代码的健壮性和可维护性。通过对比常见误区与优化方案,读者将获得编写更加健壮Java应用程序的实用知识。 --- ####
|
1月前
|
Kubernetes 监控 API
深入解析Kubernetes及其在生产环境中的最佳实践
深入解析Kubernetes及其在生产环境中的最佳实践
49 1
|
1月前
|
API PHP 数据库
PHP中的异常处理机制深度解析与最佳实践####
本文深入探讨了PHP中异常处理机制的核心概念、工作原理及其在现代Web开发中的应用。通过剖析try-catch结构、自定义异常类及异常的继承体系,揭示了如何高效地捕获、处理并管理运行时错误,以提升应用的稳定性和用户体验。文章还结合实例,分享了在实际项目中实施异常处理的最佳实践,帮助开发者构建更加健壮的PHP应用程序。 ####
|
1月前
|
PHP 开发者
PHP 7新特性深度解析及其最佳实践
【10月更文挑战第31天】本文将深入探讨PHP 7带来的革新,从性能提升到语法改进,再到错误处理机制的变革。我们将通过实际代码示例,展示如何高效利用这些新特性来编写更加健壮和高效的PHP应用。无论你是PHP新手还是资深开发者,这篇文章都将为你打开一扇窗,让你看到PHP 7的强大之处。

推荐镜像

更多