OSS服务监控、诊断和故障排除

相对于传统的软件运行环境，云数据分布式托管环境虽然解决了很多应用业务在基础设施搭建、运维管理等方面的问题和成本困难，使得应用服务搭建的门槛降低，但是其复杂的云环境，也大大增加了对其监控、诊断和故障排查的难度。

若要成功管理运行在云环境中应用程序，需要主动监视其行为，并熟悉如何诊断和排查自己的应用程序及其依赖的云服务技术的所有方面的问题。而OSS存储服务为用户提供了可以简化监控、诊断和排查基于云的应用程序中关于存储问题的过程。作为OSS的用户，你可以利用OSS提供的监控服务(即将上线)持续监视应用程序所用的存储服务是否出现任何异常的行为，并通过报警服务(即将上线)及时发现。另外，配合使用logging设置功能收集更详细的数据并深入地分析问题。从监控和日志记录获取的诊断信息将有助于确定应用业务所遇到问题的根本原因。然后，可以排查该问题，并确定解决问题的相应执行步骤。

因为OSS监控服务功能即将上线，所以，这里先抛砖引玉介绍介绍如何能够更好的利用我们的监控服务和现有工具来为你服务！

概述

这里主要描述如何使用OSS监控服务、logging日志记录功能以及其他第三方工具来监控、诊断和排查与应用业务使用OSS存储服务时遇到相关的问题，帮助用户达到如下目标：

• 帮助实时监控OSS存储服务的运行状况和性能，并及时报警通知。
• 提供必要的过程和工具来帮助用户确定应用程序中的问题是否与OSS有关。
• 提供常见的OSS存储服务相关问题的处理和操作指南，用于快速定位并且解决与OSS相关的问题。

本章内容组织如下：

• OSS监控服务实时监控，介绍如何使用OSS监控服务持续监控OSS存储服务的运行状况和性能。
• 跟踪诊断，介绍如何使用OSS监控服务和logging记录功能诊断问题；另外，还介绍如何关联各种日志文件中的相关信息进行跟踪诊断。
• 问题排查，提供常见的问题场景和故障排除方法。

OSS监控服务监控

监视总体运行状况

可用性和有效请求率

这是系统有关系统稳定性和用户是否正确使用系统的最重要指标，任何小于100%的情况说明某些请求出现失败的情况。

当然，可用性也可能因为一些系统优化因素出现暂时性的低于100%，比如为了负载均衡而出现分区迁移，此时OSS的SDK能够提供相关的重试机制无缝处理这类间歇性的失败情况，使得业务端无感知。

另外，对于有效请求率低于100%的情况，用户需要根据自己的使用情况进行分析，可以通过请求分布统计或者请求状态详情确定错误请求的具体类型，跟踪诊断确定原因，并故障排除。当然，对于一些业务场景，出现有效请求率低于100%是符合预期的，比如，用户需要先check访问的object是否存在，然后根据object的存在性采取一定的操作，如果object不存在，检测object存在性的读取请求必然会收到404错误(资源不存在错误)那么必然会导致该指标项低于100%。

对于系统可用性指标要求较高的业务，可以设置其报警规则，当低于预期阈值时，进行报警。

总请求数和有效请求数

该指标从总访问量角度来反应系统运行状态。当有效请求数不等于总请求数时表明某些请求出现失败的状况。

用户可以关注总请求数或者有效请求数的波动状况，特别是突然上升或者下降的情况，需要进行跟进调查，可以通过设置报警规则进行及时通知，对于存在周期性状况的业务，可以设置为环比报警规则。

请求状态分布统计

当可用性或者有效请求率低于100%（或者有效请求数不等于总请求数时），可以通过查看请求状态分布统计快速确定请求的错误类型。

监视请求状态详情

请求状态详情在请求状态分布统计的基础上进一步细化请求监控状态，可以更加深入、具体的监视某类请求。

监视性能

监控服务提供了以下几个监控项用来监控性能相关的指标。

• 平均延时
  • E2E平均延时
  • 服务器平均延时

• 最大延时
  • E2E最大延时
  • 服务器最大延时

• 成功请求操作分类

• 流量

以上各个监控项(除流量)都分别从API操作类型进行分类监控：

• GetObject
• HeadObject
• PutObject
• PostObject
• AppendObject
• UploadPart
• CopyObject
• UploadPartCopy

延时指标显示API操作类型处理请求所需的平均和最大时间。其中E2E延时是端到端延迟指标，除了包括处理请求所需的时间外，还包括读取请求和发送响应所需的时间还有请求在网络上传输的延迟；而服务器延时只是请求在服务器端被处理的时间，不包括与客户端通信的网络延时。所以当出现E2E延时突然升高的情况下，如果服务器延时并没有很大的变化，那么可以判定是网络的不稳定因素造成的性能问题，排除OSS系统内部故障。

成功请求操作分类除了以上提到的API之外，还提供以下两个API操作类型请求数量的监控：

• DeleteObject
• DeleteObjects

流量指标从用户或者具体的Bucket层级的总体情况进行监控，关注公网、内网、cdn回源以及跨域复制等场景中的网络资源占用状况。

对于性能类指标项，我们需要重点关注其突发的异常变化，例如，平均延时突然出现尖峰，或者长时间处于高出正常请求延时的基线上方等等。用户可以通过对性能指标设置对应的报警规则，对于低于或者超过阈值时及时通知到相关人员。对于有业务周期性的业务，可以设置环比报警规则(环比一周、环比一天或者环比一个小时)。

监视计量

攥写本文档时，OSS监控服务只支持监控存储大小、公网流出流量、Put类请求数和Get类请求数(不包括跨区域复制流出流量和cdn流出流量)，而且不支持对计量数据的报警设置和OpenAPI的读取。

OSS监控服务对Bucket层级的计量监控数据进行小时级别的粒度采集，可以在具体的Bucket监控视图中查看其持续的监控趋势图。用户可以根据监控视图分析其业务的存储服务资源使用趋势并且进行成本的预估等。

OSS监控服务还提供了用户层级和Bucket层级两个不同维度的当月消费的资源数统计，即从当月1号开始到目前的账户或者某个Bucket所消耗的OSS资源总量，每小时更新。能帮助用户实时了解本月使用资源的情况并计算消费。

• OSS的消费计算可以使用价格计算器。
• OSS详细的计费方式参考OSS价格总览。

注: 监控服务中提供的计量数据是尽最大可能推送的，可能会与实际消费账单中产生差异，请以费用中心的数据为准。

跟踪诊断

问题诊断

诊断性能

对于应用程序的性能判断多带有主观因素，用户需要根据具体的业务场景确定满足业务需求的基准线，来判定性能问题。另外，从客户端发起的请求，能引起性能问题的因素贯穿整个请求链路。比如OSS存储服务load过大、客户端tcp配置问题或网络基础结构中存在流量瓶颈等。

因此诊断性能问题首先需要设置合理的基准线，然后通过监控服务提供的性能指标确定性能问题可能的根源位置，然后根据日志查到详细的信息以便进一步诊断并且排除故障。

在下文“故障排除”中例举了很多常见的性能问题和排查措施，可以参考。

诊断错误

客户端应用程序会在请求发生错误是接收到服务端返回的相关错误信息，监控服务也会记录并显示各种错误类型请求的计数和占比。用户也可以通过检查服务器端日志、客户端日志和网络日志来获取相关单个请求的详细信息。通常，响应中返回的HTTP状态代码和OSS错误码以及OSS错误信息都指示请求失败的原因。

相关错误响应信息参考OSS错误响应。

使用logging功能

OSS存储服务为用户的请求提供服务端日志记录功能，能帮助用户记录端到端的详细请求日志跟踪。

有关如何开启并使用logging功能，请参考日志设置。

有关日志服务的命名规则以及记录格式等详细信息，参见访问日志记录。

使用网络日志记录工具

在许多情况下，通过logging功能能够记录的存储日志和客户端应用程序的日志数据已足以诊断问题，但在某些情况下，可能需要更详细的信息，这时我们需要使用网络日志记录工具。

因为，捕获客户端和服务器之间的流量，可以更详细地获取客户端和服务器之间交换的数据以及底层网络状况的详细信息，帮助问题的调查，例如，在某些情况下，用户请求可能会报告一个错误，而服务器端日志中却看不到任何该请求的访问情况，这时就可以使用OSS的日志服务功能记录的日志记录来调查该问题的原因是否出在客户端上，或者使用网络监视工具来调查网络问题。

最常用的网络日志分析工具之一应该是Wireshark。该免费的协议分析器运行在数据包级别，能够查看各种网络协议的详细数据包信息，从而可以排查丢失的数据包和连接问题。

WireShark使用参考WireShark安装使用。

更详细的WireShark操作参见WireShark用户指南。

E2E跟踪诊断

请求从客户端应用进程发起，通过网络环境，进入OSS服务端被处理，然后响应从服务端回到网络环境，被客户端接收。整个过程，是一个端到端的跟踪过程。关联客户端应用程序日志、网络跟踪日志、和服务端日志，有助于排查问题的详细信息根源，发现潜在的问题。

在OSS存储服务中，提供了RequestID作为关联各处日志信息的标识符。另外，通过日志的时间戳，不仅可以迅速查找和定位日志范围，还能够了解在请求发生时间点范围内，客户端应用、网络或者服务系统发生的其他事件，有利于问题的分析和调查。

RequestID

OSS服务始会为接收的每个请求分配唯一的服务器请求ID，即RequestID。在不同的日志中，RequestID位于不同的字段中:

• 在OSS logging功能记录的服务端日志记录中，RequestID出现在“Request ID”列中。
• 在网络跟踪（如WireShark捕获的数据流)中，RequestID作为x-oss-request-id标头值出现在响应消息中。
• 在客户端应用中，需要客户端code实现的时候将请求的RequestID自行打印到客户端日志中。在攥写本文的时候，最新版本的JAVA SDK已经支持打印正常请求的RequestID信息，可以通过各个API接口返回的Result结果的getRequestId这个方法获取。OSS的各个版本SDK都支持打印出异常请求的RequestID，可以通过调用OSSException的getRequestId方法获取。

时间戳

使用时间戳来查找相关日志项，需要注意客户端和服务器之间可能存在的时钟偏差。在客户端上基于时间戳搜索logging功能记录的服务器端日志条目时，应加/减15分钟。

故障排除

性能相关常见问题

高平均E2E延时和低平均服务端延时

通过前面的介绍，平均E2E延时与平均服务器延时的区别。所以，产生高E2E延时、低服务器延时可能的原因有两个:

• 客户端应用程序响应慢。
• 网络原因导致。

调查客户端的性能问题

客户端应用程序响应速度慢的可能原因包括：

• 可用连接数或可用线程数有限。
  • 对于可用连接数问题，可以通过以下方式优化:

1. 通过使用相关命令确定系统是否存在大量TIME_WAIT状态的连接;
2. 如果是，可以通过调整内核参数解决。

对于可用线程数有限，可以先查看客户端CPU、内存、网络等资源是否已经存在瓶颈，如果没有，适当调大并发线程数。 如果还不能解决问题，那么就需要通过优化客户端代码，比如，使用异步访问方式等。也可以使用性能分析功能分析客户端应用程序热点，然后具体优化。 CPU、内存或网络带宽等资源不足。

• 对于这类问题，需要先使用相关系统的资源监控查看客户端具体的资源瓶颈在哪儿，然后通过优化代码使其对资源的使用更为合理，或者通过扩容客户端资源(使用更多的内核或者内存)。

调查网络延迟问题

通常，因网络导致的高端到端延迟是由暂时状况导致的。可以使用Wireshark调查临时和持久网络问题，例如数据包丢失问题。

WireShark使用参考WireShark安装使用。

低平均E2E延时和低平均服务端延时，但客户端请求高延时

客户端出现请求延时高的情况，最可能的原因是请求还未达到服务端就出现了延时。所以应该调查来自客户端的请求为什么未到达服务器。

客户端延迟发送请求可能的客户端原因有两个:

• 可用连接数或可用线程数有限，在上面章节已经描述过解决方案。
• 客户端请求出现多次重试，如果遇到这种情况，需要根据重试信息具体调查重试的原因再解决。可以通过下面方式确定客户端是否出现重试:
  • 检查客户端日志。详细日志记录会指示重试已发生过。以OSS的JAVA SDK为例，可以搜索如下日志提示，warn或者info的级别。如果存在该日志，说明可能出现了重试。
    

    [Server]Unable to execute HTTP request:
    或者
    [Client]Unable to execute HTTP request:

  • 如果客户端的日志级别为debug，以OSS的JAVA SDK为例，可以搜索如下日志，如果存在，那么肯定出现过重试。
    

    Retrying on 

如果客户端没有问题，则应调查潜在的网络问题，例如数据包丢失。可以使用工具（如 Wireshark ）调查网络问题。

WireShark使用参考WireShark安装使用。

高平均服务端延时

• 对于下载出现高服务端延时的情况，可能的原因有2个:
  • 存在大量请求同时访问、或者频繁访问同一个Object文件。这种情况，可以通过查看logging功能记录的服务端日志信息来确定是否在一段时间内，某个或某组Object被频繁访问。如果确定是这种场景，那么建议用户为该Bucket开通CDN服务，利用CDN来提升性能，并且可以节约流量费用。
  • 系统内部因素。
• 对于上载情况，可能的原因也有2个:
  • 存在大量的客户端频繁访问同一个Object。这种情况同样可以通过查看logging功能记录的信息确定。针对这类情况，用户可以考虑在不影响业务需求的情况下，收回Object(bucket)的访问权限。
  • 系统内部因素。

对于系统内部或者不能通过优化方式解决问题，请提供客户端日志或者loggging功能记录的日志信息中的RequestID，联系系统工作人员协助解决。

服务端错误问题

对于服务端错误的增加，可以分为两个场景考虑:

• 暂时性的增加。

对于这一类问题，用户需要调整客户端程序中的重试策略，采用退让机制，这样不仅可以有效避免因为优化或者升级等系统操作(如为了系统负载均衡进行分区迁移等)暂时导致的服务不可用问题，还可以避开业务峰值的压力。

• 永久性的增加。

如果服务端错误持续在一个较高的水平，那么需要提供客户端日志或者logging功能记录的RequestID，联系后台工作人员协助调查。

网络错误问题

对于网络错误请求的增加，原因是客户端在存储服务超时到期之前断开了连接。对于这样的问题，需要调查客户端中的代码，了解客户端断开与存储服务连接的原因和时间。

用户可以使用工具(如Wireshark)调查客户端的网络连接问题。

WireShark使用参考WireShark安装使用。

客户端错误问题

客户端授权错误请求增加

当监控中的客户端授权错误请求数增加，或者客户端程序接收到大量的403请求错误，那么最常见的可能原因有如下几个:

• 用户访问的Bucket域名不正确。

1. 如果用户直接用三级域名或者二级域名访问，那么可能造成403的原因就是用户的Bucket并不属于该域名所指示的region内，比如，用户创建的Bucket的地域为杭州，但是访问的域名却为Bucket.oss-cn-shanghai.aliyuncs.com。这时需要确认Bucket的所属区域，然后更正域名信息。
2. 如果用户开启了cdn加速服务，那么可能造成的原因是cdn绑定的回源域名错了，客户应该检查cdn回源域名是否为用户Bucket的三级域名。

如果用户使用javascript客户端遇到403错误，可能的原因就是CORS(跨域资源共享)的设置问题，因为Web浏览器实施了“同源策略”的安全限制。用户需要先检查所属Bucket的CORS设置是否正确，并进行相应的更正。设置CORS参考跨域资源共享。 访问控制问题可以分为下面四种:

1. 用户使用主AK访问，那么用户需要检查是否AK设置出错，使用了无效AK。
2. 用户使用RAM子账号访问，那么用户需要确定RAM子账号是否使用了正确的子AK，或者对应子账号的相关操作是否已经授权。
3. 用户使用STS临时Token访问，那么用户需要确认一下这个临时Token是否已经过期。如果过期，需要重新申请。
4. 如果Bucket或者Object设置了访问控制，这个时候需要查看用户所访问的Bucket或者Object是否支持相关的操作。

授权第三方下载，即用户使用签名URL进行OSS资源访问，如果之前访问正常而突然遇到403错误，最大可能的原因是URL已经过期。 RAM子账号使用OSS周边工具的情况也会出现403错误。这类周边工具如ossftp、ossbrowser、OSS控制台客户端等，在填写相关的AK信息登入时就抛出错误，此时如果你AK是正确填写的，那么你需要查看你使用AK是否为子账号AK，该子账号是否有GetService这样操作的授权等等。这里需要强调一点，集团内部申请的OSS资源都为RAM子账号，所以这些工具的使用都会受限。

客户端资源不存在错误请求增加

客户端收到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请求)这些错误请求之外的请求。

可以通过查看logging功能记录的服务端日志确定这些错误的具体类型，可以在OSS错误响应上找到存储服务返回的常见错误码的列表，然后检查客户端代码中查找具体原因进行解决。

存储大小异常增加

储存大小异常增加，如果不是上载类请求量增多，一般常见的原因应该是清理操作出现了问题，可以根据下面两个方面进行调查:

• 客户端应用使用特定的进程定期清理来释放空间: 针对这种请求的调查步骤是:

1. 查看有效请求率指标是否下降，因为失败的删除请求会导致清理操作没能按预期完成。
2. 定位者请求有效率降低的具体原因，查看是具体是什么错误类型的请求导致。然后还可以结合具体的客户端日志定位更详细的错误信息（例如，因为用于释放空间的STS临时Token已过期）。

客户端通过设置LifeCycle来清理空间: 针对这种请求，需要通过控制台或者API接口查看目前Bucket的LifeCycle是否为之前设置的预期值。如果不是，可以直接更正目前配置；进一步的调查可以通过logging功能记录的服务端日志记录查询以前修改的具体信息。如果LifeCycle是正常的，但是却没有生效，请联系OSS系统管理员协助调查。

其他存储服务问题

如果前面的故障排除章节未包括你遇到的存储服务问题，则可以采用以下方法来诊断和排查你的问题。

首先，查看OSS监控服务，了解与预期的基准行为相比是否存在任何更改。监控视图，可能能够确定此问题是暂时的还是永久性的，并可确定此问题影响哪些存储操作。

然后，可以使用监控信息来帮助你搜索logging功能记录的服务端日志数据，以获取相关时间点发生的任何错误信息。此信息可能会帮助你排查和解决该问题。

如果服务器端日志中的信息不足以成功排查此问题，则可以使用客户端日志来调查客户端应用程序，或者配合使用网络工具（Wireshark等）调查你的网络问题。