日志服务数据加工:快速开始(SLB日志加工实战)

简介: 日志服务数据加工上线,本文以SLB日志加工实战为例,覆盖规则编写、控制台交互、权限配置、监控排错等

背景

这里我们拿一个Logstore中的网关数据(阿里云SLB日志)举例,对其数据进行加工并分发到不同的Logstore中。

数据

源logstore(slb-log)的数据内容是一个阿里云SLB的网络日志,格式样例如下:

__source__:  log_service
__tag__:__receive_time__:  1559799897
__topic__:  
body_bytes_sent:  740
client_ip:  1.2.3.4
host:  m.abcd.com
http_host:  m.abcd.com
http_referer:  -
http_x_forwarded_for:  -
http_x_real_ip:  -
read_request_time:  0
request_length:  0
request_method:  GET
request_time:  0.000
request_uri:  /category/abc/product_id?id=75&type=2&sam=123
scheme:  https
server_protocol:  HTTP/2.0
slb_vport:  443
slbid:  lb-1234
ssl_cipher:  ECDHE-RSA-AES128-GCM-SHA256
ssl_protocol:  TLSv1.2
status:  200
tcpinfo_rtt:  58775
time:  2019-06-06T13:44:50+08:00
upstream_addr:  1.2.3.4:80
upstream_response_time:  4.1234
upstream_status:  200
vip_addr:  1.2.3.4
write_response_time: 4.1234

目标

这里我们希望对数据进行如下加工,获取三份数据:

分发

  1. 将所有status非2XX或者3XX的请求,复制一份到目标logstore: slb-log-error中,日志时间180天,以便进一步做研发与安全类分析,__topic__设置为slb_error
  2. 将所有不那么重要的图片或静态资源的请求日志,分发到目标logstore: slb-log-media,日志保存30天, topic设置为slb_media_request
  3. 其他的请求日志,用于进一步分析统计业务对接的,分发到目标logstore: slb-log-normal,日志保存90天,topic设置为slb_normal

转换

  1. slb_media_request的请求
  • 提取如下字段
object_file=app.icon
object_type = icon   # css, jpeg, js 等
  • 保留如下字段:
http_referer:  -
body_bytes_sent:  740
client_ip:  1.2.3.4
host:  m.abcd.com
request_time:  4.33
  1. slb_normal请求
  • 保留如下字段
body_bytes_sent:  740
client_ip:  1.2.3.4
host:  m.abcd.com
http_referer:  -
http_x_real_ip:  -
request_length:  0
request_method:  GET
request_time:  4.33
request_uri:  /category/abc/product_id?id=75&type=2&sam=123
scheme:  https
slb_vport:  443
slbid:  lb-1234
status:  200
time:  2019-06-06T13:44:50+08:00
  • 提取request_uri的参数加上前缀reqparam_
reqparam_id: 75
reqparam_type: 2
reqparam_sam: 123
  • http_x_real_ip如果为空或者-时,填上client_ip的值
  • 提取host中的domain值:
domain:  abcd

准备工作

目标logstore准备

  1. 创建好如下3个logstore
slb-log-normal  # 日志保存90天,逻辑命名定为target0
slb-log-error    # 日志保存180天,逻辑命名定为target1
slb-log-media  # 日志保存30天, 逻辑命名定为target2
  1. 并各自配置好索引
    点击每个logstore的【查询】页面的【索引】设置,并根据每个logstore存储的日志的字段,配置相应的索引。也可以使用CloudShell中的CLIcopy_logstore子命令来从源logstore复制一份索引到目标,再进行调整来简化操作。

权限秘钥准备

当前操作需要授权以便读取源logstore或写入目标logstore

  • 通过AK秘钥授权
  • 通过角色授权(二期会支持)

需要准备好一个或多个(每个logstore对应一个)AK秘钥访问:

源logstore的最小RAM授权

{
  "Version": "1",
  "Statement": [
    {
      "Action": [
        "log:ListShards",
        "log:GetCursorOrData",
        "log:GetConsumerGroupCheckPoint",
        "log:UpdateConsumerGroup",
        "log:ConsumerGroupHeartBeat",
        "log:ConsumerGroupUpdateCheckPoint",
        "log:ListConsumerGroup",
        "log:CreateConsumerGroup"
      ],
      "Resource": [
        "acs:log:*:*:project/源project/logstore/slb-log",
    "acs:log:*:*:project/源project/logstore/slb-log/*"
      ],
      "Effect": "Allow"
    }
  ]
}

目标logstore的最小RAM授权

{
  "Statement": [
    {
      "Action": [
        "log:Post*"
      ],
      "Effect": "Allow",
      "Resource": [ "acs:log:*:*:project/目标Project/logstore/slb-log-error", "acs:log:*:*:project/目标Project/logstore/slb-log-media", "acs:log:*:*:project/目标Project/logstore/slb-log-normal"]
    }
  ],
  "Version": "1"
}

也可以考虑将这两个授权合并成一个以便简化操作。

配置加工任务

进入加工规则界面

  1. 在日志服务列表中,选择源logstore(slb-log)的数据接入右边的+号直接进入加工模式.

image

  1. 进入交互的加工界面
    在 #1 中选择日期的时间,例如【今天】,确保能够看到数据:

image

复制失败的请求日志到sbl-log-error

在编辑框中输入如下的规则(关于语法说明,可参考后续的章节):

e_if(e_match("status", r"4\d+|5\d+"), e_coutput("target1", topic="slb_error"))
e_drop()

再点击【预览数据】,会弹窗提示输入访问源logstore的AK秘钥,输入前面准备好的AK秘钥:
image

等待一会儿之后,可以在【数据加工】标签页中看到结果中,所有非2XX/3XX的请求会被输出到target1的目标中,且topic设置为了slb_error
image

提取静态类请求日志并输出到sbl-log-media

在规则编辑框中更新如下规则(关于语法说明,可参考后续的章节):

# e_if(e_match("status", r"4\d+|5\d+"), e_coutput("target1", topic="slb_error"))

e_regex("request_uri", r"([\.\w]+\.\w+)", "object_file")
e_regex("object_file",  r"(\w+)$", "object_type")
e_if(v("object_file"), e_compose(e_keep_fields(F_META, r"object_\w+|request_uri|client_ip|host|request_time"), 
                                                                 e_output(name="target2", topic="slb_media_request")))

e_drop()

再点击【预览数据】,等一会,可以在【数据加工】标签页中看到结果,静态类请求将会被输出到target2的目标中。如前面需求描述,特定的字段被提取,并且还新增了2个字段object_fileobject_type,并且topic设置为了slb_media_request
image

调整字段并输出正常请求日志到sbl-log-normal

在编辑框中更新如下规则(关于语法说明,可参考后续的章节):

# e_if(e_match("status", r"4\d+|5\d+"), e_coutput("target1", topic="slb_error"))

# e_regex("request_uri", r"([\.\w]+\.\w+)", "object_file")
# e_regex("object_file",  r"(\w+)$", "object_type")
# e_if(v("object_file"), e_compose(e_keep_fields(F_META, r"object_\w+|request_uri|client_ip|host|request_time"), 
#                                                                  e_output(name="target2", topic="slb_media_request")))

e_set("__topic__", "slb_normal")
e_kv("request_uri", prefix="reqparam_")
e_if(op_eq(v("http_x_real_ip"), "-"), e_set("http_x_real_ip", v('client_ip')))
e_keep_fields(F_META, r"body_bytes_sent|client_ip|host|http_referer|http_x_real_ip|request_length", 
                                       "request_method|request_time|request_uri|scheme|slb_vport|slbid|status")

再点击【预览数据】,等一会,可以在【数据加工】标签页中看到结果,非媒体类请求将被输出到target0的目标中,如前面需求描述,特定的字段被提取,并且字段http_x_real_ip被设置成了非-的值,且topic设置为了slb_normal
image

保存配置

最终加工规则
在确认规则正确后,去掉注释的部分,就是完整版本:

e_if(e_match("status", r"4\d+|5\d+"), e_coutput("target1", topic="slb_error"))

e_regex("request_uri", r"([\.\w]+\.\w+)", "object_file")
e_regex("object_file",  r"(\w+)$", "object_type")
e_if(v("object_file"), e_compose(e_keep_fields(F_META, r"object_\w+|request_uri|client_ip|host|request_time"), 
                                                                 e_output(name="target2", topic="slb_media_request")))

e_set("__topic__", "slb_normal")
e_kv("request_uri", prefix="reqparam_")
e_if(op_eq(v("http_x_real_ip"), "-"), e_set("http_x_real_ip", v('client_ip')))
e_keep_fields(F_META, r"body_bytes_sent|client_ip|host|http_referer|http_x_real_ip|request_length", 
                                       "request_method|request_time|request_uri|scheme|slb_vport|slbid|status")

配置目标

点击【保存加工配置】,在配置中,依据前面的需求,配置源logstore的秘钥(预览的时候已经配置了),以及3个目标logstore的Project名、logstore名和写入的AK秘钥。注意3个目标的逻辑名称需要与规则中应用的规则保持一致。

image

配置加工范围
在加工范围中,可以根据情况选择【所有】、【某个时间开始】或者特定范围,这里选择【某个时间开始】,并选择此刻。那么保存后,新写入源logstore的数据将会自动应用规则写入到配置的3个目标去。
注意, 这里的时间是日志接收时间

image

加工任务管理与监控

任务管理

点击日志服务项目页面的左侧导航栏中的【数据加工】,可以看到保存的加工任务,可以根据情况选择修改、停止、重启等操作。
image

规则洞察

对于数据加工的任务详情中下方就是任务的执行状态:
image
image

语法详细说明

第一次预览操作

规则

e_if(e_match("status", r"4\d+|5\d+"), e_coutput("target1", topic="slb_error"))
e_drop()

说明

  1. 这里使用条件判断e_if(条件,操作),当条件e_match为真时,执行操作e_coutput
  • 操作e_match("status", r"4\d+|5\d+")检查日志的status字段值是否为4XX或5XX的形式;Python语法中,字符串前面用r修饰,可以避免写两个\的麻烦。
  • 操作:e_coutput('target1', topic="slb_error") 表示复制一份数据并输出到目标target1中,并且将topic设置为slb_error
  1. 函数e_drop()表示丢弃所有剩余的日志;这里是为了预览的效果特意加上,实际保存的配置中不会有这句话。

第二次预览操作

规则

# e_if(e_match("status", r"4\d+|5\d+"), e_coutput("target1", topic="slb_error"))

e_regex("request_uri", r"([\.\w]+\.\w+)", "object_file")
e_regex("object_file",  r"(\w+)$", "object_type")
e_if(v("object_file"), e_compose(e_keep_fields(F_META, r"object_\w+|request_uri|client_ip|host|request_time"), 
                                                                 e_output(name="target2", topic="slb_media_request")))

e_drop()

详细说明

  1. 操作e_regex()表示从字段request_uri中提取了字段object_file,然后进一步从object_file中提取了object_type,如果object_file不存在,字段object_type也不会存在。
  2. e_compose(操作1,操作2)对两个操作进行组合,依次执行。e_if(条件,e_compose(操作1,操作2))表示对于字段object_file不为空的事件,保留特定字段,并且输出到target2,由于这里使用的是e_output而非e_coutput,因此这些事件被输出后不再后续处理。
  3. 规则中的第一行步骤使用Python的语法方式#注释掉了,保留最后一行e_drop()的目的是方便预览。

第三次预览操作

规则

# e_if(e_match("status", r"4\d+|5\d+"), e_coutput("target1", topic="slb_error"))

# e_regex("request_uri", r"([\.\w]+\.\w+)", "object_file")
# e_regex("object_file",  r"(\w+)$", "object_type")
# e_if(v("object_file"), e_compose(e_keep_fields(F_META, r"object_\w+|request_uri|client_ip|host|request_time"), 
#                                                                  e_output(name="target2", topic="slb_media_request")))

e_set("__topic__", "slb_normal")
e_kv("request_uri", prefix="reqparam_")
e_if(op_eq(v("http_x_real_ip"), "-"), e_set("http_x_real_ip", v('client_ip')))
e_keep_fields(F_META, r"body_bytes_sent|client_ip|host|http_referer|http_x_real_ip|request_length", 
                                       "request_method|request_time|request_uri|scheme|slb_vport|slbid|status")

详细说明

  1. 操作e_set()设置默认事件的__topic__
  2. 操作e_kv(),对字段request_uri的值进行KV操作,自动提取其中的键值对并放到事件中。
  3. 进一步的基于表达式函数op_eq设置了字段http_x_real_ip的值。最后e_keep_fields保留特定字段。
  4. 这里没有使用e_output()等,因为默认会将事件输出到第一个配置的目标target0中。

进一步参考

欢迎扫码加入官方钉钉群获得实时更新与阿里云工程师的及时直接的支持:
image

相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
目录
相关文章
|
XML 安全 Java
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板
本文介绍了Java日志框架的基本概念和使用方法,重点讨论了SLF4J、Log4j、Logback和Log4j2之间的关系及其性能对比。SLF4J作为一个日志抽象层,允许开发者使用统一的日志接口,而Log4j、Logback和Log4j2则是具体的日志实现框架。Log4j2在性能上优于Logback,推荐在新项目中使用。文章还详细说明了如何在Spring Boot项目中配置Log4j2和Logback,以及如何使用Lombok简化日志记录。最后,提供了一些日志配置的最佳实践,包括滚动日志、统一日志格式和提高日志性能的方法。
5089 32
【日志框架整合】Slf4j、Log4j、Log4j2、Logback配置模板
|
监控 安全 Apache
什么是Apache日志?为什么Apache日志分析很重要?
Apache是全球广泛使用的Web服务器软件,支持超过30%的活跃网站。它通过接收和处理HTTP请求,与后端服务器通信,返回响应并记录日志,确保网页请求的快速准确处理。Apache日志分为访问日志和错误日志,对提升用户体验、保障安全及优化性能至关重要。EventLog Analyzer等工具可有效管理和分析这些日志,增强Web服务的安全性和可靠性。
636 9
|
监控 容灾 算法
阿里云 SLS 多云日志接入最佳实践:链路、成本与高可用性优化
本文探讨了如何高效、经济且可靠地将海外应用与基础设施日志统一采集至阿里云日志服务(SLS),解决全球化业务扩展中的关键挑战。重点介绍了高性能日志采集Agent(iLogtail/LoongCollector)在海外场景的应用,推荐使用LoongCollector以获得更优的稳定性和网络容错能力。同时分析了多种网络接入方案,包括公网直连、全球加速优化、阿里云内网及专线/CEN/VPN接入等,并提供了成本优化策略和多目标发送配置指导,帮助企业构建稳定、低成本、高可用的全球日志系统。
1367 55
|
存储 运维 监控
超越传统模型:从零开始构建高效的日志分析平台——基于Elasticsearch的实战指南
【10月更文挑战第8天】随着互联网应用和微服务架构的普及,系统产生的日志数据量日益增长。有效地收集、存储、检索和分析这些日志对于监控系统健康状态、快速定位问题以及优化性能至关重要。Elasticsearch 作为一种分布式的搜索和分析引擎,以其强大的全文检索能力和实时数据分析能力成为日志处理的理想选择。
1271 6
|
12月前
|
运维 安全 数据可视化
日志审查安排工具实战攻略:中小团队如何通过日志审查安排工具建立可控、安全的审查机制?
在审计敏感时代,日志审查安排工具成为安全运维与合规管理的关键利器。它实现审查任务的流程化、周期化与可视化,支持多系统协作、责任到人,确保“可控、可查、可追”的日志治理。工具如板栗看板、Asana、Monday 等提供任务调度、问题闭环与合规对接能力,助力企业构建高效、透明的日志审查体系,提升安全与合规水平。
|
存储 缓存 关系型数据库
图解MySQL【日志】——Redo Log
Redo Log(重做日志)是数据库中用于记录数据页修改的物理日志,确保事务的持久性和一致性。其主要作用包括崩溃恢复、提高性能和保证事务一致性。Redo Log 通过先写日志的方式,在内存中缓存修改操作,并在适当时候刷入磁盘,减少随机写入带来的性能损耗。WAL(Write-Ahead Logging)技术的核心思想是先将修改操作记录到日志文件中,再择机写入磁盘,从而实现高效且安全的数据持久化。Redo Log 的持久化过程涉及 Redo Log Buffer 和不同刷盘时机的控制参数(如 `innodb_flush_log_at_trx_commit`),以平衡性能与数据安全性。
958 5
图解MySQL【日志】——Redo Log
|
人工智能 运维 监控
Aipy实战:分析apache2日志中的网站攻击痕迹
Apache2日志系统灵活且信息全面,但安全分析、实时分析和合规性审计存在较高技术门槛。为降低难度,可借助AI工具如aipy高效分析日志,快速发现攻击痕迹并提供反制措施。通过结合AI与学习技术知识,新手运维人员能更轻松掌握复杂日志分析任务,提升工作效率与技能水平。
|
缓存 Java 编译器

相关产品

  • 日志服务