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 持續飚高。