文档

稳定性说明与使用限制

更新时间:

本文介绍OSS投递(新版)的稳定性与使用限制。

稳定性说明

读日志服务

稳定项

说明

可用性

可用性较高。

如果日志服务出错,无法读取数据,OSS投递任务会在内部至少重试10次。如果仍然失败,任务执行会报错,然后任务重启。

写OSS

稳定项

说明

并发度

按照日志服务Shard进行分区并创建投递实例,支持快速扩容。

如果日志服务源Logstore进行Shard分裂,可以在数秒以内完成投递实例的扩容,加快数据导出速度。

数据不丢失

OSS投递任务基于消费组进行扩展,提供一致性保证。投递完成后,才会提交offset,因此可以保证数据写入OSS之前,offset不被提交,即保证投递数据不丢失。

监控告警

稳定项

说明

监控告警

数据投递有完善的监控,可实时追踪投递任务的延迟、流量等指标。您可以根据业务需求,配置自定义告警,及时发现投递问题(例如导出实例不足、网络Quota限制等)。具体操作,请参见为OSS投递任务(新版)设置告警

使用限制

网络

限制项

说明

网络类型

通过阿里云内网传输数据,网络稳定性和速度具有保障。

权限管理

限制项

说明

授权

涉及OSS投递操作权限和数据访问权限。更多信息,请参见准备权限

服务端加密

如果开启了服务端加密,需要为RAM角色添加额外的权限。更多信息,请参见OSS配置文档

读流量

限制项

说明

读流量

单个Project以及单个Shard存在最高流量限制。更多信息,请参见数据读写

如果超过最高流量限制,请分裂Shard或者申请扩容Project读流量限制。超过限制,会导致OSS投递任务读取数据失败,并在内部至少重试10次,如果仍然失败,任务执行会报错,然后任务重启。

写OSS

限制项

说明

并发实例

并发实例数量与Shard数量相同(包括读写Shard和只读Shard)。

投递限制

  • 通过每个Shard的投递大小控制OSS Object大小(以未压缩计算),取值范围为5~256 MB。

  • 每个Shard的投递周期取值范围为300~900秒。

  • 每个并发实例的每次投递,都会产生一个单独的OSS文件。

    重要

    创建OSS投递任务后,每个Shard都会根据投递大小、投递时间决定投递的频率,当任一条件满足时,即会执行一次投递。

时间分区

OSS投递是攒批进行,每次写一个文件,文件内包括一批数据,文件路径由该批数据中最小的receive_time(数据到达日志服务的时间)决定。

文件格式

数据被投递到OSS后,支持存储为CSV、JSON、Parquet、ORC四种文件格式。更多信息,请参见JSON格式CSV格式Parquet格式ORC格式

压缩方式

支持snappy、gzip、zstd三种压缩方式以及不压缩。

OSS Bucket

  • 控制台界面原则上只支持投递给已存在且未开启WORM的Bucket,且该Bucket与日志服务Project位于相同地域。关于WORM的更多信息,请参见保留策略

    说明

    OSS投递功能为了保证Exactly-once,在少数情况下(如网络抖动等)会修改Bucket中已存在的文件,如果Bucket开启了WORM策略,为了保证投递功能正常执行不被阻塞,会尝试将数据写入新命名后的文件,尝试次数为5次,新命名的文件规则为:“{原文件名}.worm.{重试次数}”。例如,原文件名为test.file,重试时写入的文件名则为test.file.worm.1test.file.worm.2等。

  • 支持投递到标准、低访问、归档、冷归档四种存储类型的Bucket中。投递后,生成的OSS Object的存储类型默认与Bucket一致。更多信息,请参见存储类型介绍

  • 非标准存储的Bucket存在最低存储时间和最小计量单位限制,请根据需求合理设置目标Bucket存储类型。更多信息,请参见存储类型对比

配置项

限制项

说明

延迟投递

延迟投递配置项中设置的时间不能超过目标Logstore的数据保存时间。

建议预留一段缓冲时间,否则可能会导致数据丢失。例如Logstore的数据保存时间为30天,则延迟投递的时间最好不要超过25天。

管理投递

限制项

说明

暂停投递任务

投递任务会记录上次投递的日志Cursor,恢复运行时从记录的Cursor开始继续投递。因此暂停投递任务时存在如下机制。

  • 暂停任务一段时间且没有超过数据的保存时间,则再运行任务时,系统从上次暂停的位置继续开始投递,不会丢失数据。

  • 暂停任务一段时间但超过了数据的保存时间,则再运行任务时,系统从离上次暂停位置最近的一条数据开始投递。