TraceView 团队一直忙于与我们的用户打交道，尤其是负责确保他们的应用程序能够处理流量波动的运营中的用户。我们很高兴地宣布，除了 最近的 UI 更新 之外，我们还推出了一个图表，显示对您的应用程序的请求总数。更新仪器后，您会看到它出现在主应用程序服务器页面上的延迟图表下方。
此图表标记了新公开的总请求数，可帮助您了解您的应用程序如何受到流量增加的影响。这使您可以轻松地将应用程序中的任何延迟与流量高峰相关联，还可以识别在负载下恶化的任何资源。
设置步骤
- 新用户：放心，没有工作要做！您将自动使用新工具进行设置。
- 现有用户：从 TraceView 中的设置（齿轮图标）> 检测菜单项升级您的检测，然后重新启动构成应用程序的服务。
更新 ：使用所有受支持语言的用户现在可以使用更新的工具来查看总请求数。
任何包含新请求计数的时间段都将开始在几个地方显示数据，详情如下。
概览页面
对于具有请求计数的应用程序，总请求数将代替总览页面上的调用量显示。
分层分解
在每个应用程序的层细分图表下方，用户现在将在每个应用程序的调用量上方看到总请求数（完成设置步骤后）。请注意，将数据过滤到特定层将隐藏此图表，因为总请求数是在应用程序级别计算的。
热图
与 Layer Breakdown 类似，未过滤的结果将在热图下方显示总请求数和收集的跟踪数。
采样
我想讨论一个必然会出现的问题，即总请求数和收集到的跟踪数并列。为了将开销保持在最低限度， TraceView 对您的数据进行采样 。为了解释，最好更深入地了解我们的检测代理的工作方式。我们的语言代理通过随机抽样进入系统的请求来报告数据。
大多数监控工具以不同方式报告数据：查看每个请求并每分钟发送一组统计数据和大约 10 个有趣的跟踪。要获得那些“有趣的跟踪”，需要实时决定要在系统上跟踪什么，这会导致开销增加和可审查数据的减少。
TraceView 的目标是跟踪总请求的统计代表性部分，这通常意味着在相同的一分钟时间段内接近 1,000 条跟踪。此外，TraceView 可以更快地将此数据流式传输到报告仪表板，因为我们不必等待每分钟的采样决策。
对于高吞吐量应用程序或那些具有高请求数的应用程序， TraceView 的模型可扩展以提供数千个请求，同时保持低于 1% 的开销。
我们希望新图表可以帮助您更快地识别在高流量下挣扎的任何资源。如果您有任何反馈意见，我们很乐意听取 - 您可以发送电子邮件至 feedback@appneta.com 、 发送推文至@AppNeta 或在下方发表评论！