阶段组的可观测性
可观测性是指为系统带来可见性，以便在上下文中查看和理解每个组件的状态，以支持性能调优和调试。要大规模运行 SaaS 平台，需要一个丰富且详细的可观测性平台。
为了向阶段组提供信息，我们按功能类别聚合指标，然后在为这些组定制的仪表板上显示这些信息。只有该组构建的功能的指标才会在其仪表板上可见。
通过过滤视图，组可以发现在使用聚合数据时可能被忽略的错误和性能回归。
有关仪表板的更具体信息，请参见：
错误预算
错误预算是根据我们用于监控 GitLab.com 的相同服务级别指标（SLIs）计算的。阶段组的 28 天可用性数字与我们为 GitLab.com 计算的月度可用性相当，只是它限定在该组的功能范围内。
有关我们如何使用错误预算的更多信息，请参阅工程错误预算手册页面。
默认情况下，两个仪表板的面板第一行都显示阶段组的错误预算。这一行显示了该组拥有的功能如何影响我们的整体可用性。
官方预算是 28 天的聚合值。您可以在阶段组仪表板上看到它。错误预算详情仪表板允许自定义时间范围。
我们以两种格式显示信息：
- 可用性：这个数字可以与 GitLab.com 整体 99.95% 的正常运行时间目标进行比较。
- 已用预算：过去 28 天内，该组拥有的功能表现不佳的时间。
预算基于每个组件的指标计算。每个组件可以有两个指标：
-
Apdex：表现良好的操作比率。
“表现良好"的阈值存储在我们的指标目录中，并取决于相关服务。对于API、Git和Web服务的 Puma (Rails) 组件，当未选择加入
rails_requestSLI时，该阈值为5秒。我们已在此项目中使此目标可配置。要自定义请求 Apdex，请参阅Rails 请求 SLIs。在您选择加入之前，这个新的 Apdex 测量值不属于错误预算的一部分。
对于 Sidekiq 作业执行，阈值取决于作业紧急程度。目前，高紧急程度作业为10秒，其他作业为5分钟。
某些阶段组可能有更多服务。它们的阈值也在指标目录中。
-
错误率：出现错误的操作比率。
比率的计算如下：
检查预算的使用情况
阶段组仪表板和错误预算详情仪表板都显示面板，用于查看错误预算的使用情况。阶段组仪表板始终显示固定的 28 天。错误预算详情仪表板允许按时间深入查看 SLI。
错误预算行下方的行默认是折叠的。展开它会显示在过去 28 天中，哪个组件和违规类型有最多的违规操作。
左侧的第一个面板显示一个表格，列出了每个组件的错误数量。深入该表格的第一行对已用预算的影响最大。
通常，消耗大部分预算的组件是 Sidekiq 或 Puma。中间的面板解释了不同违规类型的含义以及如何在日志中深入挖掘。
右侧的面板提供了指向 Kibana 的链接，应该可以揭示是哪些端点或 Sidekiq 作业导致了错误。
要学习如何使用这些面板和日志来确定哪些 Rails 端点响应缓慢，请观看购买组错误预算归因视频。
表格中可见的其他组件来自指标目录中定义的服务级别指标（SLIs）。
对于这些类型的故障，您可以跟随链接到从type列链接的服务仪表板。服务仪表板包含一行专门用于导致预算使用的 SLI，并带有日志链接和对组件含义的描述。
例如，查看 web-pages 服务的 server 组件：
要添加针对特定功能的更多 SLI，您可以使用应用程序 SLI。
错误预算的 Kibana 仪表板
要进行详细分析，您可以使用专门的 Kibana 仪表板，如下所示：
描述：
- 超出限制的 Apdex 请求（图表） - 仅显示超过其目标持续时间的请求。
- 超出限制的 Apdex 操作持续时间（图表） - 显示持续时间组件（数据库、Redis、Gitaly 和 Rails 应用）的分布。
- Apdex 请求（饼图） - 显示
2xx、3xx、4xx和5xx请求的百分比。 - 慢请求组件分布 - 突出显示负责 Apdex 违规的组件。
- 超出限制的 Apdex 操作（表格） - 显示每个端点超出限制的操作数量。
- 超出限制的 Apdex 请求 - 显示导致 Apdex 违规的个别请求列表。
使用仪表板
- 选择您要调查的功能类别。
- 滚动到功能类别部分。输入功能名称。
- 选择应用更改。选定的结果仅包含与此功能类别相关的请求。
- 选择调查的时间范围。
- 查看仪表板并注意故障类型。
需要回答的问题：
- 故障模式看起来像是峰值吗？还是持续存在？
- 故障是否与特定组件相关？（数据库、Redis 等）
- 故障是否影响特定端点？还是系统范围的？
- 故障是否似乎是由基础设施事件引起的？
GitLab 的 OpenTelemetry 仪器化
我们正在努力为 GitLab 代码库进行 OpenTelemetry 仪器化。
有关此努力的更具体信息，请参阅GitLab 的 OpenTelemetry 仪器化。