Node성능 모니터링 지표를 얻는 방법은 무엇입니까? 이 기사에서는 노드 성능 모니터링 지표를 얻는 방법에 대해 설명하겠습니다. 도움이 되기를 바랍니다.
최근에 nodejs 모니터링에 대해 배우고 있습니다. 비록 간단한 모니터링 버전을 작성하는 방법을 배울 에너지는 없지만 여전히 이러한 지표를 얻는 방법을 이해할 수는 없습니다. 정보가 많아서 국내 인터넷에는 이런 내용이 없는 것 같아요.. 소개가 너무 부족하네요.. 서버노드 지식 포인트도 정리하고 있어서 이 글에서 정리해보겠습니다.)
이 기사의 일부 지표에는 문제가 있을 수 있습니다. 교환을 환영합니다. 실제로 이러한 데이터를 정리하여 모니터링 라이브러리에 기록하고 자신의 중소 규모 프로젝트에 사용할 수 있습니다. 그러면 프론트엔드 리액트에는 비즈차트, g2 등의 도구가 있고, 프론트엔드가 스스로 큰 화면의 데이터를 그립니다. 내 생각에는 esay 모니터가 수집한 데이터 차원이 우리만큼 완전하지 않은 것 같습니다.
서버의 성능 병목 현상은 일반적으로 다음과 같습니다.
CPU 사용량과 CPU 로드는 어느 정도 시스템의 사용량을 반영할 수 있습니다.
CPU 사용량은 프로그램을 실행하는 데 사용되는 CPU 리소스로, 특정 시점에 기계가 프로그램을 어떻게 실행하고 있는지를 나타냅니다. 사용률이 높을수록 현재 컴퓨터에서 많은 프로그램을 실행하고 있음을 의미하며 그 반대의 경우도 마찬가지입니다. 사용량 수준은 CPU 성능과 직접적인 관련이 있습니다. 먼저 CPU 사용량을 얻기 위한 코드를 이해하는 데 도움이 되는 관련 API와 일부 용어 설명을 이해하겠습니다.
os.cpus()os.cpus()
返回包含有关每个逻辑 CPU 内核的信息的对象数组。
model: 一个字符串，指定CPU内核的型号。
speed: 一个数字，指定CPU内核的速度(以MHz为单位)。
times: 包含以下属性的对象：
注意： 的nice值仅用于POSIX。在Windows操作系统上，nice
model: CPU 코어의 모델을 지정하는 문자열입니다.
speed: CPU 코어의 속도를 MHz 단위로 지정하는 숫자입니다. times: 다음 속성을 포함하는 개체:
user CPU가 사용자 모드에서 소비한 밀리초 수입니다.
sys CPU가 시스템 모드에서 소비한 시간(밀리초)입니다. idle CPU가 유휴 모드에서 소비하는 시간(밀리초)입니다.
참고: 의 nice 값은 POSIX에만 해당됩니다. Windows 운영 체제에서 nice 값은 모든 프로세서에 대해 항상 0입니다.
애플리케이션 프로세스 실행은 사용자 모드
와 🎜커널 모드🎜로 구분됩니다. CPU는 사용자 모드에서 애플리케이션 프로세스 자체의 코드 로직을 실행합니다. 일반적으로 CPU는 프로세스를 실행합니다. 커널 모드에서 시작🎜 시스템 호출 🎜, 일반적으로 프로세스의 리소스 요청에 대한 응답으로 시작됩니다. 🎜🎜사용자 공간 프로그램은 커널의 일부가 아닌 모든 프로세스입니다. 셸, 컴파일러, 데이터베이스, 웹 서버 및 데스크톱 관련 프로그램은 모두 사용자 공간 프로세스입니다. 프로세서가 유휴 상태가 아닌 경우 대부분의 CPU 시간이 사용자 공간 프로세스를 실행하는 데 소비되는 것이 정상입니다. 🎜🎜nice🎜🎜nice는 CPU가 🎜낮은 우선순위 사용자 모드🎜에서 실행되는 시간의 비율을 나타냅니다. 낮은 우선순위는 프로세스 nice 값이 0보다 작다는 것을 의미합니다. 🎜🎜system🎜🎜user는 CPU가 🎜커널 상태🎜에서 실행되는 시간의 비율을 나타냅니다. 🎜🎜일반적으로 말하자면, 🎜커널 모드🎜 CPU 사용량은 응용 프로그램 프로세스가 많은 수의 시스템 호출을 시작하지 않는 한 너무 높으면 안 됩니다. 너무 높으면 잦은 IO 연산 등 시스템 호출에 오랜 시간이 걸린다는 뜻이다. 🎜🎜idle🎜🎜idle은 CPU가 유휴 상태인 시간의 비율을 나타냅니다. 이 상태에서는 CPU에 실행할 작업이 없습니다. 🎜🎜irq🎜🎜irq는 CPU가 🎜하드웨어 인터럽트🎜를 처리하는 시간의 비율을 나타냅니다. 🎜네트워크 카드 인터럽트는 일반적인 예입니다. 네트워크 카드는 데이터 패킷을 수신한 후 처리를 위해 하드웨어 인터럽트를 통해 CPU에 알립니다. 시스템 네트워크 트래픽이 매우 많으면 irq 사용량이 크게 증가하는 것을 볼 수 있습니다.
사용자 상태는 70% 미만, 커널 상태는 35% 미만, 전체 상태는 70% 미만으로 건강한 상태라고 볼 수 있습니다.
다음 예에서는 Node.js의 os.cpus() 메서드 사용을 보여줍니다.
예 1:
// Node.js program to demonstrate the // os.cpus() method // Allocating os module const os = require('os'); // Printing os.cpus() values console.log(os.cpus());
출력:
[ { model:'Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz',
speed:2712,
times:
{ user:900000, nice:0, sys:940265, idle:11928546, irq:147046 } },
{ model:'Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz',
speed:2712,
times:
{ user:860875, nice:0, sys:507093, idle:12400500, irq:27062 } },
{ model:'Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz',
speed:2712,
times:
{ user:1273421, nice:0, sys:618765, idle:11876281, irq:13125 } },
{ model:'Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz',
speed:2712,
times:
{ user:943921, nice:0, sys:460109, idle:12364453, irq:12437 } } ]다음은 CPU 사용률을 얻는 방법에 대한 코드입니다
const os = require('os');
const sleep = ms => new Promise(resolve => setTimeout(resolve, ms));
class OSUtils {
constructor() {
this.cpuUsageMSDefault = 1000; // CPU 利用率默认时间段
}
/**
* 获取某时间段 CPU 利用率
* @param { Number } Options.ms [时间段，默认是 1000ms，即 1 秒钟]
* @param { Boolean } Options.percentage [true（以百分比结果返回）|false]
* @returns { Promise }
*/
async getCPUUsage(options={}) {
const that = this;
let { cpuUsageMS, percentage } = options;
cpuUsageMS = cpuUsageMS || that.cpuUsageMSDefault;
const t1 = that._getCPUInfo(); // t1 时间点 CPU 信息
await sleep(cpuUsageMS);
const t2 = that._getCPUInfo(); // t2 时间点 CPU 信息
const idle = t2.idle - t1.idle;
const total = t2.total - t1.total;
let usage = 1 - idle / total;
if (percentage) usage = (usage * 100.0).toFixed(2) + "%";
return usage;
}
/**
* 获取 CPU 瞬时时间信息
* @returns { Object } CPU 信息
* user <number> CPU 在用户模式下花费的毫秒数。
* nice <number> CPU 在良好模式下花费的毫秒数。
* sys <number> CPU 在系统模式下花费的毫秒数。
* idle <number> CPU 在空闲模式下花费的毫秒数。
* irq <number> CPU 在中断请求模式下花费的毫秒数。
*/
_getCPUInfo() {
const cpus = os.cpus();
let user = 0, nice = 0, sys = 0, idle = 0, irq = 0, total = 0;
for (let cpu in cpus) {
const times = cpus[cpu].times;
user += times.user;
nice += times.nice;
sys += times.sys;
idle += times.idle;
irq += times.irq;
}
total += user + nice + sys + idle + irq;
return {
user,
sys,
idle,
total,
}
}
}
const cpuUsage = new OSUtils().getCPUUsage({ percentage: true });
console.log('cpuUsage: ', cpuUsage.then(data=>console.log(data))); // 我的电脑是6.15%CPU 로드(loadavg)는 CPU 시간을 차지하는 프로세스 수와 일정 시간 동안 CPU 시간을 기다리는 프로세스 수를 의미하는 것으로 이해하기 쉽습니다. 깨어나기를 기다리는 프로세스. 대기 상태의 프로세스는 제외됩니다.
이전에 노드 API를 배워야 합니다
os.loadavg()os.loadavg()返回包含 1、5 和 15 分钟平均负载的数组。
平均负载是操作系统计算的系统活动量度，并表示为小数。
平均负载是 Unix 特有的概念。 在 Windows 上，返回值始终为 [0, 0, 0]
[0, 0, 0]운영 체제의 현재 사용률을 설명하는 데 사용되며, 이는 단순히 CPU가 사용되고 대기 중이라고 이해할 수 있습니다. 단위 시간당 사용되는 평균 CPU 작업 수입니다. CPU 부하가 너무 높다는 것은 프로세스가 너무 많다는 것을 의미합니다. Node에서는 자금성 모듈을 사용하여 새 프로세스를 반복적으로 시작하는 데 반영될 수 있습니다. const os = require('os'); // CPU线程数 const length = os.cpus().length; // 单核CPU的平均负载，返回一个包含 1、5、15 分钟平均负载的数组 os.loadavg().map(load => load / length);
heapUsed: 힙에 있는 모든 개체의 총 크기인 할당 메모리는 heapTotal 집합의 하위 항목입니다.
external: 프로세스에서 사용하는 시스템 링크 라이브러리가 차지하는 메모리입니다. 예를 들어 버퍼는 외부에 있는 데이터입니다. 버퍼 데이터는 V8의 메모리 할당 메커니즘을 거치지 않는다는 점에서 다른 객체와 다르므로 힙 메모리 크기 제한이 없습니다.
다음 코드를 사용하여 하위 프로세스의 메모리 사용량을 인쇄하면 rss가 최상위 명령의 RES와 거의 동일하다는 것을 알 수 있습니다. 또한, 메인 프로세스의 메모리는 33M에 불과해 자식 프로세스의 메모리보다 작으며, 메모리 사용량이 독립적으로 계산되는 것을 볼 수 있습니다.var showMem = function(){
var mem = process.memoryUsage();
var format = function(bytes){
return (bytes / 1024 / 1024).toFixed(2) + ' MB';
};
console.log('Process: heapTotal ' + format(mem.heapTotal) + ' heapUsed ' + format(mem.heapUsed) + ' rss ' + format(mem.rss) + ' external:' + format(mem.external));
console.log('-----------------------------------------------------------');
};const os = require('os');
// 查看当前 Node 进程内存使用情况
const { rss, heapUsed, heapTotal } = process.memoryUsage();
// 获取系统空闲内存
const systemFree = os.freemem();
// 获取系统总内存
const systemTotal = os.totalmem();
module.exports = {
memory: () => {
return {
system: 1 - systemFree / systemTotal, // 系统内存占用率
heap: heapUsed / headTotal, // 当前 Node 进程内存占用率
node: rss / systemTotal, // 当前 Node 进程内存占用系统内存的比例
}
}
}match[와 같이 디스크 상태와 마운트된 디스크를 일치시킵니다. 1]은 Usage를 의미하는 문자열이고, match[2]는 마운트된 디스크의 이름을 나타냅니다
const { execSync } = require('child_process');
const result = execSync('df -P', { encoding: 'utf8'})
const lines = result.split('\n');
const metric = {};
lines.forEach(line => {
if (line.startsWith('/')) {
const match = line.match(/(\d+)%\s+(\/.*$)/);
if (match) {
const rate = parseInt(match[1] || 0);
const mounted = match[2];
if (!mounted.startsWith('/Volumes/') && !mounted.startsWith('/private/')) {
metric[mounted] = rate;
}
}
}
});
console.log(metric)I/O 로드는 주로 디스크 I/O를 나타냅니다. 이는 디스크의 읽기 및 쓰기 상황을 반영하며 주로 네트워크 서비스용으로 작성된 애플리케이션의 경우 I/O 로드가 너무 높을 가능성은 없습니다. 많은 읽기의 I/O 압력은 데이터베이스에서 발생합니다. .
I/O 표시기를 얻으려면 iostat라는 Linux 명령을 이해해야 합니다. 설치되어 있지 않은 경우 이 명령이 I/O 표시기를 반영할 수 있는 이유를 살펴보겠습니다.
iostat -dx
rrqm/s: 每秒进行 merge 的读操作数目。即 rmerge/s（每秒对该设备的读请求被合并次数，文件系统会对读取同块(block)的请求进行合并） wrqm/s: 每秒进行 merge 的写操作数目。即 wmerge/s（每秒对该设备的写请求被合并次数） r/s: 每秒完成的读 I/O 设备次数。即 rio/s w/s: 每秒完成的写 I/O 设备次数。即 wio/s rsec/s: 每秒读扇区数。即 rsect/s wsec/s: 每秒写扇区数。即 wsect/s rkB/s: 每秒读K字节数。是 rsect/s 的一半，因为每扇区大小为512字节。 wkB/s: 每秒写K字节数。是 wsect/s 的一半。 avgrq-sz: 平均每次设备I/O操作的数据大小 (扇区)。 avgqu-sz: 平均I/O队列长度。 await: 平均每次设备I/O操作的等待时间 (毫秒)。 svctm: 平均每次设备I/O操作的处理时间 (毫秒)。 %util: 一秒中有百分之多少的时间用于 I/O 操作，即被io消耗的cpu百分比
如果 await 远大于 svctm，说明 I/O 队列太长，应用得到的响应时间变慢，如果响应时间超过了用户可以容许的范围，这时可以考虑更换更快的磁盘，调整内核 elevator 算法，优化应用，或者升级 CPU。
监控Nodejs的页面响应时间, 方案选自廖雪峰老师的博客文章。
最近想监控一下Nodejs的性能。记录分析Log太麻烦，最简单的方式是记录每个HTTP请求的处理时间，直接在HTTP Response Header中返回。
记录HTTP请求的时间很简单，就是收到请求记一个时间戳，响应请求的时候再记一个时间戳，两个时间戳之差就是处理时间。
但是，res.send()代码遍布各个js文件，总不能把每个URL处理函数都改一遍吧。
正确的思路是用middleware实现。但是Nodejs没有任何拦截res.send()的方法，怎么破？
其实只要稍微转换一下思路，放弃传统的OOP方式，以函数对象看待res.send()，我们就可以先保存原始的处理函数res.send，再用自己的处理函数替换res.send：
app.use(function (req, res, next) {
// 记录start time:
var exec_start_at = Date.now();
// 保存原始处理函数:
var _send = res.send;
// 绑定我们自己的处理函数:
res.send = function () {
// 发送Header:
res.set('X-Execution-Time', String(Date.now() - exec_start_at));
// 调用原始处理函数:
return _send.apply(res, arguments);
};
next();
});只用了几行代码，就把时间戳搞定了。
对于res.render()方法不需要处理，因为res.render()内部调用了res.send()。
调用apply()函数时，传入res对象很重要，否则原始的处理函数的this指向undefined直接导致出错。
实测首页响应时间9毫秒
名词解释：
QPS：Queries Per Second意思是“每秒查询率”，是一台服务器每秒能够响应的查询次数，是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
互联网中，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。
TPS：是TransactionsPerSecond的缩写，也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。
QPS vs TPS：QPS基本类似于TPS，但是不同的是，对于一个页面的一次访问，形成一个TPS；但一次页面请求，可能产生多次对服务器的请求，服务器对这些请求，就可计入“QPS”之中。如，访问一个页面会请求服务器2次，一次访问，产生一个“T”，产生2个“Q”。
响应时间：执行一个请求从开始到最后收到响应数据所花费的总体时间,即从客户端发起请求到收到服务器响应结果的时间。
响应时间RT(Response-time)，是一个系统最重要的指标之一，它的数值大小直接反应了系统的快慢。
并发数是指系统同时能处理的请求数量，这个也是反应了系统的负载能力。
系统的吞吐量（承压能力）与request对CPU的消耗、外部接口、IO等等紧密关联。单个request 对CPU消耗越高，外部系统接口、IO速度越慢，系统吞吐能力越低，反之越高。
系统吞吐量几个重要参数：QPS（TPS）、并发数、响应时间。
QPS（TPS）：（Query Per Second）每秒钟request/事务 数量
并发数： 系统同时处理的request/事务数
响应时间： 一般取平均响应时间
理解了上面三个要素的意义之后，就能推算出它们之间的关系：
我们通过一个实例来把上面几个概念串起来理解。按二八定律来看，如果每天 80% 的访问集中在 20% 的时间里，这 20% 时间就叫做峰值时间。
1、每天300w PV 的在单台机器上，这台机器需要多少QPS？
( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)
2、如果一台机器的QPS是58，需要几台机器来支持？
139 / 58 = 3
到这里，以后如果你做一般中小项目的前端架构，在部署自己的node服务，就知道需要多少机器组成集群来汇报ppt了吧，哈哈，有pv就能推算一个初略值。
我们需要了解一下压力测试（我们要靠压测获取qps），以ab命令为例：
命令格式：
ab [options] [http://]hostname[:port]/path
常用参数如下：
-n requests 总请求数 -c concurrency 并发数 -t timelimit 测试所进行的最大秒数, 可以当做请求的超时时间 -p postfile 包含了需要POST的数据的文件 -T content-type POST数据所使用的Content-type头信息复制代码
更多参数请查看官方文档。
http://httpd.apache.org/docs/2.2/programs/ab.html
例如测试某个GET请求接口：
ab -n 10000 -c 100 -t 10 "http://127.0.0.1:8080/api/v1/posts?size=10"
得到一下数据：
我们从中获取几个关键指标：
服务器并发处理能力的量化描述，单位是reqs/s，指的是在某个并发用户数下单位时间内处理的请求数。某个并发用户数下单位时间内能处理的最大请求数，称之为最大吞吐率。
记住：吞吐率是基于并发用户数的。这句话代表了两个含义：
计算公式：
总请求数/处理完成这些请求数所花费的时间
必须要说明的是，这个数值表示当前机器的整体性能，值越大越好。
2、QPS每秒查询率(Query Per Second)
每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量，即每秒的响应请求数，也即是最大吞吐能力。
计算公式
QPS（TPS）= 并发数/平均响应时间（Time per request）
在上图里有Time per request的值，然后我们也有并发数数据，就可以计算出QPS。
这个QPS是压测数据，真实的qps，可使用日志监控来获取。
通常情况下，随着系统的运行，我们的后台服务会产生各种日志，应用程序会产生应用程序的访问日志、错误日志，运行日志，网络日志，我们需要一个展示平台去展示这些日志。
后端一般都用比如ELk去展示，我们前端都是ui老手了，自己可以画定制的UI界面，不多说了，主要是日志本身要打印符合一定的规范，这样格式化的数据更利于分析和展示。
并且业务逻辑型的监控主要体现在日志上。通过监控异常日志文件的变动，将新增的异常按异常类型和数量反映出来。某些异常与具体的某个子系统相关，监控出现的某个异常也能反映出子系统的状态。
在体制监控里也能体现出实际业务的QPS值。观察QPS的表现能够检查业务在时间上的分部。
此外，从访问日志中也能实现PV和UV的监控。并且可以从中分析出使用者的习惯，预知访问高峰。
这个也可以通过访问日志来获取，并且真实响应时间是需要在controller上打log的。
监控进程一般是检查操作系统中运行的应用进程数，比如对于采用多进程架构的node应用，就需要检查工作进程的数量，如果低于预期值，就当发出报警。
查看进程数在linux下很简单，
假如我们通过Node 提供 child_process 模块来实现多核 CPU 的利用。child_process.fork() 函数来实现进程的复制。
worker.js 代码如下：
var http = require('http')\
http.createServer(function(req, res) {\
res.writeHead(200, { 'Content-Type': 'text/plain' })\
res.end('Hello World\n')\
}).listen(Math.round((1 + Math.random()) * 1000), '127.0.0.1')\通过 node worker.js 启动它，会监听 1000 到 2000 之间的一个随机端口。
master.js 代码如下：
var fork = require('child_process').fork
var cpus = require('os').cpus()
for (var i = 0; i < cpus.length; i++) {
fork('./worker.js')
}查看进程数的 命令如下：
ps aux | grep worker.js
$ ps aux | grep worker.js lizhen 1475 0.0 0.0 2432768 600 s003 S+ 3:27AM 0:00.00 grep worker.js\ lizhen 1440 0.0 0.2 3022452 12680 s003 S 3:25AM 0:00.14 /usr/local/bin/node ./worker.js\ lizhen 1439 0.0 0.2 3023476 12716 s003 S 3:25AM 0:00.14 /usr/local/bin/node ./worker.js\ lizhen 1438 0.0 0.2 3022452 12704 s003 S 3:25AM 0:00.14 /usr/local/bin/node ./worker.js\ lizhen 1437 0.0 0.2 3031668 12696 s003 S 3:25AM 0:00.15 /usr/local/bin/node ./worker.js\
更多node相关知识，请访问：nodejs 教程！
위 내용은 노드 성능 모니터링 지표를 얻는 방법은 무엇입니까? 메소드 공유 받기의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
