随着微服务环境在规模和复杂性上的不断增长，它们给致力于监控系统健康和行为的DevOps团队带来了更大的挑战。New Relic最近宣布了一个新功能的普遍可用性，以解决这一挑战:分布式跟踪异常检测．
异常检测自动曲面迹象的异常部分，这允许客户直接在延迟源上找到和焦点。它是一系列新的遗物版本，其中致力于分布追踪改进，包括浓缩的跟踪视图，部署标记和跟踪组 - 所有这些都可以帮助Devops团队更快地了解和解决微通术环境。
使用跟踪数据解决性能瓶颈的挑战
分布式跟踪帮助您了解请求如何流过MicroServices环境。这种能力使得分布式跟踪用于查找这些环境中的延迟和错误的源。通过跟踪从一个服务到另一个服务的请求，以及每次服务中的重要操作的持续时间，您可以完成影响分布式系统内请求的任何性能问题或瓶颈的完整图片。
然而，通过挖掘所有这些跟踪数据来找到可行的见解可能是耗时的——需要您过滤到能够真正帮助您发现问题的相关跟踪。随着分布式系统的不断扩展和变得越来越复杂，寻找相关跟踪和跨越解决性能问题的难度会越来越大。
此外，即使找到了相关的跟踪，通常也很难理解跟踪的流程—而且可能无法判断跟踪中的特定跨度是否正常执行。更糟糕的是，许多分布式跟踪解决方案只提供高级的、服务到服务的细节。亚博直播平台这些解决方案亚博直播平台未能深入到指示服务内部实际发生的细节——当性能问题的根源在于服务本身时，这些高度具体的进程内细节正是开发人员需要看到的。
突出应用智能的性能瓶颈
新的遗物引入了异常检测，以便在跟踪中自动突出显示异常缓慢的跨度，从而更容易找到并专注于这些异常延迟来源。新文物应用智能-A包括人工智能，机器学习和高级统计分析的一套服务 - 通过在最大的异常检测数据集中进行连接和揭示可操作的洞察，在这种能力中起着关键作用。
当New Relic查看一个轨迹时，它使用异常检测将该轨迹的跨度与其他类似轨迹的跨度进行比较。然后根据这个比较分析，突出显示延迟时间比正常时间长的跨度。对于每个异常跨度，New Relic都会显示一个摘要，说明它为什么将跨度标记为异常。New Relic还创建了直方图，显示了类似跨度的持续时间分布;这些数据还显示了在过去6个小时内，该卫星的异常跨度与其他卫星相比如何。后一种功能对于理解特定跨度代表的离群值有多少特别有用。
这些功能还帮助Teams在微服务环境中，他们经常看出涉及自己服务的痕迹，但它们也可能看看涉及他们自己不拥有的服务的痕迹，并不深入了解。对于这些团队来说，通常很难理解痕迹中的“正常”。随着新的遗物的异常检测，这些团队现在在给定的情况下获得了一个快速而高度准确的对正常情况，而不是什么是不寻常的，需要注意。
使用改进的跟踪导航和上下文更快地识别根本原因
我们还发布了一些改进，使使用跟踪数据更容易查明潜在问题。
跟踪分组:重现问题通常需要识别模式:源自特定服务的跟踪是否比其他服务慢?某个特定的入口跨度比其他的慢还是快?错误是否集中在一个特定的时间段内?跟踪分组允许您根据错误、根服务、根条目跨度和服务条目跨度组织跟踪，为您提供更多方法来锁定与您试图解决的问题相关的跟踪。
部署标记:部署和其他更改通常会导致性能问题。在这些情况下，将跟踪行为的差异与特定部署相关联到上游或下游服务，允许您更快地识别违规服务。嵌入式部署标记提供了这种上下文，作为跟踪散点图的一部分 - 使得识别来自上游和下游的潜在影响的过程更加简单。
浓缩跟踪视图:复杂的微服务环境需要同时兼顾两个方面的监控:高级系统概述的简单性和清晰性，以及让用户深入到特定的事务和流程中进行故障排除。我们的更新和浓缩的跟踪视图满足这两个要求。它从一个高层视图开始，该视图使人们更容易理解给定请求的流程。但是，从那里，您可以扩展不同的范围，以查看特定服务中的细节;您还可以深入到进程内操作，这些操作精确地显示了在服务中执行内部方法调用和函数等任务所需的时间。深入研究这些进程内跨度可以更容易地发现潜在的延迟和错误源，比如Java应用程序中的servlet过滤器。
自定义仪表板和针对特定服务和范围的警报
新的遗物客户在实现时自动获得策划，外包追踪体验新的Relic APM语言代理。同时，底层跟踪数据也可以在New Relic的见解——所有跨度和事务事件可用于自定义仪表板。用户可以创建见解仪表板使用强大的NRQL查询，完全自定义为自己的团队和系统。这些查询还为用户提供创建的选项针对NRQL警报可以立即通知团队服务中的错误或性能问题。
查看复杂环境中的故障排除问题
在我们对这些新功能的早期访问测试中，我们发现团队在他们的环境中挖掘有趣的问题。例如，一个客户在他们的一个分布式缓存服务中确定了一个周期性的重建——这是一个非常昂贵的问题，也导致了重建期间请求的显著减速。在这种情况下，客户通过将减速期间跟踪到的信息关联起来，迅速识别出问题。
我们还发现了一个有趣的例子，在一个不熟悉的系统上跟踪，持续时间为65秒——这个持续时间似乎表明性能异常缓慢。正常情况下，我们可能会认为这个痕迹确实是异常的，我们很惊讶异常检测没有标记它。实际上，跟踪涉及的是一个每小时运行两次的作业，并且始终需要大约65秒的时间——对于它正在执行的作业来说，这是完全正常的性能配置文件。
由于我们还使用新的遗物来监控我们自己的生产系统，我们已经通过客户并脱颖而出。我们发现的一个有趣问题涉及使用异常检测的新的遗物团队成员，以便在一组迹线中审查缓慢的跨度。一种模式开始出现 - 涉及一系列始终如一地具有相同数量的跨度和持续时间的请求。通过“服务入口跨度”分组迹线后，团队成员发现，请求始终称为同一API，并始终遇到相同的问题：aClassic N + 1查询问题与旧版的REST API．
另外，自从我们加入自定义属性对于这些跨度来说，我们可以看到这些请求起源于特定的新遗物客户。我们与客户合作，采用并集成更新，更加表现的版本这些api．发现这样一个模式实际上是一种很棒的感觉，否则它可能一直隐藏在我们运行的数百个微服务中，并允许我们为客户改进New Relic体验!
为分布式系统构建更好的可观察性
自从我们以来以来原始版本分布式追踪，我们继续为在微服务环境中工作的客户构建更有用和直观的体验。我们是否能够更好地了解组织的服务拓扑地图服务，或允许客户使用我们最新的分布式跟踪版本深入他们的服务，或以任何其他方式提供创新，我们继续投资，使DevOps团队更容易发现和解决应用程序性能问题。
要了解关于New Relic分布式跟踪的更多信息，请查看New Relic文档中的这些资源:
如果您还没有启用分布式跟踪，请立即执行此操作！我们会告诉你如何在这里．
本博客所表达的观点是作者个人的观点，并不一定代表New Relic的观点。作者提供亚博直播平台的任何解决方案都是特定于环境的，不属于New Relic提供的商业解决方案或支持的一部分。请在探索者中心(discuss.newrelic.com)的问题和支持相关的博客文章。本博客可能包含到第三方网站内容的链接。通过提供此类链接，New Relic并不采用、保证、批准或认可此类网站上可用的信息、观点或产品。亚博最新版直播
