SLS数据加工——动态解析与分发日志实战

本文涉及的产品
对象存储 OSS,20GB 3个月
对象存储 OSS,内容安全 1000次 1年
文件存储 NAS,50GB 3个月
简介: 阿里云日志服务提供可托管、可扩展、高可用的数据加工服务。数据加工服务可用于数据的规整、富化、流转、脱敏和过滤。本文为读者带来了数据加工动态解析与分发的最佳实践。

背景

阿里云日志服务提供可托管、可扩展、高可用的数据加工服务。数据加工服务可用于数据的规整、富化、流转、脱敏和过滤。本文为读者带来了数据加工动态解析与分发的最佳实践。


场景

现有多个不同的APP,所有APP的程序运行日志都输入到同一个中心Logstore中。每个APP的日志都是以分隔符分隔的文本日志,但是日志字段schema各不相同。日志样例如下:

APP_1的日志样例
content: schema_app1|113.17.4.39|www.zsc.mock.com|PUT|1082|404|https|28.3|Mozilla/5.0
APP_2的日志样例
content: schema_app2|183.93.165.82|db-01|MySQL|5.5|0|cn-shanghai|1072|user-2
APP_3的日志样例
content: schema_app3|root|container4|image3|www.jd.mock.com|221.176.106.202|200|01/Apr/2021:06:27:56

上述APP的日志格式为:"schema_id|字段值1|字段值2|字段值3..."

  • schema_id为该日志的字段schema的ID
  • "字段值X"是日志的各个字段值,每个字段值的字段名由schema_id对应schema定义。


所有schema的定义存储在OSS的一个文件中,并与schema_id一一映射。Schema定义文件的内容格式如下:

{
  "schema_app1": {
    "fields": ["client_ip", "host", "http_method", "resquest_length", "status_code", "request_time", "user_agent"],
    "logstore": "logstore_app1"
  },
  "schema_app2": {
    "fields": ["client_ip", "db_name", "db_type", "db_version", "fail", "region", "check_rows", "user_name"],
    "logstore": "logstore_app2"
  },
  "schema_app3": {
    "fields": ["user", "container_name", "image_name", "referer", "container_ip", "status_code", "datetime"],
    "logstore": "logstore_app3"
  },
}

其中schema_app1等是schema_id。每个schema的定义包含两个字段,fields和logstore,fields定义了该schema对应的字段名列表,logstore定义了该schema的日志要分发的目标logstore名。


需求

  1. 对中心Logstore中不同Schema的日志进行动态解析(Schema在动态变化),将分隔符分隔的各个字段值映射到对应的字段名上,形成结构化的日志。
  2. 不同Schema的日志分发到不同的Logstore中。


例子:

  • 中心Logstore的原始日志
content: schema_app1|113.17.4.39|www.zsc.mock.com|PUT|1082|404|https|28.3|Mozilla/5.0
content: schema_app2|183.93.165.82|db-01|MySQL|5.5|0|cn-shanghai|1072|user-2


  • 加工后的日志
输出到logstore_app1:
{"client_ip": "113.17.4.39", "host": "www.zsc.mock.com", "http_method": "PUT", "resquest_length": 1082, "status_code": 404, "request_time": 28.3, "user_aent": "Mozilla/5.0"}
输出到logstore_app2:
{"client_ip": "183.93.165.82", "db_name": "db-01", "db_type": "MySQL", "db_version": "5.5", "fail": 0, "region": "cn-shanghai", "check_rows": 1072, "user_name": "user-2"}


数据加工语法

数据加工的创建流程参考创建数据加工任务

# 1.原始日志切分出schema_id和日志内容raw_content
e_set("split_array", str_partition(v("content"), "|"))
e_set("schema_id", lst_get(v("split_array"), 0))
e_set("raw_content", lst_get(v("split_array"), 2))
# 2.根据schema_id从OSS读取对应的schema内容
e_set(
    "schema",
    dct_get(
        res_oss_file(
            endpoint="http://oss-cn-hangzhou.aliyuncs.com",
            ak_id=res_local("AK_ID"),
            ak_key=res_local("AK_KEY"),
            bucket="ali-licheng-demo",
            file="schema_lib/schema.json",
            change_detect_interval=20,
        ),
        v("schema_id"),
    ),
)
# 3.从schema中读取字段名列表fields和分发的目标Logstore
e_set("fields", dct_get(v("schema"), "fields"))
e_set("target_logstore", dct_get(v("schema"), "logstore"))
# 丢弃多余字段
e_keep_fields("raw_content", "fields", "target_logstore", F_TIME, F_META)
# 4.解析分隔符日志,并映射到fields中的字段上
e_psv("raw_content", json_parse(v("fields")))
# 丢弃多余字段
e_drop_fields("fields", "raw_content")
# 5.根据schema中定义的logstore名,动态分发
e_output(project="licheng-simulator-test", logstore=v("target_logstore"))


上述加工语法的加工总体流程如下:

1.将原始日志切分出schema_id和日志内容raw_content,即:

原始日志:
content: schema_app1|113.17.4.39|www.zsc.mock.com|PUT|1082|404|https|28.3|Mozilla/5.0
切分为:
schema_id: schema_app1
raw_content: 113.17.4.39|www.zsc.mock.com|PUT|1082|404|https|28.3|Mozilla/5.0


2.根据schema_id从OSS读取对应的schema内容

3. 从schema中读取字段名列表fields和分发的目标Logstore

  • 每个schema中都定义了该schema日志的字段名列表以及分发的目标Logstore名

4.解析分隔符日志,并映射到fields中的字段上

5.根据schema中定义的分发logstore名,实现日志的动态分发。


加工后的结果示例


后续维护

后续维护过程中,如果APP日志的Schema发生变化,或者有新的APP日志进来,只需在OSS中的schema库文件中修改和增加对应APP的schema定义即可,无需对加工任务做任何修改。

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
3天前
|
缓存 Java 编译器
|
11天前
|
人工智能 运维 监控
一招高效解析 Access Log,轻松应对泼天流量
一招高效解析 Access Log,轻松应对泼天流量
|
20天前
|
存储 缓存 关系型数据库
图解MySQL【日志】——Redo Log
Redo Log(重做日志)是数据库中用于记录数据页修改的物理日志,确保事务的持久性和一致性。其主要作用包括崩溃恢复、提高性能和保证事务一致性。Redo Log 通过先写日志的方式,在内存中缓存修改操作,并在适当时候刷入磁盘,减少随机写入带来的性能损耗。WAL(Write-Ahead Logging)技术的核心思想是先将修改操作记录到日志文件中,再择机写入磁盘,从而实现高效且安全的数据持久化。Redo Log 的持久化过程涉及 Redo Log Buffer 和不同刷盘时机的控制参数(如 `innodb_flush_log_at_trx_commit`),以平衡性能与数据安全性。
28 5
图解MySQL【日志】——Redo Log
|
22天前
|
存储 关系型数据库 MySQL
图解MySQL【日志】——Undo Log
Undo Log(回滚日志)是 MySQL 中用于实现事务原子性和一致性的关键机制。在默认的自动提交模式下,MySQL 隐式开启事务,每条增删改语句都会记录到 Undo Log 中。其主要作用包括:
35 0
|
1月前
|
XML JSON Java
Java中Log级别和解析
日志级别定义了日志信息的重要程度,从低到高依次为:TRACE(详细调试)、DEBUG(开发调试)、INFO(一般信息)、WARN(潜在问题)、ERROR(错误信息)和FATAL(严重错误)。开发人员可根据需要设置不同的日志级别,以控制日志输出量,避免影响性能或干扰问题排查。日志框架如Log4j 2由Logger、Appender和Layout组成,通过配置文件指定日志级别、输出目标和格式。
|
1月前
|
存储 SQL 关系型数据库
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log、原理、写入过程;binlog与redolog区别、update语句的执行流程、两阶段提交、主从复制、三种日志的使用场景;查询日志、慢查询日志、错误日志等其他几类日志
115 35
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log
|
2月前
|
SQL 关系型数据库 MySQL
MySQL事务日志-Undo Log工作原理分析
事务的持久性是交由Redo Log来保证,原子性则是交由Undo Log来保证。如果事务中的SQL执行到一半出现错误,需要把前面已经执行过的SQL撤销以达到原子性的目的,这个过程也叫做"回滚",所以Undo Log也叫回滚日志。
123 7
MySQL事务日志-Undo Log工作原理分析
|
3月前
|
监控 安全 Apache
什么是Apache日志?为什么Apache日志分析很重要?
Apache是全球广泛使用的Web服务器软件,支持超过30%的活跃网站。它通过接收和处理HTTP请求,与后端服务器通信,返回响应并记录日志,确保网页请求的快速准确处理。Apache日志分为访问日志和错误日志,对提升用户体验、保障安全及优化性能至关重要。EventLog Analyzer等工具可有效管理和分析这些日志,增强Web服务的安全性和可靠性。
|
3月前
|
存储 监控 安全
什么是事件日志管理系统?事件日志管理系统有哪些用处?
事件日志管理系统是IT安全的重要工具,用于集中收集、分析和解释来自组织IT基础设施各组件的事件日志,如防火墙、路由器、交换机等,帮助提升网络安全、实现主动威胁检测和促进合规性。系统支持多种日志类型,包括Windows事件日志、Syslog日志和应用程序日志,通过实时监测、告警及可视化分析,为企业提供强大的安全保障。然而,实施过程中也面临数据量大、日志管理和分析复杂等挑战。EventLog Analyzer作为一款高效工具,不仅提供实时监测与告警、可视化分析和报告功能,还支持多种合规性报告,帮助企业克服挑战,提升网络安全水平。
131 2
|
4月前
|
存储 监控 安全
什么是日志管理,如何进行日志管理?
日志管理是对IT系统生成的日志数据进行收集、存储、分析和处理的实践,对维护系统健康、确保安全及获取运营智能至关重要。本文介绍了日志管理的基本概念、常见挑战、工具的主要功能及选择解决方案的方法,强调了定义管理目标、日志收集与分析、警报和报告、持续改进等关键步骤,以及如何应对数据量大、安全问题、警报疲劳等挑战,最终实现日志数据的有效管理和利用。
476 0

相关产品

  • 日志服务
  • 推荐镜像

    更多