Sentry Web 性能监控 - Metrics

简介: Sentry Web 性能监控 - Metrics

Apdex



Apdex 是一种行业标准指标,用于根据您的应用程序响应时间(response time)跟踪和衡量用户满意度(satisfaction)。Apdex 分数提供特定 transaction 或端点中满意(satisfactory)、可容忍(tolerable)和失败(frustrated)请求的比率。该指标为您提供了一个标准来比较 transaction 性能,了解哪些可能需要额外优化或调查,并为性能设定目标。


以下是 Apdex 的组成部分及其公式:


  • T:目标响应时间的阈值。
  • Satisfactory(满意度):当页面加载时间小于或等于 T 时,用户对使用该应用感到满意。
  • Tolerable(可容忍度):当页面加载时间在 T4T 之间时,用户认为该应用程序可以容忍使用。
  • Frustrated(失败):当用户的页面加载时间大于 4T 时,他们对应用程序感到失望。
  • Apdex:(满意请求数 +(可容忍请求数/2))/(总请求数)

Settings > Performance 中为 Apdex 配置令人满意的响应时间阈值 (ms)。您可以使用自定义阈值为每个项目设置此项。


失败率



failure_rate() 表示不成功 transaction 的百分比。Sentry 将状态为 “ok”“canceled”“unknown” 以外的 transaction 视为失败。有关更多详细信息,请参阅可能的状态值列表。


吞吐量 (Total, TPM, TPS)



吞吐量表示给定时间范围内的事务数 (Total)、平均每分钟事务数 (TPM) 或每秒平均事务数 (TPS)。


延迟



平均事务持续时间


平均事务持续时间表示给定事务的所有出现的平均响应时间。

以下函数用于聚合事务(aggregate transaction)持续时间:

  • average
  • various percentiles(默认情况下,预构建的 Transactions 查询显示第 75 个和第 95 个百分位数,但还有许多其他选项,包括自定义百分位数)
  • maximum

跟踪这些统计数据的一个用例是帮助您识别比组织的目标服务级别协议 (SLA) 慢的事务。


查看平均值和百分位数时要注意一点:在大多数情况下,您需要设置跟踪,以便仅将可能的跟踪的一小部分实际发送到 Sentry,以避免使您的系统不堪重负。此外,您可能希望按日期或其他因素过滤您的 transaction 数据,或者您可能正在跟踪一个相对不常见的操作。由于所有这些原因,您最终可能会得到方向正确但不准确的平均值和百分位数据。(以最极端的情况为例,如果只有单个事务与您的过滤器匹配,您仍然可以计算“平均(average)”持续时间,即使这显然不是“平均(average)”通常的意思。)

对于某些指标,样本量小(以及由此导致的无法有效准确)的问题会比其他指标更频繁地发生,并且样本量也会因行而异。例如,计算有意义的平均值所需的数据少于计算同样有意义的第 95 个百分位数所需的数据。此外,代表对 /settings/my-awesome-org/ 的请求的一行可能包含的事务数量是代表对 /settings/my-awesome-org/projects/best-project-ever/ 的请求的事务的数倍。


P50 阈值


P50 阈值表示 50% 的事务持续时间大于阈值。这也是中位数。例如,如果 P50 阈值设置为 10 毫秒,则 50% 的事务超过该阈值,耗时超过 10 毫秒。


P75 阈值


P75 阈值表示 25% 的事务持续时间大于阈值。例如,如果 P75 阈值设置为 10 毫秒,则 25% 的事务超过该阈值,耗时超过 10 毫秒。


P95 阈值


P95 阈值表示 5% 的事务持续时间大于阈值。例如,如果 P95 阈值为 50 毫秒,则 5% 的事务超过该阈值,耗时超过 50 毫秒。


P99 阈值


P99 阈值表示 1% 的事务持续时间大于阈值。例如,如果 P99 阈值为 5 秒,则 1% 的事务超过该阈值,耗时超过 5 秒。


频率


以下函数汇总 transaction 计数和 transaction 记录速率:


  • count
  • count unique values (对于给定字段)
  • average requests (事务) per second
  • average requests (事务) per minute


这些函数中的每一个都是根据给定行中的事务集合计算的,这意味着数字会随着您过滤数据或更改时间窗口而发生变化。此外,如果您已设置 SDK 来对数据进行采样,请记住,只有发送到 Sentry 的事务才会被计算在内。因此,如果包含代表对给定端点的请求的事务的行计算为每秒接收 5 个请求,并且您启用了 25% 的采样率,则实际上您每秒收到大约 20 个请求到该端点。(20 因为您收集了 25% - 或 1/4 - 的数据,所以您的实际数量是您在 Sentry 中看到的数量的 4 倍。)


User Misery


User Misery 是一个用户加权的性能指标,用于评估应用程序性能的相对大小。虽然您可以使用 Apdex 检查各种响应时间阈值级别的比率,但 User Misery 会根据满意响应时间阈值 (ms) 的四倍计算感到失望的唯一用户数。User Misery 突出显示对用户影响最大的事务。


您可以使用自定义阈值为每个项目设置令人满意的阈值。


自定义阈值



对于每个项目,您可以在 [Project] > Settings > Performance 中配置 ApdexUser Misery 的计算方式。您可以在 Transaction Summary > Settings 中覆盖事务级别(transaction level )的项目级别设置。


计算方法确定持续时间是定义为事务的整个长度还是定义为特定的 Web Vital,例如 LCP。响应时间阈值确定令人满意的基线持续时间是多少毫秒。此阈值可能因项目而异,具体取决于项目面向用户的方式。

相关文章
|
7月前
|
Arthas 监控 NoSQL
web服务性能监控方案
web服务性能监控方案
|
7月前
|
存储 监控 Java
【深度挖掘Java性能调优】「底层技术原理体系」深入探索Java服务器性能监控Metrics框架的实现原理分析(Counter篇)
【深度挖掘Java性能调优】「底层技术原理体系」深入探索Java服务器性能监控Metrics框架的实现原理分析(Counter篇)
172 0
|
SQL 缓存 监控
MyCat - 高级 - MyCat-Web 性能监控 | 学习笔记
快速学习 MyCat - 高级 - MyCat-Web 性能监控
MyCat - 高级 - MyCat-Web 性能监控 | 学习笔记
|
7月前
|
监控 算法 Java
【深度挖掘Java性能调优】「底层技术原理体系」深入探索Java服务器性能监控Metrics框架的实现原理分析(Gauge和Histogram篇)
【深度挖掘Java性能调优】「底层技术原理体系」深入探索Java服务器性能监控Metrics框架的实现原理分析(Gauge和Histogram篇)
98 0
|
6月前
|
运维 监控 Java
性能监控之 Java Metrics 度量包
【6月更文挑战10天】标题性能监控之 Java Metrics 度量包
145 2
|
存储 缓存 监控
Sentry Web 前端监控 - 最佳实践(官方教程)
Sentry Web 前端监控 - 最佳实践(官方教程)
1230 0
Sentry Web 前端监控 - 最佳实践(官方教程)
|
JSON API 数据安全/隐私保护
Sentry 开发者贡献指南 - Web API
Sentry 开发者贡献指南 - Web API
408 0
Sentry 开发者贡献指南 - Web API
|
存储 监控 JavaScript
Sentry 开发者贡献指南 - SDK 开发(性能监控)
Sentry 开发者贡献指南 - SDK 开发(性能监控)
949 0
|
监控
Sentry Web 性能监控 - Trends
Sentry Web 性能监控 - Trends
224 0
|
2月前
|
XML JSON API
ServiceStack:不仅仅是一个高性能Web API和微服务框架,更是一站式解决方案——深入解析其多协议支持及简便开发流程,带您体验前所未有的.NET开发效率革命
【10月更文挑战第9天】ServiceStack 是一个高性能的 Web API 和微服务框架,支持 JSON、XML、CSV 等多种数据格式。它简化了 .NET 应用的开发流程,提供了直观的 RESTful 服务构建方式。ServiceStack 支持高并发请求和复杂业务逻辑,安装简单,通过 NuGet 包管理器即可快速集成。示例代码展示了如何创建一个返回当前日期的简单服务,包括定义请求和响应 DTO、实现服务逻辑、配置路由和宿主。ServiceStack 还支持 WebSocket、SignalR 等实时通信协议,具备自动验证、自动过滤器等丰富功能,适合快速搭建高性能、可扩展的服务端应用。
158 3
下一篇
DataWorks