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

本文涉及的产品
对象存储 OSS,20GB 3个月
阿里云盘企业版 CDE,企业版用户数5人 500GB空间
对象存储 OSS,内容安全 1000次 1年
简介: 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"

       }

   ]

}




参考

目录
相关文章
|
9天前
|
JSON 前端开发 搜索推荐
关于商品详情 API 接口 JSON 格式返回数据解析的示例
本文介绍商品详情API接口返回的JSON数据解析。最外层为`product`对象,包含商品基本信息(如id、name、price)、分类信息(category)、图片(images)、属性(attributes)、用户评价(reviews)、库存(stock)和卖家信息(seller)。每个字段详细描述了商品的不同方面,帮助开发者准确提取和展示数据。具体结构和字段含义需结合实际业务需求和API文档理解。
|
2天前
|
JSON 缓存 API
解析电商商品详情API接口系列,json数据示例参考
电商商品详情API接口是电商平台的重要组成部分,提供了商品的详细信息,支持用户进行商品浏览和购买决策。通过合理的API设计和优化,可以提升系统性能和用户体验。希望本文的解析和示例能够为开发者提供参考,帮助构建高效、可靠的电商系统。
20 12
|
4天前
|
存储 人工智能 NoSQL
Tablestore深度解析:面向AI场景的结构化数据存储最佳实践
《Tablestore深度解析:面向AI场景的结构化数据存储最佳实践》由阿里云专家团队分享,涵盖Tablestore十年发展历程、AI时代多模态数据存储需求、VCU模式优化、向量检索发布及客户最佳实践等内容。Tablestore支持大规模在线数据存储,提供高性价比、高性能和高可用性,特别针对AI场景进行优化,满足结构化与非结构化数据的统一存储和高效检索需求。通过多元化索引和Serverless弹性VCU模式,助力企业实现低成本、灵活扩展的数据管理方案。
33 12
|
7天前
|
存储 分布式计算 Hadoop
基于Java的Hadoop文件处理系统:高效分布式数据解析与存储
本文介绍了如何借鉴Hadoop的设计思想,使用Java实现其核心功能MapReduce,解决海量数据处理问题。通过类比图书馆管理系统,详细解释了Hadoop的两大组件:HDFS(分布式文件系统)和MapReduce(分布式计算模型)。具体实现了单词统计任务,并扩展支持CSV和JSON格式的数据解析。为了提升性能,引入了Combiner减少中间数据传输,以及自定义Partitioner解决数据倾斜问题。最后总结了Hadoop在大数据处理中的重要性,鼓励Java开发者学习Hadoop以拓展技术边界。
34 7
|
22天前
|
JSON JavaScript 前端开发
一次采集JSON解析错误的修复
两段采集来的JSON格式数据存在格式问题,直接使用PHP的`json_decode`会报错。解决思路包括:1) 手动格式化并逐行排查错误;2) 使用PHP-V8JS扩展在JavaScript环境中解析。具体方案一是通过正则表达式和字符串替换修复格式,方案二是利用V8Js引擎执行JS代码并返回JSON字符串,最终实现正确解析。 简介: 两段采集的JSON数据因掺杂JavaScript代码导致PHP解析失败。解决方案包括手动格式化修复和使用PHP-V8JS扩展在JavaScript环境中解析,确保JSON数据能被正确处理。
|
2月前
|
数据采集 自然语言处理 搜索推荐
基于qwen2.5的长文本解析、数据预测与趋势分析、代码生成能力赋能esg报告分析
Qwen2.5是一款强大的生成式预训练语言模型,擅长自然语言理解和生成,支持长文本解析、数据预测、代码生成等复杂任务。Qwen-Long作为其变体,专为长上下文场景优化,适用于大型文档处理、知识图谱构建等。Qwen2.5在ESG报告解析、多Agent协作、数学模型生成等方面表现出色,提供灵活且高效的解决方案。
265 49
|
2月前
|
存储 缓存 监控
后端开发中的缓存机制:深度解析与最佳实践####
本文深入探讨了后端开发中不可或缺的一环——缓存机制,旨在为读者提供一份详尽的指南,涵盖缓存的基本原理、常见类型(如内存缓存、磁盘缓存、分布式缓存等)、主流技术选型(Redis、Memcached、Ehcache等),以及在实际项目中如何根据业务需求设计并实施高效的缓存策略。不同于常规摘要的概述性质,本摘要直接点明文章将围绕“深度解析”与“最佳实践”两大核心展开,既适合初学者构建基础认知框架,也为有经验的开发者提供优化建议与实战技巧。 ####
|
1月前
|
监控 数据管理 测试技术
API接口自动化测试深度解析与最佳实践指南
本文详细介绍了API接口自动化测试的重要性、核心概念及实施步骤,强调了从明确测试目标、选择合适工具、编写高质量测试用例到构建稳定测试环境、执行自动化测试、分析测试结果、回归测试及集成CI/CD流程的全过程,旨在为开发者提供一套全面的技术指南,确保API的高质量与稳定性。
|
1月前
|
PHP 开发者 容器
PHP命名空间深度解析及其最佳实践####
本文深入探讨了PHP中引入命名空间的重要性与实用性,通过实例讲解了如何定义、使用及别名化命名空间,旨在帮助开发者有效避免代码冲突,提升项目的模块化与可维护性。同时,文章还涉及了PHP-FIG标准,引导读者遵循最佳实践,优化代码结构,促进团队协作效率。 ####
32 1
|
1月前
|
Java 数据库连接 开发者
Java中的异常处理机制:深入解析与最佳实践####
本文旨在为Java开发者提供一份关于异常处理机制的全面指南,从基础概念到高级技巧,涵盖try-catch结构、自定义异常、异常链分析以及最佳实践策略。不同于传统的摘要概述,本文将以一个实际项目案例为线索,逐步揭示如何高效地管理运行时错误,提升代码的健壮性和可维护性。通过对比常见误区与优化方案,读者将获得编写更加健壮Java应用程序的实用知识。 --- ####

推荐镜像

更多