前言
New Relic 是美国的一家软件服务供应商公司，2008年 38岁的 Lew Cirne创建了该公司。该公司提供了一套集成的可观测性平台，平台允许用户对部署在云中心或在数据中心的 NET, Java, JavaScript, Node.js, PHP, Python, and Ruby 、基础设施、端等进行运维监控。 通过该平台开发人员和运营团队监控用来故障排除和优化他们的应用程序。
Lew Cirne
NewRelic 发展几个重要里程碑：
2008年 Lew Cirne 创立NewRlic公司
2010年 APM产品被CA Technologies 以3.75亿美金收购
2014年 12月12日 以NEWR作为股票代号在纽交所上市
2015年 宣布拥有 1万家客户，其中包括Runkeeper，Tableau， Nike，Gawker Media， ESPN，Sony，Comcast，E*Trade，eHarmony，GitHub，Groupon，Zumba 等 营收超
2016年 Gartner 评为APM市场的领导者
2020年 营收达到6.36亿美元
目前公司2000多人
随着可观测赛道的玩家越来越多，更多的如DataDog Dynatrace 的竞争，NewRelic的营收增长目前也面临着很大的压力
平台能力概览
New Relic One 是newRelic 的一个全栈监控的平台。他可以将你所有的场景资产监控数据聚集到一个平台来进行分析洞察。
全栈监控
- 应用程序监控
- 基础设施监控
- k8s 监控
- 日志管理
- 网络监控
- 浏览器监控
- 移动端监控
- 链路监控
- serverless 监控
- 机器学习模型性能监控
可观测性体验
- IDE集成调试、工作流
- 错误跟踪
- 数据探索
- AIOps
数据采集和洞察
- 数据接入
- 仪表盘
- 告警
- OpenTelemetry
部分功能介绍
本文将主要围绕 NewRelic的 浏览器监控、告警功能、自定义App进行详细描述。
1. Browser Monitor
浏览器监控是大部分可观测性产品必备的功能之一。通过接入浏览器监控探针，用户可以对产品浏览器端的数据进行监控。监控包含页面响应性能指标、页面js异常数据、页面请求数据、静态资源加载数据、客户端信息、geo信息等进行采集和监控。通过这些数据，用户可以对自己关切的业务界面进行即使的故障处理以及界面优化。
1.1 接入方式
newRelic 提供了两种浏览器监控的接入方式
- 探针模式
探针模式是使用最多的一种接入场景。随着SPA应用的普及，只要在单一入口页面埋入探针（上图中的探针js代码），即可完成探针的接入。
- APM模式
服务端安装脚本，自动分发探针到html页面。
比较适合多页面的场景。第一种探针模式需要手动为每个页面添加，比较麻烦。apm模式只需要在web服务层的代码上加入apm client，即可完成自动分发。
当然也有一些限制。比如静态页面走cdn场景或者web服务层语言框架本身不支持的一些场景。
以go 语言的一个web服务为例。只需要在服务侧对http路由进行newrelic的包裹函数即可完成配置
和传统的浏览器监控应用一样，newRelic 也提供了常规的一些功能
1.2 报表统计 
1.3 自定义api
提供自定义上报用户信息，如uid标示，其他业务关联信息等 如API：setCustomAttribute
提供了各种钩子函数，提供不同的时间机制进行数据的上报或者其他控制
1.4 数据聚合
对路径相同，参数不同的数据进行聚合。提供了模式匹配
1.5 度量规范配置
对同类的异常指标进行更好的分组。避免分组多散导致基数过高，服务性能会受到影响
1.6 上报范围管控
newRelic提供了三种模式。 Lite模式，只上报页面加载的一些性能数据 Pro模式，上报所有的页面信息 Pro+SPA模式，上面所有页面信息以及单页应用路由的一些信息和一些span的链路追踪
1.7 黑白名单配置等
提供了host的黑白名单配置，所在国家地区的黑白名单配置
1.8 trace
通过在头部设置sessionID 和 span的一内容来关联上下游链路
2. Alerts&&AI
数据洞察是数据采集后的重要一环。也是数据真正价值的体现之一。而告警正是数据洞察的一个重要形式之一。
在newRelic的告警体系里。包含：事件系统、决策系统、通知系统、开放告警、工作流、AI等
2.1 整体架构：
2.2 工作步骤：
- NewRelic 提供了自定义告警 Policy 和 预制内置告警（pre-built） Policy。以及异常巡检（Anomaly detection） Policy。
- 系统按照 Policy设置的定时活着其他策略去扫描数据，按照不同的条件。产生异常事件。异常事件也可以开放api对接其他告警系统的事件。
- 异常事件进入事件系统后，会转交到决策系统Decisions。决策系统会自动合并同类事件。关联相关资源（比如其他的告警事件，巡检事件等）。NewRelic 还集成了一些内置的黄金指标的AI模型供用户进行打标。用户可以在incident里对此次资源关联进行打标，模型会自动优化。 newRelic提供了默认的决策逻辑，当然也提供了一些自定义的决策逻辑。供用户来按照一些属性对不同的事件关联。decision设置的越好，告警的降噪关联效果也会越好。
- 决策系统最终会将多个事件 按照决策规则聚合成Incident，以及将多个incident生成工作流中issues，供工作流中的值班人员全局查看评估。
- NewRelic告警里有一个全局配置的静默策略（Muting rule）。静默策略可以设置全局匹配的属性条件。当incident 符合静默策略的条件。将进行静默操作
- 如果一个incident不在静默策略范围中，将继续向上进入通知渠道。通知到Policy里设置的渠道，例如邮件、slack、pageDuty、webhook，同一个NR账号体系下的users等。
- newRelic 的issue是决策系统将 incident聚合后产生的一个问题。用户可以在界面上通过issue 查看所有incident以及incent的关联逻辑。还以通过工作流对issue进行定期的汇总和通知到工作流平台中。比如webhook 、jira，slack，等 Issue 面板包含了聚合的incident信息的展示，通知渠道的展示，source的展示，Root cause 的分析，以及issue time-line的信息
- 用户可以对告警Policy设置RunBook。RunBook 可以在告警触发的时候提供可执行回调进行自动化的问题处理逻辑。或者提供处理该类问题的文档链接，供运维人员进行查看，提高效率
3. 自定义APP
在newRelic里提供了一个自定义app的UI定制功能。传统的运维产品模式下，用户只能依赖平台提供的可视化仪表盘来构建一些大盘视图。对于定制化要求高的客户来说，如何打通自己需求以及平台限制显得特别重要。往往大客户都有自建的统一风格的运维平台，可观测性产品对于大客户来说更多的是运维平台的一环。他们不希望通过多个不一样的界面来完成运维。
newRelic里提供了一个cli工具，让用户可以像编写小程序一样，自定义自己的应用。平台提供了cli工具搭建应用框架，sdk调用平台开放数据。component 提供平台对外暴露的一些组件。用户通过这些组合自由定制自己场景需要的视图。自定义app提供了远程调试，发布，上传等功能。
newRelic还提供了一个类似app中心的生态，你可以安装别人开放的app到你的应用下。
3.1 自定义app的开发流程：
1.Cli工具安装
2.编写代码
3.调试（在线/本地）
4.发布app
自定义APP基于react框架编写，客户需要做的就是完整render函数组件的定制开发 编写react 组件：
通过nr提供的ui组件和数据组件进行开发：
界面效果：
更多的开发细节可以参考官方文档进行探索。
最后
正如第二章节提到，newRelic还有很多有意思的功能，后续会继续探索。newRelic 提供了一个免费的100G/月的版本使用。当然会有一些功能限制。因为newRelic的数据中心主要是在国外。国内使用部分功能会有异常，包括ui的加载延迟也会比较高。在阿里云日志服务产品中，目前也集成了 RUM功能模块，以及功能丰富的 告警功能 感兴趣可以使用。
