Node.js 性能平台运行时与社区 Node.js 运行时是什么关系
Node.js 性能平台运行时完全兼容社区对应版本 Node.js 运行时，对应关系 请查看。
Node.js 性能平台运行时是否会影响性能
Node.js 性能平台运行时每分钟在主线程将监控数据写到内存中，通过额外的日志线程写日志到文件，因此对性能影响可以忽略。
做故障诊断时，执行诊断功能 3 分钟，随后自动切回到正常运行状态。
Node.js 性能平台运行时提供了哪些额外的功能
Node.js 虚拟机 V8 的运行时内存状态监控；
libuv 运行时状态监控；
在线故障诊断功能：堆快照、CPU Profile、GC Trace 等。
部署 Node.js 性能平台运行时后控制台显示实例数为 0
step 1 查看 agenthub 是否启动成功，通过如下命令查看是否有 agenthub 实例运行。
u@h:~$ agenthub list |- App ID -|- PID -|---- Start Time -----|--- Config Path ------------------------------------| | 12345 | 29015 | 2018-07-11 16:53:44 | /path/to/your/config.json | |----------|-------|---------------------|----------------------------------------------------| u@h:~$如果没有运行中的 agenthub，可以通过 DEBUG 方式启动 agenthub 后查看 ~/.agenthub.log 日志查看具体出错信息。
DEBUG=* agenthub start config.json cat ~/.agenthub.logstep 2 查看 agenthub 的配置，通过
实例页面上的查看运行中的Node.js进程后点击检查进程。
诊断操作提示失败
所有诊断操作需要顺序执行。一个操作未完成时进行下一个操作会提示操作失败。文件页面转储按钮有效时表明操作已完成（诊断报告数秒可完成，堆快照根据堆大小可能数秒到数分钟，其他操作持续时间为 3 分钟）。
agenthub 异常退出
通过 agenthub start config.json 启动 agenthub 后，agenthub list 无法获得 agenthub 实例。那么通过 DEBUG 方式启动agenthub
DEBUG=* agenthub start config.json然后查看 ~/.agenthub.log 获取出错信息。
修复错误后，重新普通方式启动agenthub。
agenthub stop all # 停止 agenthub
agenthub start config.json如何处理一台服务器部署多个应用
强烈建议每台服务器部署一种应用。
如果必须要在同一台服务器部署多个应用，下面提供了两种方法来实现：
每个应用申请不同的 和
App Secret，用NODE_LOG_DIR指定不同的路径存放运行时日志，并且与config.json里面logdir路径一致。这样可以启动多个 agenthub。启动一个 agenthub，所有应用的运行时日志指向相同目录（默认
/tmp），error_log和packages可以放到配置文件的数组里面。
请使用其中一种方式来进行部署。
使用 pm2 管理的应用如何使用 Node.js 性能平台运行时
如果安装 Node.js 性能平台运行时前系统已经安装社区 Node.js 运行时和 pm2 ：
安装 Node.js 性能平台运行时后重新安装 pm2，确保
which pm2结果中包含.tnvm字段；将 pm2 所有进程杀掉，尤其是其守护进程
PM2 v0.15.8: God Daemon不能漏掉；重新用 pm2 启动应用。
$ ENABLE_NODE_LOG=YES pm2 start app.js
如果安装 Node.js 性能平台运行时前系统未安装社区 Node.js 运行时和 pm2 ：
安装 pm2 后直接使用 pm2 启动应用
$ ENABLE_NODE_LOG=YES pm2 start app.js
控制台只有系统监控数据，没有进程监控数据
通过实例页面上的 查看运行中的Node.js进程 后点击 检查进程进行排查。
多个实例的 hostname 相同如何处理
在配置文件中添加配置项 "agentidMode": "IP"。
例如有两个实例的 hostname 都是 app_container，IP 分别是 10.10.12.124 和 10.10.12.123，如果配置中增加 "agentidMode": "IP"，那么两个实例ID分别是 app_container_12124 和 app_container_12123。细节请参考。
慢 HTTP 日志是什么
响应时间 (RT) 大于 400ms 的 HTTP 请求。
异常日志是什么
在
config.json里面中配置的error_log所指定的日志文件中带error stack的日志，该日志由用户应用生成。
模块依赖是什么
在
config.json里面中配置的packages所指定的 npm 模块，用红色提示存在安全风险的模块。
系统监控数据各项指标什么含义
基本信息
最近一次日志上报的各项指标，具体指标含义如下所述。
长周期数据
Memory
memory_sys：系统内存使用百分比。memory_node： 所有 Node.js 进程内存使用之和占系统内存的百分比。
CPU
cpu_sys：系统 CPU 使用百分比。cpu_node：所有 Node.js 进程 CPU 使用百分比之和。
Load
load1：1分钟内平均 Load。load5：5分钟内平均 Load。load15：15分钟内平均 Load。下面是一些
Load的参考信息 (Load已经归一化处理，如果是 N 核 CPU，那么相应Load * N)：0.7 < Load < 1：不错的状态，有新任务也可以及时处理；Load = 1：即将有任务需要额外的等待时间才能被处理，需要引起关注；Load > 5：任务需要等待时间很长，需要干预处理。通常先看
load15，如果很高，再看load1和load5，看是否有下降趋势，短时间内load1大于 1，不用担心，如果长时间Load较高，需要引起关注。
QPS
该实例所有 Node.js 进程每秒钟处理的 HTTP 请求数之和。
GC
gc_avg：所有 Node.js 进程垃圾回收时间占比平均值。gc_max：每分钟内垃圾回收时间最多的 Node.js 进程的垃圾回收时间占比。
Apdex
Node.js 性能平台根据 HTTP 的响应时间 RT 来定义用户满意度（默认响应时间 100ms）：
satisfied（满意）：RT <= Ttolerating（容忍）：T < RT < 4 * Tfrustrated（失望）：RT > 4 * T计算方式：
satisfied + tolerating / 2举例来说：
每分钟
satisfied的HTTP请求为60%，tolerating的为30%，frustrated的为10%那么
Apdex = 0.6 + 0.3 / 2 = 0.75
Apdex detail
如上面描述的，根据响应时间分类的 HTTP 请求详细统计。
node进程数
该实例内的 Node.js 进程数统计。
磁盘
该实例的磁盘使用率。
进程监控数据各项指标什么含义
堆整体信息
rss：该进程实际使用的内存，包括堆内内存和堆外内存。heap_total：总的堆内存。heap_used：实际使用的堆内存。
GC 信息
scavange_duration：scavange垃圾回收时间占比。marksweep_duration：marksweep垃圾回收时间占比。
堆空间组成
堆上各个内存空间 code_space，lo_space，map_space，new_space，old_space上的内存大小。
QPS 趋势
该进程每秒钟处理的 HTTP 请求数。
CPU 趋势
该进程在各个统计时段内的 CPU 使用率。now，cpu_15，cpu_30，cpu_60分别代表1s，15s，30s，60s内的 CPU 使用率。
Timer 趋势
该进程当前定时器数量。
所有超时值相同的
js层面的定时器在该统计中数量为1。
libuv 句柄趋势
该进程的 libuv 句柄数统计，其中：
每个 TCP 连接占用一个句柄。
每个打开的文件占用一个句柄。
如何配置报警项
参见 用户指南-报警设置。
Node.js 性能平台是如何进程故障诊断的
参见 用户指南-故障诊断。
异常日志和性能日志有什么区别
异常日志是由应用写入的日志；
性能日志是由运行时在设置了
ENABLE_NODE_LOG=YES（默认不写）后写入到NODE_LOG_DIR所指定的目录（默认/tmp），每天一个日志文件，例如文件名称为node-20171010.log表示2017年10月10日的日志文件。
如何判断是否存在内存泄露
内存监控指标部分能看到随着时间内存持续增长。
如何判断是否存在 CPU 热点函数
CPU 持续飚高。