OSS存储服务提供了全面的监控指标和详细的日志记录功能,协助您深入洞察程序运行行为,快速发现潜在问题,并精准定位故障根源,从而大幅提升问题解决效率。
本文主要描述如何使用OSS监控服务、日志记录功能以及其他第三方工具来监控、诊断和排查应用业务使用OSS存储服务时遇到的相关问题,帮助您达到如下目标:
实时监控OSS存储服务的运行状况和性能,并及时报警通知。
获取有效的方法和工具来定位问题。
根据相关问题的处理和操作指南,快速解决与OSS相关的问题。
本文包括如下内容:
服务监控
监控总体运行状况
可用性和有效请求率
可用性和有效请求率是系统稳定性和用户使用情况的重要指标,低于100%表示存在失败的请求。
可能因为一些系统优化因素出现暂时性的低于100%,例如为了负载均衡而出现分区迁移,此时OSS的SDK能够提供相关的重试机制无缝处理这类间歇性的失败情况,使得业务端无感知。
对于有效请求率低于100%的情况,您需要根据自己的使用情况进行分析,可以通过请求分布统计或者请求状态详情确定错误请求的具体类型、原因,并排除故障。
对于某些业务场景,出现有效请求率低于100%是符合预期的。例如,用户检查Object存在性时,若Object不存在,会收到404错误,导致指标低于100%。
对于系统可用性要求高的业务,可以设置报警规则,低于阈值时报警。
总请求数和有效请求数
该指标从总访问量角度来反应系统运行状态,当有效请求数不等于总请求数时表明某些请求失败。
您可以关注总请求数或者有效请求数的波动状况,特别是突然上升或者下降的情况,需要进行跟进调查,可以通过设置报警规则进行及时通知。具体操作,请参见报警服务使用指南。
请求状态分布统计
当可用性或者有效请求率低于100%(或者有效请求数不等于总请求数时),可以通过查看请求状态分布统计快速确定请求的错误类型。有关该统计监控指标的更多信息,请参见OSS监控指标参考手册。
监控请求状态详情
请求状态详情是在请求状态分布统计的基础上进一步细化请求监控状态,可以更加深入、具体地监控某类请求。
监控性能
监控服务提供了以下监控项来监控性能相关的指标:
平均延时,包括E2E平均延时和服务器平均延时
延时指标显示API操作类型处理请求所需的平均和最大时间。其中E2E延时是端到端延迟指标,除了包括处理请求所需的时间外,还包括读取请求和发送响应所需的时间以及请求在网络上传输的延时;而服务器延时只是请求在服务器端被处理的时间,不包括与客户端通信的网络延时。所以当出现E2E延时突然升高的情况下,如果服务器延时并没有很大的变化,那么可以判定是网络的不稳定因素造成的性能问题,排除OSS系统内部故障。
最大延时,包括E2E最大延时和服务器最大延时
成功请求操作分类
流量
流量指标从用户或者具体的Bucket层级的总体情况进行监控,关注公网、内网、CDN回源以及跨域复制等场景中的网络资源占用状况。
以上各个监控项(除流量)都分别从API操作类型进行分类监控,包括:
GetObject
HeadObject
PutObject
PostObject
AppendObject
UploadPart
UploadPartCopy
成功请求操作分类除了以上提到的API之外,还提供以下两个API操作类型请求数量的监控:
DeleteObject
DeleteObjects
对于性能类指标项,您需要重点关注其突发的异常变化。例如,平均延时突然出现尖峰,或者长时间处于高出正常请求延时的基线上方等。您可以通过对性能指标设置对应的报警规则,当指标低于或者超过阈值时及时通知到相关人员。
监控计量
目前,OSS监控服务只支持监控存储空间大小、公网流出流量、Put类请求数和Get类请求数(不包括跨区域复制流出流量和CDN流出流量),不支持对计量数据的报警设置和OpenAPI的读取。
OSS监控服务对Bucket层级的计量监控数据进行小时级别的粒度采集,可以在具体的Bucket监控视图中查看其持续的监控趋势图。您可以根据监控视图分析其业务的存储服务资源使用趋势并且进行成本的预估等。
OSS监控服务还提供了用户层级和Bucket层级两个不同维度的当月消费的资源数统计。即统计阿里云账户或者某个Bucket当月消耗的OSS资源总量,每小时更新一次,帮助您了解本月资源的使用情况并计算消费。
有关OSS的计费项和计费方式的更多信息,请参见计量项和计费项。
说明监控服务中提供的计量数据是尽最大可能推送的,可能会与实际消费账单不一致,请以费用中心的数据为准。
跟踪诊断
问题诊断
诊断性能
对于应用程序的性能判断,您需要根据具体业务场景确定基准线。性能问题可能由OSS存储服务负载、客户端TCP配置或网络流量瓶颈引起。首先设置合理的基准线,通过监控服务的性能指标确定问题根源,然后根据日志进一步诊断和排除故障。
因此诊断性能问题首先需要设置合理的基准线,然后通过监控服务提供的性能指标确定性能问题可能的根源位置,接着根据日志查找详细的信息以便进一步诊断并且排除故障。
诊断错误
客户端应用程序在请求错误时会接收到服务端返回的错误信息,监控服务也会记录各种错误类型。您可以通过检查服务器端、客户端和网络日志获取详细信息。HTTP状态代码和OSS错误码指示请求失败原因。
有关错误响应的更多信息,请参见 OSS错误响应。
使用日志功能
OSS存储服务提供服务端日志记录功能,帮助用户记录详细请求日志。
使用网络日志记录工具
在某些情况下,可能需要使用网络日志记录工具捕获客户端和服务器之间的流量,获取详细数据和网络状况信息。例如,用户请求报告错误但服务器端日志中没有记录时,可以使用OSS日志服务或网络监控工具调查问题。常用工具之一是Wireshark,用于查看各种网络协议的详细数据包信息。更多信息,请参见安装Wireshark和使用WireShark。
E2E跟踪诊断
请求从客户端发起,通过网络进入OSS服务端处理,然后响应返回客户端。关联客户端、网络和服务端日志有助于排查问题根源。OSS提供RequestID作为日志关联标识符,通过时间戳可以迅速查找和定位日志范围,了解请求发生时的其他事件,有利于问题分析和调查。
RequestID
OSS为每个请求分配唯一的RequestID。在不同日志中,RequestID位于不同字段:
在OSS服务端日志中,RequestID出现在“Request ID”列中。
在网络跟踪(如WireShark捕获的数据流)中,RequestID作为x-oss-request-id标头值出现在响应消息中。
在客户端应用中,最新版本的Java SDK支持打印正常请求的RequestID,通过API接口返回的Result结果的getRequestId方法获取。异常请求的RequestID通过调用OSSException的getRequestId方法获取。
时间戳
使用时间戳查找相关日志项时,注意客户端和服务器之间可能存在的时间偏差。在客户端上基于时间戳搜索服务器端日志条目时,应加上或减去15分钟。
故障排除
性能相关常见问题
平均E2E延时高,而平均服务端延时低
可能原因如下:
客户端应用程序响应慢
可用连接数或可用线程数有限
使用相关命令检查系统连接状态,调整内核参数。
查看客户端资源瓶颈,适当调大并发线程数,优化客户端代码。
CPU、内存或网络带宽等资源不足
使用资源监控工具查看资源瓶颈,优化代码或扩容资源。
网络原因
使用Wireshark调查网络问题。
平均E2E延时低,平均服务端延时低,但客户端请求延时高
客户端出现请求延时高的情况,最可能的原因是请求还未达到服务端就出现了延时。因此,应该调查来自客户端的请求为什么未到达服务器。
对于客户端延迟发送请求,可能的客户端的原因有两个:
可用连接数或可用线程数有限
检查系统连接状态,调整内核参数。
查看客户端资源瓶颈,适当调大并发线程数,优化客户端代码。
客户端请求出现多次重试
检查客户端日志,调查重试原因,使用Wireshark调查网络问题。
检查客户端日志,详细日志记录会指示重试已发生过。以OSS的Java SDK为例,可以搜索如下日志提示,warn或者info的级别。如果存在该日志,说明可能出现了重试。
[Server]Unable to execute HTTP request: 或者 [Client]Unable to execute HTTP request:
如果客户端的日志级别为debug,以OSS的Java SDK为例,可以搜索如下日志,如果存在,那么肯定出现过重试。
Retrying on
平均服务端延时高
对于下载或者上传出现服务端高延时的情况,可能的原因有2个:
大量客户端频繁访问同一个小Object
查看服务端日志,考虑开通CDN服务或调整访问权限。
系统内部因素
提供客户端日志,联系售后技术人员协助解决。
服务端错误问题
暂时性的增加
调整客户端重试策略,采用合理的退让机制。
永久性的增加
提供客户端日志,联系售后技术人员协助调查。
网络错误问题
网络错误是指服务端正在处理请求时,连接在非服务器端断开而来不及返回HTTP请求头的情况。此时系统会记录该请求的HTTP状态码为499。以下几种情况会导致服务器记录请求的状态码变为499:
服务器在收到读写请求处理之前,会检查连接是否可用,不可用则为499。
服务器正在处理请求时,客户端提前关闭了连接,此时请求被记录为499。
在请求过程中,客户端主动关闭请求或者客户端网络断掉都会产生网络错误。对于客户端主动关闭请求的情况,需要调查客户端中的代码,了解客户端断开与存储服务连接的原因和时间。对于客户端网络断掉的情况,用户可以使用工具(如Wireshark)调查网络连接问题。
客户端错误问题
客户端授权错误请求增加
当监控中的客户端授权错误请求数增加,或者客户端程序接收到大量的403请求错误时,最常见的可能原因有以下几个:
用户访问的Bucket域名不正确
如果用户直接用三级域名或者二级域名访问,那么可能的原因就是用户的Bucket并不属于该域名所指示的region内,例如,用户创建的Bucket的地域为杭州,但是访问的域名却为Bucket.oss-cn-shanghai.aliyuncs.com。这时需要确认Bucket的所属区域,然后更正域名信息。
如果用户开启了CDN加速服务,那么可能的原因是CDN绑定的回源域名错误,请检查CDN回源域名是否为用户Bucket的三级域名。
如果用户使用JavaScript客户端遇到403错误,可能的原因就是CORS(跨域资源共享)的设置问题,因为Web浏览器实施了“同源策略”的安全限制。用户需要先检查所属Bucket的CORS设置是否正确,并进行相应的更正。有关设置CORS的具体步骤,请参见跨域资源共享。
访问控制问题
用户使用主AK访问时,用户需要检查是否AK设置出错,使用了无效AK。
用户使用RAM子账号访问时,用户需要确定RAM子账号是否使用了正确的子AK,或者对应子账号的相关操作是否已经授权。
用户使用STS临时Token访问时,需要确认一下这个临时Token是否已经过期。如果过期,需要重新申请。
如果Bucket或者Object设置了访问控制,这个时候需要查看用户所访问的Bucket或者Object是否支持相关的操作。
URL过期
授权第三方下载,即用户使用签名URL进行OSS资源访问,如果之前访问正常而突然遇到403错误,最大可能的原因是URL已经过期。
RAM子账号使用OSS周边工具的情况也会出现403错误。这类周边工具如ossftp、ossbrowser、OSS控制台客户端等,在填写相关的AK信息登录时就抛出错误,此时如果您的AK填写正确,那么您需要查看使用的AK是否为子账号AK,以及该子账号是否有GetService等操作的授权。
客户端资源不存在错误请求增加
客户端收到404错误说明用户试图访问不存在的资源信息。当看到监控服务上资源不存在错误请求增加,那么最大可能是以下问题导致的:
用户的业务使用方式。例如用户需要先检查Object是否存在来进行下一步动作,可以调用doesObjectExist(以JAVA SDK为例)方法,如果Object不存在,在客户端则收到false值,但是这时在服务器端实际上会产生一个404的请求信息。所以,这种业务场景下,出现404是正常的业务行为。
客户端或其他进程以前删除了该对象。这种情况可以通过搜索logging功能记录的服务端日志信息中的相关对象操作来确认。
网络故障引起丢包重试。例如客户端发起一个删除操作删除某个Object,此时请求达到服务端,执行删除成功,但是响应在网络环境中丢包,然后客户端发起重试,第二次的删除操作可能就会遇到404错误。这种由于网络问题引起的404错误可以通过客户端日志和服务端日志确定:
查看客户端应用日志是否出现重试请求。
查看服务端日志是否对该Object有两次删除操作,前一次的删除操作HTTP Status为2xx。
有效请求率低且客户端其他错误请求数高
有效请求率为请求返回的HTTP状态码为2xx/3xx的请求数占总请求的比例。状态码为4xx和5xx范围内的请求将计为失败并降低该比例。客户端其他错误请求是指除服务端错误请求(5xx)、网络错误请求(499)、客户端授权错误请求(403)、客户端资源不存在错误请求(404)和客户端超时错误请求(408或者OSS错误码为RequestTimeout的400请求)之外的请求。
您可以通过查看日志功能记录的服务端日志确定这些错误的具体类型,之后根据OSS错误响应码在客户端代码中查找具体原因进行解决。详情请参见OSS错误响应。
存储容量异常增加
存储容量异常增加,如果不是上传类请求量增多,常见的原因应该是清理操作出现了问题,可以根据下面两个方面进行调查:
客户端应用使用特定的进程定期清理来释放空间。针对这种请求的调查步骤是:
查看有效请求率指标是否下降,因为失败的删除请求会导致清理操作没能按预期完成。
定位请求有效率降低的具体原因,查看具体是什么错误类型的请求导致。然后还可以结合具体的客户端日志定位更详细的错误信息(例如,用于释放空间的STS临时Token已过期)。
客户端通过设置LifeCycle来清理空间:针对这种请求,需要通过控制台或者API接口查看目前Bucket的LifeCycle是否为之前设置的预期值。如果不是,可以直接更正目前配置;进一步的调查可以通过Logging功能记录的服务端日志查询以前修改的具体信息。如果LifeCycle是正常的,但是却没有生效,请联系OSS系统管理员协助调查。
其他存储服务问题
如果前面的故障排除章节未包括您遇到的存储服务问题,则可以采用以下方法来诊断和排查您的问题:
查看OSS监控服务,了解与预期的基准行为相比是否存在任何更改。监控视图可能能够确定此问题是暂时的还是永久性的,并可确定此问题影响哪些存储操作。
使用监控信息来帮助您搜索日志功能记录的服务端日志数据,获取相关时间点发生的任何错误信息。此信息可能会帮助您排查和解决该问题。
如果服务器端日志中的信息不足以成功排查此问题,则可以使用客户端日志来调查客户端应用程序,或者使用网络工具(Wireshark等)调查您的网络问题。