监控的主要目的是为了将一些重要指标采样记录下来，一旦这些指标发生较大变化，可以配合报警系统将问题反馈到负责人那。监控的点可以很细致，也可以只选主要的指标。
日志监控
01
业务逻辑型的监控主要体现在日志上，做足了日志记录的功夫之后，如何将日志应用起来是个问题。通过监控异常日志文件的变动，将新增的异常按异常类型和数量反映出来。某些异常与具体的某个子系统相关，监控出现的某个异常多半能反映出子系统的状态。
除了异常日志的监控外，对于访问日志的监控也能体现出实际的业务QPS值。观察QPS的表现能够检查业务在时间上的分布。
此外，从访问日志中也能实现PV和UV的监控。同QPS值一样，通过对PV/UV的监控，可以很好地知道应用的使用者们的习惯、预知访问高峰等。
响应时间
02
响应时间也是一个需要监控的点。一旦系统的某个子系统出现异常或者性能瓶颈，将会导致系统的响应时间变长。响应时间可以在Nginx一类的反向代理上监控，也可以通过应用自行产生的访问日志来监控。健康的系统响应时间应该是波动较小的、持续均衡的。
进程监控
03
监控日志和响应时间都能较好地监控到系统的状态，但是它们的前提是系统是运行状态的，所以监控进程是比前两者更为紧要的任务。监控进程一般是检查操作系统中运行的应用进程数，比如对于采用多进程架构的Web应用，就需要检查工作进程的数量，如果低于预估值，就应当发出报警声。
磁盘监控
04
磁盘监控主要是监控磁盘的用量。由于日志频繁写的缘故，磁盘空间渐渐被用光。一旦磁盘不够用，将会引发系统的各种问题。给磁盘的使用量设置一个上限，一旦磁盘用量超过警戒值，服务器的管理者就应该整理日志或清理磁盘了。
内存监控
05
对于Node而言，一旦出现内存泄漏，不是那么容易排查的。监控服务器的内存使用状况，可以检查应用中是否存在内存泄漏的状况。如果内存只升不降，那么铁定存在内存泄漏问题。健康的内存使用应当是有升有降，在访问量大的时候上升，在访问量回落的时候，占用量也随之回落。
如果进程中存在内存泄漏，又一时没有排查解决，有一种方案可以解决这种状况。这种方案应用于多进程架构的服务集群，让每个工作进程指定服务多少次请求，达到请求数之后进程就不再服务新的连接，主进程启动新的工作进程来服务客户，旧的进程等所有连接断开后就退出。这样即使存在内存泄漏的风险，也能有效地规避内存泄漏带来的影响。但这属于规避问题，只解决了问题的表象，不推荐使用。
总而言之，监控内存并长时间观察是防止系统出现异常的好方法。如果突然出现内存异常，也能够追踪到是近期的哪些代码改动导致的问题。
CPU占用监控
06
服务器的CPU占用监控也是必不可少的项，CPU的使用分为用户态、内核态、IOWait等。如果用户态CPU使用率较高，说明服务器上的应用需要大量的CPU开销；如果内核态CPU使用率较高，说明服务器花费大量时间进行进程调度或者系统调用；IOWait使用率则反应的是CPU等待磁盘I/O操作。
CPU的使用率中，用户态小于70%、内核态小于35%且整体小于70%时，处于健康状态。监控CPU占用情况，可以帮助分析应用程序在实际业务中的状况。合理设置监控阈值能够很好地预警。
CPU load监控
07
CPU load又称CPU平均负载，它用来描述操作系统当前的繁忙程度，可以简单地理解为CPU在单位时间内正在使用和等待使用CPU的平均任务数。它有3个指标，即1分钟的平均负载、5分钟的平均负载、15分钟的平均负载。CPU load过高说明进程数量过多，这在Node中可能体现在用子进程模块反复启动新的进程。监控该值可以防止意外产生。
I/O负载
08
I/O负载指的主要是磁盘I/O。反应的是磁盘上的读写情况，对于Node编写的应用，主要是面向网络服务，是故不太可能出现I/O负载过高的情况，大多数的I/O压力自于数据库。不管Node进程是否与数据库或其他I/O密集的应用共处相同的服务器，我们都应监控该值以防万一。
网络监控
09
虽然网络流量监控的优先级没有上述项目那么高，但还是需要对流量进行监控并设置上限值。即便应用突然受到用户的青睐，流量暴涨时也能通过数值感知到网站的宣传是否有效。一旦流量超过警戒值，开发者就应当找出流量增长的原因。对于正常增长，应当评估是否该增加硬件设备来为更多用户提供服务。网络流量监控的两个主要指标是流入流量和流出流量。
应用状态监
10
除了这些硬性需要检测的指标外，应用还应当提供一种机制来反馈其自身的状态信息，外部监控将会持续性地调用应用的反馈接口来检查它的健康状态。
最简单的状态反馈就是给监控响应一个时间戳，监控方检查时间戳是否正常即可。
健壮一些的状态响应则是将应用的依赖项的状态打印出来，如数据库连接是否正常、缓存是否正常等。
完
