日志服务汇总数据指南

本文涉及的产品
对象存储 OSS,20GB 3个月
日志服务 SLS,月写入数据量 50GB 1个月
对象存储 OSS,内容安全 1000次 1年
简介: 本文为您介绍基于SLS推出的ScheduledSQL功能,对历史数据进行汇总压缩,降低使用存储成本。

本文为您介绍基于SLS推出的ScheduledSQL功能,对历史数据进行汇总压缩,降低使用存储成本。

背景

日志服务 SLS通过丰富灵活的方式将多种类型(日志、指标)的数据接入到服务中,并随着时间不断沉淀;之后,用户就可以通过SLS强大的查询分析能力对多个维度的数据进行搜索、分析。虽然历史数据同样有较高的查询分析价值,但是大量历史数据的存储成本也不能忽视。因而SLS的用户一般会给数据设置一个固定的保留日期,定期清理历史数据,减轻成本压力。为了解决这一问题,SLS近期推出了新功能ScheduledSQL,让用户定时保存SLS中的汇总数据,既保存了历史数据供以后查询分析,同时又减轻了存储的成本压力。

汇总数据

日志、指标类的数据都会随着时间的推移不断累积。例如一个系统每秒产生1000条日志,日志的平均大小为500byte,一小时就会有1.8GB的日志,一年就会产生15T的数据。虽然数据使用方希望能够尽可能多的保存这15T数据以供查询分析使用,但是这些历史数据在提供分析价值的同时,也造成了较高的成本压力。定期删除历史数据虽然能够解决成本问题,但同时也给数据使用方带来了不便。

数据价值的时间梯度

从使用频率、数据权重等维度不难看出,数据的价值是随着时间不断降低的。例如用户页面查看日志,需要查看最近七天单个用户每天的特定页面的访问数,最近一月单个用户每天的访问数,最近一年单个用户每月的访问数。假设有2万用户,20可供用户访问的页面:

数据维度

时间梯度

保存时长

汇总数据量(条)

原始数据量(条)

汇总占比

user/page

7天

2万 * 20 * 7 = 280万

2万 * 20 * 7 = 280万

100%

user

30天

2万 * 30 = 60万

2万 * 20 * 30 = 1200万

5%

user

1年

2万* 12 = 24万

2万 * 20 * 365 = 1.4亿

0.16%

可以看到在上述场景下,随着时间推移,数据具有极高的可压缩比率。相对于直接删除历史数据,可以通过保存汇总数据来降低存储成本。这样即能够查询分析历史数据,又不必花费极高的存储成本。

汇总数据结构

在生成汇总数据的时候,首先需要评估数据的使用场景。不同场景、不同类型的数据的使用方式千差万别,其评估方式也不尽相同。下面介绍下不同类型数据的评估方式。

数值型数据

指标数据是典型的数值型数据,一条典型的指标日志如下所示:

{
    "bucket_location": "oss-cn-*****-h",
    "bucket": "buc*****65",
    "object": "245-***************.model",
    "operation": "PostObject",
    "time": "23/Jun/2021:10:23:50",
    "object_size": "3188",
    "__time__": 1624443830,
    "key": "data-***************.txt",
    "content_length_out": "22583527",
    "content_length_in": "46803694",
    "http_status": "200",
    "response_time": "7339",
    "__tag__:__receive_time__": "1624443838"
}

这条日志的字段可以分为时间,数值字段,分组字段三类,例如:

字段名称

字段值

类型

bucket

buc*****65

分组

object

245-***************.model

分组

operation

PostObject

分组

object_size

3188

数值

content_length_in

46803694

数值

content_length_out

22583527

数值

__time__

1624443830

时间

__tag__:__receive_time__

1624443838

时间

数值字段即为具体的指标值,维度和时间字段一般用作分组值,在计算指标的聚合值时作为分组依据。例如,如果要计算OSS每个bucket每小时写入的数据量,则需要使用维度字段operation和bucket,时间字段__time__,数值字段content_length_out:

operation: PostObject | select bucket, date_trunc("hour", __time__) as tm, sum(content_length_in) as total from log group by bucket, tm

如果使汇总数据支持上述场景,需要在汇总数据中保存分组字段operation和bucket,精确到小时级别的__time__字段,以及content_length_in的聚合值。所以可以通过如下sql语句计算汇总数据,支持上述场景:

operation: PostObject | select bucket, operation, date_trunc("hour", __time__) as tm, sum(content_length_in) as size from log group by bucket, operation, tm

如果还需要汇总数据同时支持计算每小时单次写入数据量的平均值,则需要通过如下sql语句计算汇总数据:

operation: PostObject | select bucket, operation, date_trunc("hour", __time__) as tm, avg(content_length_in) as avg, count(1) as size from log group by bucket, operation, tm

得到如下所示的汇总数据:

字段名称

字段样例

字段说明

bucket

buc*****65

bucket名称

operation

PostObject

操作名称

tm

1624442400

取整到小时的时间戳

avg

22583527

单次写入数据大小的平均值

size

65

写入数据请求的次数

基于得到的汇总数据,可以通过如下sql语句进行计算

  1. 计算OSS每个bucket每小时写入的数据量

operation: PostObject | select bucket, tm, sum(avg * size) as total from log
  1. 每小时单次写入数据量的平均值

operation: PostObject | select bucket, tm, avg from log

可以看出,随着场景的不同,计算汇总数据所需的sql语句也不尽相同。可以从以下几个方面评估如何计算汇总数据:

  1. 选择分组字段。

  2. 选择数值字段的聚合值:计数、求和、平均、最大、最小。

  3. 选择时间粒度:分钟、小时、天。

采样历史数据

采样历史数据则较为简单,在历史数据中按照一定的规则挑选合适的数据存储即可。例如对于系统日志,可以选择存储日志级别为WARNING或者ERROR的数据进行存储,忽略INFO级别的日志。

汇总数据的限制

汇总数据本质上是对原始数据在更粗时间粒度的聚合,并且聚合分组、计算都是按照对汇总数据的预期使用方式来选择的。

  1. 时间粒度

如果汇总数据的时间粒度是小时,则使用汇总数据进行数据分析只能够得到以小时为单位的聚合结果,无法得到更细粒度的数据。

  1. 聚合函数

聚合函数只能够使用汇总数据中聚合值支持的。如果汇总结果中不包含最小值,则基于汇总结果进行聚合计算的时候,是无法精确得到最小值的。

  1. 分组数据

由于汇总数据只保存了部分分组数据,在使用汇总数据进行数据分析时只能够使用保存的部分。

日志服务中的汇总数据

下面以OSS访问日志为例,说明如何基于SLS推出的ScheduledSQL功能,对历史数据进行汇总压缩,从而降低使用存储成本。

评估使用场景

一条完整的OSS访问日志如下:

{
    "__topic__": "oss_access_log",
    "bucket_location": "oss-cn-****-p",
    "bucket": "bucket****",
    "object": "245-************.model",
    "client_ip": "127.0.0.1",
    "operation": "PutObject",
    "logging_flag": "false",
    "time": "23/Jun/2021:13:07:30",
    "server_cost_time": "8636",
    "object_size": "7748",
    "vpc_addr": "127.0.0.1",
    "sync_request": "cdn",
    "__time__": 1624453650,
    "key": "data*****6958txt",
    "delta_data_size": "3938",
    "__source__": "127.0.0.1",
    "error_code": "network disconnected",
    "content_length_out": "79193322",
    "response_body_length": "717233083",
    "request_uri": "/request/path-2/file-9",
    "content_length_in": "1823770",
    "http_method": "GET",
    "http_status": "200",
    "request_length": "4099",
    "response_time": "398",
    "__tag__:__receive_time__": "1624453651",
    "owner_id": "ln***v2",
    "http_type": "https",
    "bucket_storage_type": "archive"
}

需要基于OSS访问数据构建如下的几类关键结果:

名称

时间粒度

分组依据

聚合函数

单位时间请求次数

小时

bucket, operation

count

单位时间请求错误

小时

bucket, operation, http_status

count

单位时间写入数据量

小时

bucket, operation

sum

单位时间平均写入数据量

小时

bucket, operation

avg, count

单位时间读取数据量

小时

bucket, operation

sum

单位时间平均读取数据量

小时

bucket, operation

avg, count

根据上面的使用场景,可以通过如下语句计算汇总数据:

operation: PostObject | select bucket, operation, http_status, date_trunc('hour', __time__) as tm, avg(content_length_out) as out_avg, avg(content_length_in) as in_avg, count(1) as size from log group by bucket, operation, http_status, tm

创建ScheduledSQL任务

执行查询语句

在SLS的控制台中执行上述查询语句,随后点击创建ScheduledSQL。

计算配置

此处填入合适的作业名称、以及目标库即可。此处需要注意开启目标库的索引。

调度配置

这里调度间隔和时间窗口都选择小时级别,点击确认即可。关于调度配置的详细信息,可以参考官方文档

在任务执行成功之后,就可以在目标库中看到汇总数据。

汇总数据的使用

基于ScheduledSQL任务生成的汇总数据,可以为上述场景提供支撑。

名称

查询语句

单位时间请求次数

*| select bucket, tm, sum(1) as total group by bucket, tm

单位时间请求错误

not http_status: 200 | select bucket, count(1) as cnt group by bucket

单位时间写入数据量

operation: PostObject | select bucket, tm, sum(avg_out * size) as total from log

单位时间平均写入数据量

operation: PostObject | select bucket, tm, sum(avg_out * size) as total from log

单位时间读取数据量

operation: GetObject | select bucket, tm, sum(avg_in * size) as total from log

单位时间平均读取数据量

operation: GetObject | select bucket, tm, sum(avg_in * size) as total from log

总结

通过汇总数据支撑历史数据分析,能够较大的减轻存储成本上的压力。虽然同原始数据相比,其在使用场景以及灵活性方面都有所欠缺,但是如果能够提前做好规划,就能够很好的支撑大部分的使用场景。

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
10天前
|
存储 Oracle 关系型数据库
【赵渝强老师】MySQL InnoDB的数据文件与重做日志文件
本文介绍了MySQL InnoDB存储引擎中的数据文件和重做日志文件。数据文件包括`.ibd`和`ibdata`文件,用于存放InnoDB数据和索引。重做日志文件(redo log)确保数据的可靠性和事务的持久性,其大小和路径可由相关参数配置。文章还提供了视频讲解和示例代码。
118 11
【赵渝强老师】MySQL InnoDB的数据文件与重做日志文件
|
10天前
|
SQL Oracle 关系型数据库
【赵渝强老师】Oracle的联机重做日志文件与数据写入过程
在Oracle数据库中,联机重做日志文件记录了数据库的变化,用于实例恢复。每个数据库有多组联机重做日志,每组建议至少有两个成员。通过SQL语句可查看日志文件信息。视频讲解和示意图进一步解释了这一过程。
|
4月前
|
SQL 运维 监控
SLS 数据加工全面升级,集成 SPL 语法
在系统开发、运维过程中,日志是最重要的信息之一,其最大的优点是简单直接。SLS 数据加工功能旨在解决非结构化的日志数据处理,当前全面升级,集成 SPL 语言、更强的数据处理性能、更优的使用成本。
18178 142
|
1月前
|
数据采集 机器学习/深度学习 存储
使用 Python 清洗日志数据
使用 Python 清洗日志数据
35 2
|
3月前
|
存储 消息中间件 人工智能
AI大模型独角兽 MiniMax 基于阿里云数据库 SelectDB 版内核 Apache Doris 升级日志系统,PB 数据秒级查询响应
早期 MiniMax 基于 Grafana Loki 构建了日志系统,在资源消耗、写入性能及系统稳定性上都面临巨大的挑战。为此 MiniMax 开始寻找全新的日志系统方案,并基于阿里云数据库 SelectDB 版内核 Apache Doris 升级了日志系统,新系统已接入 MiniMax 内部所有业务线日志数据,数据规模为 PB 级, 整体可用性达到 99.9% 以上,10 亿级日志数据的检索速度可实现秒级响应。
AI大模型独角兽 MiniMax 基于阿里云数据库 SelectDB 版内核 Apache Doris 升级日志系统,PB 数据秒级查询响应
|
3月前
|
缓存 NoSQL Linux
【Azure Redis 缓存】Windows和Linux系统本地安装Redis, 加载dump.rdb中数据以及通过AOF日志文件追加数据
【Azure Redis 缓存】Windows和Linux系统本地安装Redis, 加载dump.rdb中数据以及通过AOF日志文件追加数据
129 1
【Azure Redis 缓存】Windows和Linux系统本地安装Redis, 加载dump.rdb中数据以及通过AOF日志文件追加数据
|
2月前
|
SQL 人工智能 运维
在阿里云日志服务轻松落地您的AI模型服务——让您的数据更容易产生洞见和实现价值
您有大量的数据,数据的存储和管理消耗您大量的成本,您知道这些数据隐藏着巨大的价值,但是您总觉得还没有把数据的价值变现出来,对吗?来吧,我们用一系列的案例帮您轻松落地AI模型服务,实现数据价值的变现......
195 3
|
3月前
|
存储 监控 网络协议
在Linux中,如何使用 tcpdump 监听主机为 192.168.1.1,tcp 端⼝为 80 的数据,并将将输出结果保存输出到tcpdump.log?
在Linux中,如何使用 tcpdump 监听主机为 192.168.1.1,tcp 端⼝为 80 的数据,并将将输出结果保存输出到tcpdump.log?
|
3月前
|
数据库 Java 监控
Struts 2 日志管理化身神秘魔法师,洞察应用运行乾坤,演绎奇幻篇章!
【8月更文挑战第31天】在软件开发中,了解应用运行状况至关重要。日志管理作为 Struts 2 应用的关键组件,记录着每个动作和决策,如同监控摄像头,帮助我们迅速定位问题、分析性能和使用情况,为优化提供依据。Struts 2 支持多种日志框架(如 Log4j、Logback),便于配置日志级别、格式和输出位置。通过在 Action 类中添加日志记录,我们能在开发过程中获取详细信息,及时发现并解决问题。合理配置日志不仅有助于调试,还能分析用户行为,提升应用性能和稳定性。
57 0
|
3月前
|
开发者 前端开发 编解码
Vaadin解锁移动适配新境界:一招制胜,让你的应用征服所有屏幕!
【8月更文挑战第31天】在移动互联网时代,跨平台应用开发备受青睐。作为一款基于Java的Web应用框架,Vaadin凭借其组件化设计和强大的服务器端渲染能力,助力开发者轻松构建多设备适应的Web应用。本文探讨Vaadin与移动设备的适配策略,包括响应式布局、CSS媒体查询、TouchKit插件及服务器端优化,帮助开发者打造美观且实用的移动端体验。通过这些工具和策略的应用,可有效应对屏幕尺寸、分辨率及操作系统的多样性挑战,满足广大移动用户的使用需求。
66 0