当新遗迹介绍了NRDB2014年，我们从根本上改变了客户与监控数据交互的方式。通过对数据进行实时切片和切割来诊断软件问题是非常强大的。它可以揭示趋势、模式和根本原因，而这些只能通过单一维度、聚合度量来实现。
然后，去年年底FutureStack16，我们预览了一个强大的新功能NRQL警报它允许客户配置警报条件，以获得主动的、接近实时的通知，利用丰富的、维度深度的数据New Relic的见解。(NRQL指New Relic查询语言。)
从那时起，成百上千的客户已经通过它的速度来发送NRQL警报。现在，随着我们接近发布，现在是时候花几分钟来探索这个特性将如何改变您对新Relic数据的操作方式。
最基本的
使用NRQL警报，客户可以使用NRQL编写时间序列查询并对结果发出警报。“时间序列查询”基本上是返回一个数字的任何查询，因此可以使用聚合函数，如count()、average()、percentile()、sum()、min()、max()、stddev()和uniqueCount()。
下面是一个示例查询，用于对响应代码为200的事务的中位数(50%)发出警报:
SELECT * FROM Transaction WHERE appName = 'Storefront' and httpResponseCode = '200'然后，有了NRQL的灵活性，客户可以很容易地(通过添加过滤器)获得更精确的警报信号。例如，添加以下过滤器会显著地改变我们正在查看的数据:
SELECT * FROM Transaction WHERE appName = 'Storefront' and httpResponseCode = '200'and externalCallCount > 0 and transactionType = 'Web'现在，查询只返回web事务的结果，其中包括对外部服务的调用。
真正的操作弹性
当你安装一个新的Relic代理时，你会立即开始收集非常有价值的性能数据，这些数据具有强大的维度，就像上面查询中的属性(httpResponseCode, externalCallCount, transactionType)。然而，客户可以很容易地利用自定义属性的API用业务特别感兴趣的特定领域的维度来修饰数据，例如用户类型、帐户段和标识符。
例如，这里有一个可以添加到任何事务的APM + Java代理代码示例。它允许你过滤和facet你的数据使用重要的维度:
NewRelic。addCustomParameter(“标识”,userId);/ / 1234 NewRelic。addCustomParameter(“userRole”,userRole);//用户名，admin NewRelicaddCustomParameter(“accountType userId);/ /银,金系统或业务kpi
使用NRQL，您可以直接筛选最能代表与您有关的系统、服务或业务kpi的数据，并对其发出警报。这种能力不仅适用于开发人员和操作人员。从事营销工作的New Relic客户已经在监控他们的购物车系统处理的收入流。
下面是一个真实世界的APM + Java代理示例，它将项目总数添加到事务事件中:
NewRelic。addCustomParameter(“itemTotal”,itemTotal);/ / 1234.31只需将itemTotal作为自定义属性添加到其订单服务代码的“WebTransaction/web/orders”事务中，就可以使用New Relic对业务性能进行操作。很不可思议的。
它是如何工作的:举个例子
当你把NRDB、NRQL和New Relic的警报功能结合起来时，你会得到什么?
流媒体查询警报!
让我们看看它是如何工作的。您的第一步是创建一个返回您感兴趣的数字的查询。假设您有一个业务关键型服务昼夜不停地处理事务。您已经将这个应用程序部署在带有10个Java虚拟机的负载均衡器后，想知道在任何时候，持续处理请求的jvm是否少于10个。
首先，让我们编写一个查询来回答最初的问题“现在有多少JVM在服务事务?”我们知道New Relic APM的事务事件类型具有宿主属性。下面的查询每分钟统计创建事务事件的唯一主机。在这种情况下，我知道我的“Storefront”应用程序是由四个应用程序实例服务的，它看起来与我的数据一致:
现在让我们将其移植到NRQL条件。我已经准备好了NRQL，数据预览看起来仍然很好。然后，我只需要设置阈值参数，以便在连续5分钟内少于4个处理事务的应用程序实例时触发。小菜一碟，对吧?
现在，只要有“没有足够的店面实例!”，我就会得到通知。
几乎无限的用例
此时，你可能会问:“好吧，我知道这对于系统或业务操作来说很强大，但我的想象力太糟糕了。你能不能给我一个大大的清单，上面写着我可以做些什么来激励我?”是的，你说对了!
受到数百个New Relic用户(在early access中)已经使用该功能的启发，以下是一些有用的例子:
任意响应时间百分比:使用NRQL查询NRDB中的原始事件数据非常快速和简单。有了原始数据，你就可以根据需要计算任意百分位数，不管是第50个百分位数、第90个百分位数，还是第93个百分位数。
我们已经说过了在过去，“平均值很好，但有时它们不能说明全部情况，因为在一个典型的web应用程序中，异常值会拖高平均值。”下面的示例NRQL查询将为您提供在最后一分钟完成95%的事务所需要的时间。
APM应用服务器事务持续时间:
SELECT * FROM Transaction WHERE appName = 'Storefront' and transactionType = 'Web'浏览器客户端页面视图持续时间:
SELECT percentage (duration, 95) FROM PageView WHERE appName = 'Storefront'合成监测检查数据:从多位置故障到页面加载时间、页面大小等，New Relic人工合成物把大量的数据放到NRDB，都可以查询了。以下是一些查询示例:
监控“店面主页”第95百分位检查时间太长
SELECT * FROM synticcheck WHERE monitorName = '店面主页'监控“店面主页”总页面大小指向未优化资产
SELECT average(totalResponseBodySize) FROM synticcheck WHERE monitorName = 'Storefront Homepage'Monitor“店面结帐页面”有很高的子请求失败百分比
SELECT percentage(count(*)， responseStatus != 'OK') FROM synticrequest WHERE monitorName = '店面结账'监控“店面主页”是失败的加载Javascript文件
SELECT count(*) FROM synticrequest WHERE monitorName = 'Storefront Homepage' and responseStatus != 'OK' and path like '%.js'监视器“店面”有多个未通过检查的位置*
SELECT uniqueCount(location) FROM synticcheck WHERE monitorName = 'Storefront' and result = 'FAILED'*要使用上述查询，客户必须在警报用户界面中设置两个条件选项，将上述查询与“查询结果总和”和更广泛的持续时间(例如15分钟)结合起来。
移动交互:使用New Relic的移动监控你的移动应用的使用趋势可以提示你应用构建的问题以及支持后端服务的问题。这里有一个很好的例子:
没有人在很长一段时间内登录手机应用程序
SELECT count(*) FROM Mobile WHERE name = 'AppName.MobileApp.QuickLogin'浏览器客户端API跟踪:有很多有趣的数据New Relic的浏览器的PageView、PageAction和AjaxRequest事件类型，它们可以告诉你用户的移动或桌面客户端正在发生什么。例如:
页面操作和Ajax请求导致500秒的百分比很高
选择百分比(count (*), actionName not null)从PageAction AjaxRequest appId = 1234和(actionName = AjaxError和httpResponseCode > = 500和httpResponseCode < = 599和requestUrl ' % / api /商务/订单/ %’)或(actionName零和requestUrl ' % / api /商务/订单/ % ')自定义事件类型:我们的一些高级客户大量使用见解插入API。他们正在创建自己的事件类型、事件和属性，这也就是说，NRQL警报的能力实际上是无限的。看看这些有趣的用例:
下面的示例收集完成的电子商务订单的数量。如果它在过去30分钟的正常业务时间内下降到0，则可以推断用户无法下订单，即使您的系统没有报告任何故障。你可以进一步分析，以发现可能只影响特定平台(iOS和Android)的问题。请注意，“MobileMetrics”事件类型是一个自定义类型，用于存储来自移动应用程序的重要电子商务事件。
SELECT uniqueCount(ecommercedes _id) FROM MobileMetrics WHERE order_id IS NOT NULL下面是另一个例子，这次使用自定义事件来节省云存储的费用:
SELECT filter(sum(sent)*0.09/(1024*1024*1024)， WHERE bucket = 'company-downloads') + filter(sum(sent)*0.14/(1024*1024*1024)， WHERE bucket != 'company-downloads')从S3Logs查询这是一个非常极端的例子，但它说明了这个特性是多么开放。假设您构建了一个自定义轮询器，它从Amazon S3 (Simple Storage Service)访问日志，并将其发送到New Relic数据库(NRDB)使用Insights Insert API。该查询将过滤到我们关心的特定S3 bucket，并计算该bucket当前发生的传输成本。这个想法是，当价格上涨超过某个阈值时发送一个webhook，系统可以被通知在其他地方存储/检索数据，以降低成本。很有趣,对吧?
只是一个开始
我们很高兴能将这项新功能交到我们的客户手中。我们迫不及待地想看到我们的客户提出的所有酷炫的新用例。
也就是说，当我们将NRDB与新遗迹警报连接起来时，我们只是触及了可能性的表面。对于想象力受损的人，Nadya杜克布恩更多的解释在她的帖子介绍New Relic的动态基线警报。
