阿里云存储的降本增效与运维

小浩负责公司存储架构层，需要确保存储层不会成为公司业务系统的性能瓶颈，让数据读写达到最佳性能。那么小浩可以从哪些方面着手优化性能呢？他继续求助系统架构师大雷。

小浩：雷哥，PD反馈公司系统最近响应很慢，需要排除客户端、流量负载层、服务端、存储层各个模块哪里出现了瓶颈，我要负责存储层的性能问题排查和性能优化，您有什么建议吗？

大雷：那你首先需要和PD对齐性能的要求，从对象存储OSS的角度来看，我们可以从以下维度来分析：

性能优化简介

对存储进行性能优化，有利于降低系统的不可服务时间，提高效率并改善用户体验。小浩结合大雷建议首先确定了应用系统的基准性能要求，系统在创建Bucket时已经考虑了区域因素（资源创建在更靠近业务的位置以减少延迟，比如部署应用的ECS在杭州地域，建议在同一地域创建Bucket），之后就开始研究优化性能的方法......

小浩反复琢磨架构师大雷给出的几个建议：

（1）系统规划阶段：应合理规划对象文件（object）的前缀；

（2）系统开发阶段（使用阿里云OSS SDK）：业务通过并行请求实现高吞吐量、通过超时和重试机制可以在连接失败时恢复；

（3）业务发展中（系统初期规划时未考虑到）可能需要系统改造：使用CDN缓存频繁访问的静态数据、利用传输加速应用到远距离文件的上传、下载；

小浩按照自己的理解对大雷的建议进行梳理之后，开始对以上优化手段进行研究。

使用前缀

小浩在开始研究前缀之前，对OSS Object的命名模式进行回顾学习：

对象存储命名模式

说明：dir1为示范，在实际业务生产过程中，可根据实际情况设置适当的前缀，比如设备类型、公司名等

为什么合理使用前缀能可以优化性能

在了解前缀时，小浩了解到分区，那什么是分区呢？分区的作用是什么呢？

分区是对象存储OSS中的一个逻辑的概念，内部用来建立object key索引的信息，每个object key的索引都会在某一个分区内。随着业务的发展，吞吐量的增长，OSS会按照文件名UTF-8编码的顺序对用户数据进行自动分区，基于Range Partition方式管理，OSS将海量对象的索引信息根据负载分布到不同的Range Partition，不同的Range Partition会分配给各个分区服务器来进行管理，并提供超大规模的并发请求、自动负载均衡。

下图说明：p1-p4代表分区，dir1/ob1.txt等为示例代表对象键索引信息，不同对象键的索引信息会分布到不同的机器上，提供大规模的并发请求

了解完分区的概念，小浩理解得还是很模糊，设想如果没有合理设置前缀，会产生什么结果呢？

不合理使用前缀，比如如果在命名上使用顺序前缀（时间戳等），可能会出现大量文件索引集中存储于存储空间（Bucket）中的某个特定分区的情况，这样就会造成：

该分区成为热点分区，导致分区的I/O能力被耗尽，或超过系统速率限制系统自动限制请求速率。
热点分区的存在会触发系统进行持续的分区数据再均衡，这个过程可能会延长请求处理时间

这样就导致所有的请求压力落在了单分区上，此时整个集群的性能就是单台机器的性能，未能充分利用OSS分布式的性能，那应该怎么办呢？

合理使用前缀解决方案

示例：如果在存储数据时使用日期与客户ID生成文件名，路径会包含顺序时间戳前缀，此时就可能会造成分区热点。

demo-share/2023-06-06/customer-1/file1
demo-share/2023-06-06/customer-2/file1
demo-share/2023-06-06/customer-3/file1
......
demo-share/2023-06-07/customer-1/file1
demo-share/2023-06-07/customer-2/file1
demo-share/2023-06-07/customer-3/file1

针对这种情况，需要避免object key出现按顺序索引的情况，我们可以对客户ID计算哈希、文件名反转等方式避免出现顺序前缀，此处可以对客户ID计算哈希（即MD5），并取若干字符的哈希前缀作为文件名的前缀。假如取4个字符的哈希前缀，这样就可以把之前以日期的顺序前缀转变为随机前缀，结果如下：

demo-share/8b11/2023-06-06/customer-1/file1
demo-share/s5c2/2023-06-06/customer-2/file1
demo-share/d2b3/2023-06-06/customer-3/file1
......
demo-share/9fc2/2023-06-07/customer-1/file1
demo-share/afv1/2023-06-07/customer-2/file1
demo-share/de4b/2023-06-07/customer-3/file1

到此小浩已掌握了存储数据时合理设计前缀及其原理，此时小浩思考既然OSS是分布式系统，数据会落在不同的分区上，那提高并发是不是也能实现高吞吐量以提升性能呢？

并行请求

学习完上个课时中分区的概念，小浩明白了OSS可以利用其规模，将并行请求水平扩展到OSS服务终端节点，这种扩展方式有助于通过网络将负载分布在多个路径上（多个分区上），充分利用其分布式系统性能，从而获得更高的速度和可靠性。

调整并发的请求数时，性能测量非常重要。建议从单个请求开始，测量当前的网络带宽以及其他资源的使用情况，从而识别瓶颈资源（即使用率最高的资源），以及可能的并发请求数。比如，如果一次处理一个请求导致CPU使用率为10%，则表明最多可以支持10个并发请求。

同时，OSS还提供了分片上传向OSS实现并行写入，分片上传将待上传的文件分成多个碎片（Part）分别上传，上传完成之后再调用接口将这些Part组合成一个Object。

分片上传场景

大文件加速

当文件大小超过5 GB时，使用分片上传可实现并行上传多个Part以加快上传速度。

网络环境较差

网络环境较差时，建议使用分片上传。当出现上传失败的时候，您仅需重传失败的Part。

文件大小不确定

可以在需要上传的文件大小还不确定的情况下开始上传，这种场景在视频监控等行业应用中比较常见。

分片上传优势

并行上传part提高吞吐量
上传失败时，只需要重传失败的part
可调用接口进行终止、恢复上传

更多详情可参考分片上传

超时退避重试

在研究退避重试之前，小浩思考什么情况下需要重试呢？重试解决了什么问题？

对象存储OSS等大型分布式系统中，出现故障或超过产品限制的quota（账号级QPS：10,000/s）等问题是不可避免的，这时可能会收到HTTP 503响应，当然也可能会收到少量的其他 HTTP 5XX系列错误响应，这时建议延迟几秒进行重试。

为什么超时退避重试可以优化性能

超时可防止应用程序不合理地长时间等待，重试可帮助在发生故障时进行恢复，而退避可以提高利用率并减少系统堵塞问题。

超时：

超时时间是指客户端将会等待请求完成的最长时间。

当应用程序等待一项请求完成的时间超过正常水平时，它持有该请求资源（例如内存或连接）的时间也会相应延长。设置超时时间可以减轻这种问题。

重试：

重试可让客户端在连接失败/请求失败后重新发送相同的请求，从而恢复连接。可以通过阿里云对象存储OSS提供的默认重试机制或自定义重试策略在应用程序中构建重试逻辑。

退避：

当过载导致连接失败/请求失败时，频繁发出重试也会增加负载，从而加剧过载问题。可能导致高负载问题在原始问题解决后仍然长时间存在，延误恢复。

退避可以避免这种问题，例如您在2秒重试后，然后等4秒后再次重试等。

通过对象存储OSS SDK实时重试

对象存储OSS提供了可配置重试次数、自定义重试策略、超时时间的ClientBuilderConfiguration，以下为JAVA SDK如何配置超时时间，重试次数、自定义重试策略的示例。

小浩到这里已经掌握了超时退避重试的原理，学会了通过阿里云OSS提供的JAVA SDK进行操作配置，但是如何根据业务情况配置合适的超时时间和重试次数呢，有没有一些原则进行指导呢？

超时和重试的原则

要确定应用程序设置合理的重试次数和和超时时间，需要考虑以下问题：

当网络连接变差或无法访问 OSS服务时，OSS SDK和应用程序应该如何响应？希望请求快速失败还是适当继续重试？
应用程序属于要求低时延的程序还是可容忍较大延迟的后台处理？
应用程序是部署在低延迟的可靠网络上，还是部署在连接不可靠的远程位置？

示例：

当您发出大量不同大小的请求时（例如超过128 MB），建议您测量吞吐量，并重试最慢的5%请求。当您发出较小的请求时（例如小于512 KB），时延通常在数十毫秒以内。建议您在2秒后重试GET或PUT操作。如果需要额外的重试，最好的做法是退出。例如，建议您在2秒后重试，然后等4秒后再次重试。

如果您的应用程序向OSS发出固定大小的请求，您期望每个请求的响应时间趋于一致。在这种情况下，推荐的策略是识别最慢的1%请求并重试。通常情况下，即使一次重试也能有效减少时延。

使用CDN缓存优化

小浩发现前面几种优化手段更多的是从业务/应用程序着手，充分利用OSS的分布式系统的性能及SDK提供的能力来进行优化，刚好小浩公司的应用程序有大量的静态资源供用户访问，结合大雷给的建议，小浩开始研究使用阿里云CDN缓存来优化性能。

那什么是CDN呢？CDN可以解决什么问题？

阿里云CDN是建立并覆盖在承载网上，由不同区域的服务器组成的分布式网络。CDN将源站资源缓存到全国各地的边缘服务器，供用户就近获取，降低源站压力。采用缓存可带来低时延和高传输速率。使用缓存的应用程序向OSS发送的直接请求更少，请求成本也更低。

了解完其原理，小浩结合公司的网站架构，设计了增加CDN缓存的网站架构：

云上网站架构（使用CDN）

该架构实现了动态和静态资源的分离，将OSS作为CDN的源站，通过CDN加速分发，使用户通过CDN节点就近获得数据，解决海量用户访问的性能瓶颈。

CDN使用操作

使用前提：

已开通阿里云CDN服务
已注册有域名

操作步骤详情参考CDN加速OSS访问

使用OSS传输加速

OSS传输加速是利用全球分布的云机房，将全球各地用户对您存储空间的访问，经过智能路由解析至就近的接入点，使用优化后的网络及协议，为云存储在互联网上的上传下载提供端到端的加速方案。

使用场景

远距离数据传输加速

全球性的论坛、Top在线协同办公平台等，部分客户会因传输距离较远导致上传和下载体验非常差。传输加速功能可以让全球各地的客户使用优化后的网络来传输数据，极大地提升上传和下载速度，让不同地域的用户都能有很好的访问体验；

2、大文件上传、下载

通过互联网远距离上传和下载大文件时，经常会因为网络延迟过大而导致传输失败。传输加速功能使用优化的互联网传输链路、调优的协议栈与传输算法，可大幅减少远距离互联网传输超时的比例。同时还可以让传输加速功能与分片上传、断点续传下载结合，形成远距离大文件上传和下载的解决方案。

3、非静态、非热点数据下载加速

游戏、电商、社交应用的评论内容、企业门户网站、金融类APP等，用户的下载体验直接影响产品竞争力和客户留存率。传输加速功能作为专为OSS上传、下载加速而设计的功能，可以最大限度利用客户端的网络能力，提升用户的下载体验。

OSS传输加速配置

步骤：

登录OSS管理控制台。
单击Bucket 列表，然后单击目标Bucket名称。
在左侧导航栏，选择Bucket配置 > 传输加速。
在传输加速页面，打开传输加速开关，然后在弹出的对话框单击确定。

通过浏览器使用传输加速

通过浏览器访问OSS时，将文件路径的Endpoint字段需替换为传输加速Endpoint：

例如https://test.oss-cn-hangzhou.aliyuncs.com/myphoto.jpg 需改为https://test.oss-accelerate.aliyuncs.com/myphoto.jpg。如果文件访问权限为私有，则还需要加上签名信息。

传输加速访问域名如下图：

测试传输加速效果

阿里云对象存储OSS提供了在线测试工具，测试结果如下图：

至此小浩已掌握了多种性能优化手段，小浩休息片刻，回忆了整个的研究学习内容，发现使用CDN缓存优化和使用传输加速还是会出现一些混乱，小浩决定整理下两者的区别：

CDN加速和OSS传输加速的区别

实现原理

CDN加速：是建立并覆盖在承载网之上，由遍布全球的边缘节点服务器群组成的分布式网络。阿里云CDN能分担源站压力，避免网络拥塞，确保在不同区域、不同场景下加速网站内容的分发，提高资源访问速度。由CDN全球广泛分布的边缘节点缓存OSS存储的静态数据，从而实现客户端从边缘节点直接获取数据的方式来实现访问的加速。

OSS传输加速：利用全球分布的云机房，将全球各地用户对您存储空间（Bucket）的访问，经过智能路由解析至就近的接入点，使用优化后的网络及协议，为云存储互联网的上传、下载提供端到端的加速方案。

资源加速场景介绍

OSS传输加速是针对OSS的链路加速，使用OSS传输加速后支持OSS提供的任意特性。CDN通过全球边缘节点缓存OSS资源，加速同时可降低带宽成本。OSS传输加速和CDN加速完全是两个不同的产品，且应对的场景不同，详情请参见CDN应用场景和传输加速场景。

如果您的业务是第三方数据源加速，推荐您使用CDN加速。
如果您的OSS资源需要进行多次下载的操作，并且不要求数据强一致性，推荐您使用CDN加速。
如果您的OSS资源需要加速下载，并且访问量少，推荐您使用OSS传输加速。
如果您的OSS资源需要进行多次下载的操作，并且要求数据强一致性，推荐您使用OSS传输加速。
如果您的业务存储的是动态资源，且数据更新频繁，推荐您使用OSS传输加速。
如果您的业务存储的是静态资源，且更新少，推荐您使用CDN加速。

梳理完成之后，小浩瞬间对其原理和使用场景清晰了很多，接下来小浩准备继续学习对象存储运维保障相关的内容......

思考：如何监控存储的运行状态

小浩作为存储层负责人，随着对OSS的不断深入，为了保障业务更平稳地运行，小浩思考到：

是否可以主动监控对象存储OSS的运行状态；
当有人操作存储的文件时是否可以及时触发事件通知；
能否把对资源的操作都能记录下来，以满足一些合规需求。

带着上述问题，小浩继续找系统架构师大雷请教。

小浩：雷哥，我想监控对象存储OSS的运行状态，我应该从哪里入手呢？

大雷：首先你需要明确需要哪些监控指标，确定这些指标后是否还需要有一些聚合的监控图展示，以及这些可以帮助你解决什么业务问题。

小浩：我可以根据业务出现问题的时间段，查看这个时间段存储的监控初步判断存储服务是否正常，后续还可以基于此为依据进行问题的诊断。

大雷：是的，出现问题之前，你是否也希望它能给你提供一些告警？顺着这个脉络你可以去深入研究一下OSS的监控指标，并熟练地掌握使用它。

小浩：明白了，雷哥，我这就开始去研究，有问题再向您请教。

监控指标及功能

小浩查看OSS文档发现：

OSS监控服务提供系统基本运行状态、性能以及计量等方面的监控数据指标，并且提供自定义报警服务，帮助用户跟踪请求、分析使用情况、统计业务趋势，及时发现以及诊断系统的相关问题。

同时OSS提供的监控指标主要分为基础服务指标、性能指标和计量指标，从用户使用角度来看，OSS的指标分为用户层级和存储空间（Bucket）层级，小浩对这些指标进行总结梳理：

经过对监控指标的梳理，小浩逐渐理解了OSS监控指标的作用，通过对这些指标的监控为后续问题的诊断和故障的排查提供有力的数据支撑，接下来小浩准备尝试使用OSS监控服务和告警服务。

监控服务使用操作

用户层级监控

步骤：

登录云监控控制台。
在左侧导航栏，单击云产品监控。
筛选并进入对象存储OSS监控页面，如下图。

4、单击用户概况页签，查询用户监控详情，如下图。

5、在用户概况页下，切换到“请求状态详情”，如下图。

Bucket监控

步骤：

登录云监控控制台。
在左侧导航栏，单击云产品监控。
筛选并进入对象存储OSS监控页面，如下图。

4、在对象存储OSS页签，会列出Bucket列表基本信息，包括Bucket名称、地域、存储大小、公网流出流量、Get类请求数和Put类请求数，如下图。

5、单击目标Bucket操作列的监控图表，按照服务监控总览、请求状态详情、计量参考、平均延时、最大延时、成功请求操作分类6个维度查询相应的监控图表，如下图。

至此，小浩已经掌握了监控服务的使用，回顾前面梳理的oss监控指标体系，结合对监控服务的使用，发现监控服务可以很好地呈现出用户/单个Bucket请求的状态分布以及请求状态详情，可以有效帮助他监控资源的运行状态。

报警服务使用操作

小浩在监控OSS资源使用情况时发现，监控服务只支持主动查看对应的监控信息，小浩需要当资源的监控指标达到一定阈值时能够自动发送报警通知，这样小浩就能及时监控异常数据并作出快速响应。

步骤：

登录云监控控制台。
在左侧导航栏，选择报警服务 > 报警规则。
在报警规则列表页面，单击创建报警规则，如下图。

4、在创建报警规则页面，设置报警规则相关参数。

查询报警规则

步骤：

登录云监控控制台。
在左侧导航栏，选择报警服务 > 报警规则。
在报警规则列表页面，会展示创建的报警规则，可以对报警规则详情、报警历史查看、修改报警规则等操作

至此，小浩已经完成了报警规则的配置，针对指标设定了一定的阈值，在达到一定的阈值后能及时自动报警，让小浩能及时响应处理，降低对业务造成的影响，掌握了这些技能后，小浩对存储层性能保障充满了信心。

事件通知

小浩学习了监控用户层级和单个Bucket运行状态之后，突然想到研发人员提的需求，希望能对某些Object操作时收到系统通知，小浩发现监控服务并不能满足此需求，于是带着这个问题再次找到架构师大雷请教。

小浩：雷哥，我已初步了解对象存储OSS的监控服务，现在我希望有人在操作文件时OSS能及时地发出通知，我看了下OSS自身是不支持的。

大雷：对的，你可以通过消息服务MNS来实现，通过创建事件的规则，当操作object的请求（比如DeleteObject、PutObject等）到OSS时，由消息服务MNS来推送事件通知。

小浩：原来是这样，那我去研究下如何基于消息服务MNS来实现事件通知的。

大雷：去吧，你现在已经开始主动思考问题了，加油，有问题随时来找我。

事件类型

小浩开始研究对Object操作的事件通知之前，梳理了OSS支持的事件类型如下：

小浩已经知道在创建OSS事件通知时，需要开通MNS服务，那什么是MNS服务呢？小浩查找到MNS的介绍文档：

消息服务MNS文档地址：什么是消息服务MNS_消息服务(MNS)-阿里云帮助中心

事件通知使用流程

小浩带着对技术的极致热情开始研究事件通知的使用流程，当有请求触发了设置的事件规则时，消息是如何完成推送流程的呢？小浩一边学习一边梳理：

通过对流程梳理小浩发现，首先需要创建事件通知规则......

事件通知配置

步骤：

登录OSS管理控制台。
单击Bucket列表，然后单击目标Bucket名称。
在左侧导航栏，选择数据处理 > 事件通知。
在事件通知页面，单击创建规则。
在创建规则面板，进行参数配置：

说明：事件规则配置完成后一般在10min后生效。

事件通知验证

步骤：

小浩结合之前的oss所学内容，根据配置的删除文件事件类型，小浩首先删除了目标Bucket内一个名为111.jpg的文件；
登录消息服务MNS控制台。
在左侧导航栏，单击队列列表。
在顶部菜单栏，选择队列所在地域。
在队列列表页面，单击目标队列或单击目标队列右侧详情。
在目标队列详情页面会看到可用消息条数，单击收发消息，如下图。

7、进入收发消息快速体验页面，单击接收消息，出现消费的消息，如下图。

8、单击消息对应的详情，进入消息详情，下滑页面看到解码后的消息内容，可验证是否为删除的文件，如下图。

至此，小浩已完整的体验了事件通知的配置、触发、推送等整个流程，小浩舒展了一下身体，露出开心的笑容，小浩准备休息一下，继续研究如何进行OSS日志管理......

日志管理

小浩前面提出的对象存储OSS服务运维保障的三个问题已经解决了两个，还剩一个问题：“是否可以把资源的操作记录下来，以满足一些合规需求”，小浩决定主动学习一下日志管理相关的内容，首先小浩思考：

有哪些日志管理方式？
操作日志会保存在哪里？
保存后的日志如何进行分析以辅助业务决策。

带着上述几个小问题，小浩开始了以下学习......

日志管理概述

访问OSS的过程中会产生大量的日志，通过OSS提供的日志转存或者使用日志服务SLS组件可以帮助用户完成OSS访问的操作审计、访问统计、异常事件回溯和问题定位等工作，提升工作效率并可以更好地基于数据进行决策。

什么是日志转存

OSS提供了可以将访问OSS过程中的操作记录到同一账号下相同地域的Bucket内、以文件形式保存在自定义的前缀（目录）下的功能。以下是日志转存的开启方式：

学习完小浩迫不及待地打开控制台进行实操。

日志转存配置

步骤：

登录OSS管理控制台。
单击Bucket列表，然后单击目标Bucket名称。
在左侧导航栏，选择日志管理 > 日志转存。
在日志转存页面，打开日志存储开关，并设置日志存储位置及日志前缀。
单击保存。

小浩开启日志转存后，就兴奋地开始对OSS进行访问操作，上传、下载了一些文件，然后去查看对应日志是否有生成，却发现并未产生日志文件。小浩疑惑地查看产品文档发现，日志转存功能开启后，需要以小时为单位生成日志文件写入您指定的存储空间（Bucket），开通日志转存会立刻生效，但日志最晚 24 小时内生成，刚好小浩也想休息一下......

休息过后，小浩查看配置的Bucket发现日志已经生成，小浩想把日志下载下来看看日志的内容及格式。

日志转存格式及内容示例

小浩下载了生成的日志文件，查看文件发现日志内容如下：

通过查看日志内容和格式小浩发现，日志文件及内容较少时，直接下载文件打开查看也很方便，但当大量日志产生时，人工查看及关键信息检索的效率会大大降低，于是小浩继续寻找是否有工具辅助查询，经过查看文档小浩找到了分析方法：

通过日志服务SLS对日志文件进行分析。对日志文件进行分析前，需要通过数据导入方式将OSS日志文件导入到日志服务。详情可参考导入OSS数据。有关日志服务分析功能可参考分析概述。
OSS与日志服务SLS相结合，提供了实时日志查询的能力。

实时日志查询

学习完日志转存功能之后，小浩发现OSS与日志服务SLS结合还提供了实时日志查询的能力，可以在实际生产业务中带来较大的效率提升。小浩发现通过OSS控制台即可直接查询OSS的访问日志，辅助完成OSS访问的操作审计、访问统计、异常事件回溯和问题定位等工作，小浩开始尝试实操起来......

实时日志查询实操

首先需要先开通日志服务且进行云资源访问授权

开通步骤如下图：

开通SLS服务之后，OSS免费提供最近7天内的日志查询，页面如下：

日志聚类地址：如何开启、查看、对比日志聚类_日志服务(SLS)-阿里云帮助中心

小浩已初步掌握了实时日志查询的技能，但是小浩发现基于原始日志需要输入查询条件，他对查询语法还需要进一步学习，详情参考查询语法。

小浩在研究实时日志查询的过程中，发现日志服务SLS还提供了CloudLens for OSS功能，小浩的好奇心又启动起来：

什么是CloudLens？
什么是CloudLens for OSS？
CloudLens for OSS能做什么？

带着三个疑问，小浩又孜孜不倦地开启了新的求知之路......

CloudLens for OSS

小浩带着自己的三个疑问开始了学习：

CloudLens资料地址：CloudLens的原理及应用场景_日志服务(SLS)-阿里云帮助中心

CloudLens for OSS资料地址：CloudLens for OSS使用前须知_日志服务(SLS)-阿里云帮助中心

文档中小浩了解到：

CloudLens基于日志服务构建统一的云产品可观测能力，通过日志、指标、配置计量等数据的关联分析，提供阿里云产品的用量分析、性能监控、安全分析、数据保护、异常检测、访问分析等服务，从成本、性能、安全、数据保护、稳定性、访问分析六个维度，快速构建云产品的可观测性，辅助用户更好地使用云产品。

CloudLens for OSS是日志服务联合阿里云OSS推出的，支持Bucket粒度的统一管理视图，支持资源用量、访问分析、异常检测、安全分析等可视化分析能力，提供场景化运维管理，实现Bucket资产的可观测性。

小浩设想，CloudLens for OSS也可以和前面学习到的运维保障互为补充，更好地保障OSS的状态，也能保障公司业务的稳定，降低业务不可服务概率。那还等什么，开始研究用起来吧，小浩说干就干，开启了使用CloudLens for OSS之旅......

如何登录CloudLens for OSS

小浩登录到日志服务SLS控制台，按照提示开通日志服务SLS(若已开通，请忽略)，进入SLS产品页，找到云产品Lens--->CloudLens for OSS

开启CloudLens for OSS

进入CloudLens for OSS，若未开启服务，则会弹出开启页面

2、点击立即开启按钮后弹出如下页面，选择存储地域，日志服务自动在指定地域创建专属Project，然后单击立即开通

说明：由于CloudLens会默认帮用户开启中心化存储的计量日志和时序监控数据，因此首次使用时会需要您选择一个中心化地域，该地域一旦选择，不允许修改，如果是公有云地域，建议优先选择北京、上海、杭州、深圳等公有云相对较大的地域或Bucket比较集中的地域。

等待数分钟后，小浩发现之前创建的Bucket已出现在接入管理的Bucket列表下。

说明：后台对Bucket资产的同步时间，具体取决于用户Bucket的数量，一般不超过半小时。

开启功能后，小浩首先查看CloudLens提供了哪些功能，通过上图左侧菜单栏发现CloudLens for OSS 提供了接入管理、查询分析、异常检测、报表中心等功能，小浩对这些功能进行梳理：

功能梳理

那日志数据是如何接入的呢？

日志数据的接入

小浩查阅文档发现：当前提供访问明细日志（原实时日志）、计量日志、时序监控数据三种日志，其中访问明细日志需要用户按需手动开启，其他两种日志将会由后台异步自动开启，会有一定的延迟。

访问明细日志：记录相关OSS Bucket的所有访问日志及批量删除日志时具体的删除信息，实时采集，同时也包含计量日志。
计量日志：记录特定OSS Bucket每小时累计的计量数据。延迟时间为几小时，用于辅助分析，默认免费开通。
时序监控数据：记录10秒粒度的请求、延迟、流量等指标及5分钟粒度的请求、流量等指标。默认免费开通。

了解完CloudLens for OSS提供的功能特性及日志接入流程后，小浩开始练习起来，首先小浩先手动接入访问明细日志......

接入访问明细日志

开通对应Bucket的访问明细日志，可以查看详细的访问操作日志，可通过接入管理页面开启。

说明：有默认7天（每天900G）的免费额度，基本上都可以免费使用，可以放心开通。您也可以随时关闭Bucket的访问日志采集，关闭后对应Bucket新的访问明细日志将不会再写入日志库，但不影响继续查询历史数据。

存储目标库管理

访问明细日志默认存储7天，计量日志、时序监控数据默认存储60天，如需调整存储时间，可通过目标存储库进行修改。

说明：超过免费存储时间将会产生费用，可根据实际需要评估。超过30天的数据支持开启智能冷热分层，费用更低，查询分析会有10秒延迟，参考智能冷热分层，如果是在免费周期内，您可无需开启。

查询分析日志

进入查询分析-->访问明细分析，得到根据条件查询出来的日志信息如下图：

说明：如果对应地域下没有开启过任意一个Bucket的访问明细日志，则需要先行开启（见接入访问明细日志步骤），否则无法直接查询。

2、进入查询分析-->计量日志，可以查询分析所有Bucket的计量数据，也可选择过滤条件。

如果您不想或还不熟悉查询分析语句，可以切换至交互模式，您动动鼠标即可自动构建需要的语句，详情可参考Data Explorer。

访问明细日志交互模式下内置了一些高频分析场景，可一键快速进行分析。

快速发现异常事件

CloudLens内置了一些比较常用的告警规则，可以快速发现Bucket使用过程中的一些异常情况，从而能够及时响应，避免不必要的损失，详情参考监控规则。

创建告警

进入异常告警-->告警管理，进入Bucket试图的告警页面，可以针对指定的Bucket配置需要的告警规则。

说明：告警名称默认为规则名称，一般保持默认即可，可以根据需要进行调整，其他默认阈值也都需要根据实际配置一个合理的值。

2、编辑行动策略

首次创建告警时，由于默认的行动策略为SLS OSS内置行动策略，该内置策略关联的用户组下默认没有用户，需要用户先创建用户加入到该用户组，同时默认的行动组只支持邮件，如果需要增加其他通知渠道也需要修改行动策略，具体操作可参考创建行动策略，也可以选择创建新的行动策略。

3、创建用户

如果用户已创建，则直接将对应用户加入用户组即可，如下：

如果用户未创建，可取消修改用户组的对话框，点击用户组管理，选择用户管理-->创建用户，详情参考创建用户。

用户创建完成后，继续点击上方用户管理标签页，切换到用户组管理，修改用户组，添加刚刚创建的用户即可。

4、添加通知渠道

如需添加通知渠道，可参考通知渠道管理。

5、管理已有告警

如果需要修改已创建的告警规则，可通过操作列的告警管理进入。

可以编辑修改告警相关阈值参数等，也可以关闭/开启告警，或直接删除告警。

数据的可观测性

CloudLens for OSS提供了一些核心数据的可视化报表，方便用户对历史、实时数据进行快速分析，主要涵盖：

资源用量：提供OSS存储、流量等基本维度的用量概览，方便全局把握OSS使用情况。
访问分析：从使用视角分析OSS各bucket的流量分布、访问TOP分布等。
安全分析：暴露OSS Bucket配置的风险点和高危Object操作。

各报表均支持选择地域、存储类型、Bucket作为过滤器进行过滤分析。

资源用量

进入报表中心-->资源用量，查看存储量趋势、宽带等核心资源的使用等情况。

说明：流量/带宽/请求等依赖中心化的时序监控数据，可以方便您全局分析Bucket的内外网出入流量、带宽及读写请求等趋势分析。

2、访问分析

进入报表中心-->访问分析，了解使用行为情况，辅助产品使用和业务运营分析。

下滑上图页面，可以看到流量top分析、请求top分析、文件请求top20等信息。

3、安全分析

进入报表中心-->安全分析，暴露不合理的配置和高危操作，给出优化建议。

Bucket 配置健康分析：主要针对Bucket的配置风险点提供优化建议，尽量避免可能的隐患

说明：从下图可以看到配置健康分析中的风险类型，以及出现某类风险的Bucket数量及名称

2、Object操作风险分析：依赖访问明细日志，展示文件删除等高危操作的执行情况。

至此，小浩已基本熟悉了CloudLens for OSS的操作流程如何查看资源访问明细情况、资源用量情况、访问分析、安全分析情况、告警大盘、告警管理等，同时也熟悉了其中各指标代表的含义，如何依据这些数据去分析具体问题等。

因为小浩之前有了解到使用SLS需要创建Project（项目），创建Logstore（日志库）、MetrticStore（时序库），但是参照文档实操完成之后，小浩并未进行创建，又查看文档资料发现，在开通CloudLens for OSS之后，日志服务会在专属的Project中创建Logstore、MetricStore等，无需小浩再去创建。

到此小浩已掌握了对象存储OSS大部分的功能，但在深入学习研究的过程中也发现了一些不足，对于OSS周边生态产品比如SLS还不够熟悉，经过本阶段的学习，小浩对对象存储OSS的研究暂告一段落，可以助力公司提高存储运维效率及降本增效，同时小浩也暗自给自己加油打气：“小浩，加油，下阶段目标争取熟练掌握日志服务SLS”。