对于所有基于Tars框架实现的业务服务，Node都可以很好进行实时监控。一般的服务异常退出，僵死等现象，都会由Node主动监控起来，使服务运行的可靠性更高。
Node服务通过开启一个监控线程，负责定时（时间间隔可以配置）轮询监控Node所管理的所有服务的运行状态，并定时向主控上报服务的运行状态。如果某个服务满足相关触发条件，则采取相应的措施来管理服务，使服务的运行状态实时在Node的监控下。
该监控线程主要包括以下几个关键因素：
1.监控线程的频率（单位是秒）
2.业务服务心跳上报的超时时间（单位是秒），如果某个节点下的服务业务处理过程比较耗时，可以考虑增加这个值。
3.Node向主控上报服务运行状态的频率（单位是秒）
4.Node向主控上报服务运行状态的方式，有两种方式：单个和批量，默认选择批量上报。如果该Node下的服务比较多，可以选择批量方式提高效率。
监控线程在对服务的监控过程中，会涉及到几个重要的监控点的判断策略。
目前我们检测服务进程是否存在的方法是通过linux系统的kill函数向指定进程id发送NULL信号（kill -0 进程id）来判断进程是否存在。
服务的心跳超时时限是在Node中配置的，这个时限适用于该Node管理下的所有服务的心跳超时时限。
每个业务服务会每隔10秒上报一次心跳时间给Node，Node则在一定的监控频率下检测每个业务服务的心跳时间是否已经超时。
Node还会检测每个业务服务自身所有adapter的心跳时间是否超时。
考虑到各种故障以及容灾特性，Node只会对满足启动条件的服务进行发送启动命令。
这里采用的策略是：
1.服务的当前状态处于过渡状态的不允许重启，即处于“Activating”，“Deactivating”，“Destroying”，“Loading”，“Patching”，“BatchPatching”等状态。
2.有可能服务通过运维界面停止的，即人为停止该服务，此时服务的“内部工作状态”会被设置为false，在这种情况下，不允许Node监控线程去启动服务。
3.有些服务可能确实出现系统性问题，导致无法启动成功。为了防止频繁的去重启这些服务，Node监控程序采用了“服务重启惩罚时间”的策略：即服务每次重启都会被记录重启次数和重启时间点，在X秒内最多重启N次，如果重启超过N次后，服务还是启动失败，则以Y秒的频率去尝试重启服务。
目前框架中的默认值是：60秒内最多启动10次，达到10次启动仍失败后,每隔600秒再重试一次。