确定发生延迟的位置

注意：OpenCensus 已废弃。我们建议使用 OpenTelemetry 来捕获并直观呈现 Spanner 可观测性指标如需了解详情，请参阅使用 OpenTelemetry 检查 Spanner 组件中的延迟时间。

本页面介绍了如何排查 Spanner 组件问题， 延迟时间的原因如需详细了解 Spanner 请求，请参阅 Spanner 请求中的延迟时间点。

1. 在影响您的服务的客户端应用中，确认存在 客户端往返延迟时间导致的延迟时间增加检查以下维度 查看客户端指标

   • 客户端应用名称
   • 客户端位置（例如 Compute Engine 虚拟机可用区）和主机（即虚拟机名称）
   • Spanner API 方法
   • Spanner API 状态

   按这些维度进行分组，看看问题是否仅限于特定客户端、状态或方法。对于双区域或多区域工作负载，请参阅 。

2. 检查客户端应用健康状况，尤其是 例如虚拟机、CPU 或内存等 利用率、连接、文件描述符等）。

3. 检查 Spanner 组件中的延迟时间：

   a. 使用 OpenTelemetry 检查客户端往返延迟时间 或使用 OpenCensus。

   b. 使用 OpenTelemetry 检查 Google Front End (GFE) 延迟时间 或使用 OpenCensus。

   c. 使用 OpenTelemetry 或 使用 OpenCensus 检查 Spanner API 请求延迟时间。

   如果客户端往返延迟时间较长，但 GFE 延迟时间和 Spanner API 请求延迟时间较短，则应用代码可能存在问题。这也可能表示客户端与区域级 GFE 之间存在网络问题。如果您的应用存在导致某些代码路径变慢的性能问题，则每个 API 请求的客户端往返延迟时间可能会增加。客户端计算基础架构中可能还存在上一步未检测到的问题。

4. 请检查以下维度 Spanner 指标：

   • Spanner 数据库名称
   • Spanner API 方法
   • Spanner API 状态

   按这些维度分组，看看问题是否仅限于特定 数据库、状态或方法。对于双区域或多区域工作负载，请检查问题是否仅限于特定区域。

   如果 GFE 延迟时间较长，但 Spanner API 请求延迟时间较短，则可能由以下某种原因所致：

   • 从其他区域访问数据库。此操作可能会导致 GFE 过高 和较短的 Spanner API 请求延迟时间。例如，如果来自 us-east1 区域的客户端的流量在 us-central1 地区具有实例，则 GFE 的延迟时间可能会比较长，但 Spanner API 请求的延迟时间会比较短。

   • GFE 层存在问题。查看 Google Cloud 状态信息中心 看看您所在的区域是否还存在任何网络问题。如果 没有任何问题，然后创建支持请求并提供相关信息 可帮助工程师帮助排查 GFE 问题。

5. 检查实例的 CPU 利用率。如果实例的 CPU 利用率高于建议的水平，您应手动添加更多节点或设置自动扩缩。如需更多信息 请参阅自动扩缩概览。

6. 观察潜在的热点或不平衡的访问模式并进行问题排查 （使用 Key Visualizer） 并尝试回滚与 问题时间范围

   注意 ：我们建议您遵循架构设计最佳实践 确保您的访问在 Spanner 计算中得到平衡 资源。

7. 检查所有流量模式变化。

8. 查看查询数据分析和事务数据分析，了解是否可能存在任何查询或事务性能瓶颈。

9. 使用最早的活跃查询中的步骤 查看任何可能导致性能瓶颈的费用查询， 可以根据需要取消查询

10. 请使用以下主题中排查问题部分中的步骤，使用 Spanner 自省工具进一步排查问题：

    • 查询统计信息
    • 读取统计信息
    • 事务统计信息
    • 锁定统计信息

后续步骤

• 现在您已经确定了包含延迟时间的组件，接下来探索 使用 OpenCensus 进一步解决问题如需了解详情，请参阅使用 OpenTelemetry 检查 Spanner 组件中的延迟时间或使用 OpenCensus 检查 Spanner 组件中的延迟时间。
• 了解如何使用指标诊断延迟时间。
• 了解如何排查 Spanner 截止时间超出错误。