# 服务监控

## 概述

对于所有基于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秒再重试一次。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://tarscloud.gitbook.io/tarsdocs/kuang-jia-guan-jian-te-xing/tars-monitor.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.