更新时间:2018-12-25 13:54
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.log
step 2 查看 agenthub 的配置,通过实例
页面上的 查看运行中的Node.js进程
后点击 检查进程
。
所有诊断操作需要顺序执行。一个操作未完成时进行下一个操作会提示操作失败。文件页面转储按钮有效时表明操作已完成(诊断报告数秒可完成,堆快照根据堆大小可能数秒到数分钟,其他操作持续时间为 3 分钟)。
通过 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 Id
和 App Secret
,用 NODE_LOG_DIR
指定不同的路径存放运行时日志,并且与 config.json
里面 logdir
路径一致。这样可以启动多个 agenthub。或者;
启动一个 agenthub,所有应用的运行时日志指向相同目录(默认 /tmp
),error_log
和 packages
可以放到配置文件的数组里面。
which pm2
结果中包含 .tnvm
字段;PM2 v0.15.8: God Daemon
不能漏掉;
$ ENABLE_NODE_LOG=YES pm2 start app.js
$ ENABLE_NODE_LOG=YES pm2 start app.js
通过实例
页面上的 查看运行中的Node.js进程
后点击 检查进程
进行排查。
在配置文件中添加配置项 "agentidMode": "IP"
。
例如有两个实例的 hostname
都是 app_container
,IP
分别是 10.10.12.124
和 10.10.12.123
,如果配置中增加 "agentidMode": "IP"
,那么两个实例ID分别是 app_container_12124
和 app_container_12123
。细节请参考。
config.json
里面中配置的 error_log
所指定的日志文件中带 error stack
的日志,该日志由用户应用生成。config.json
里面中配置的 packages
所指定的 npm 模块,用红色提示存在安全风险的模块。最近一次日志上报的各项指标,具体指标含义如下所述。
memory_sys
:系统内存使用百分比。memory_node
: 所有 Node.js 进程内存使用之和占系统内存的百分比。cpu_sys
:系统 CPU 使用百分比。cpu_node
:所有 Node.js 进程 CPU 使用百分比之和。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
较高,需要引起关注。该实例所有 Node.js 进程每秒钟处理的 HTTP 请求数之和。
gc_avg
:所有 Node.js 进程垃圾回收时间占比平均值。gc_max
:每分钟内垃圾回收时间最多的 Node.js 进程的垃圾回收时间占比。Node.js 性能平台根据 HTTP
的响应时间 RT
来定义用户满意度(默认响应时间 100ms
):
satisfied
(满意):RT <= T
tolerating
(容忍):T < RT < 4 * T
frustrated
(失望):RT > 4 * T
satisfied + tolerating / 2
satisfied
的 HTTP
请求为 60%
,tolerating
的为 30%
,frustrated
的为 10%
Apdex = 0.6 + 0.3 / 2 = 0.75
如上面描述的,根据响应时间分类的 HTTP
请求详细统计。
该实例内的 Node.js 进程数统计。
该实例的磁盘使用率。
rss
:该进程实际使用的内存,包括堆内内存和堆外内存。heap_total
:总的堆内存。heap_used
:实际使用的堆内存。scavange_duration
:scavange
垃圾回收时间占比。marksweep_duration
:marksweep
垃圾回收时间占比。堆上各个内存空间 code_space
,lo_space
,map_space
,new_space
,old_space
上的内存大小。
该进程每秒钟处理的 HTTP 请求数。
该进程在各个统计时段内的 CPU 使用率。now
,cpu_15
,cpu_30
,cpu_60
分别代表1s
,15s
,30s
,60s
内的 CPU 使用率。
该进程当前定时器数量。
js
层面的定时器在该统计中数量为1。该进程的 libuv
句柄数统计,其中:
参见 用户指南-报警设置。
参见 用户指南-故障诊断。
ENABLE_NODE_LOG=YES
(默认不写)后写入到 NODE_LOG_DIR
所指定的目录(默认 /tmp
),每天一个日志文件,例如文件名称为 node-20171010.log
表示2017年10月10日的日志文件。
在文档使用中是否遇到以下问题
更多建议
匿名提交