tarsdocs
  • Readme.md
  • CLA
  • LICENSE
  • 基础介绍
    • 简介
    • 基础概念
    • 基础通信协议 Tars
    • 统一通信协议 Tup
    • 开发模式介绍
    • 模板配置
    • 服务市场
    • 服务扩展
    • 框架版本说明
  • 开源版框架介绍
    • 开源版本部署
      • 部署总体介绍
      • Docker环境安装
      • Mysql安装
      • 框架源码部署(Linux/Mac)
      • 框架源码部署(Windows)
      • 框架Docker部署
      • 框架节点部署
      • 业务服务容器化
      • 框架K8SDocker 部署
      • 框架K8STARS 部署
      • 框架K8SFramework 部署(强烈推荐)
      • 框架更新及扩容
      • 调用链升级注意事项
      • TarsWeb-v3.0.3升级说明
    • 开源版管理平台
      • TarsWeb说明
      • web用户体系
      • web管理平台 API
  • 企业版本介绍
    • 企业版说明
    • 框架集群化机制
    • 框架单节点机制
    • 使用二进制包部署
    • 使用容器部署
    • 业务服务一主多备机制
    • 命令行控制终端
    • IP-LIST级联缓存机制
    • 多数据中心管理
    • 多网络支持
    • 第三方服务管理
    • 数据产生和管理机制
    • 密码重置
    • TarsPython介绍
  • 框架关键特性
    • 业务配置
    • 服务监控
    • 无损发布/重启
    • 调用链
    • IDC分组
    • 鉴权功能
  • TarsCPP
    • 编译
    • 快速开发入门
    • 使用指南
    • 开发规范
    • 服务线程说明文档
    • protobuf 协议支持文档
    • 第三方协议支持
    • HTTP1 支持
    • HTTP2 支持
    • TLS 通信支持
    • Push 功能说明
    • PushCallback 功能说明
    • Cookie 支持
    • 队列模式
    • 手动绑定
    • 性能数据
    • 2.x 版本变化
    • 3.x 版本变化
    • 协程版本说明
    • 基础类库说明
    • [案例]
      • 框架快速入门
      • Http 服务示例
  • TarsJava
    • 快速开始
    • 快速开发入门
    • [使用指南]
      • Tars 服务开发与上线
      • HTTP 服务开发与上线
      • 生成接口调用文件
    • [性能测试]
      • tars java 压测代码
  • TarsGo
    • 基本介绍
    • 快速开始
    • 使用指南
    • cmake 管理代码
    • pb2tarsgo
    • 性能数据
    • 使用示例
  • TarsPHP
    • 搭建 php 环境
    • 快速开发入门
    • [快速起步]
      • 搭建 HttpServer
      • 搭建 TimerServer
      • 搭建 TcpServer
      • 搭建 WebSocketServer
      • 弹幕活动实战
    • [框架简介]
      • 简介
      • tars-server
      • tars-client
      • tars-config
      • tars-deploy
      • tars-extension
      • tars-log
      • tars-monitor
      • tars-registry
      • tars-report
      • tars-utils
      • tars2php
    • [高阶应用]
      • PHP 的 Swoole 框架如何接入 Tars
      • 与 thinkphp 结合使用
      • 与 Swoft 结合使用
      • 与 Laravel 结合使用
      • 与 Yii2 结合使用
      • 持续集成方案
    • [其他]
      • 常见问题
      • 如何 Debug
      • changelog
      • 其他外部文档
  • Tars.js
    • 基本介绍
    • 脚手架
    • 快速开发入门
    • @tars/stream
    • @tars/rpc
    • @tars/logs
    • @tars/config
    • @tars/monitor
    • @tars/notify
    • @tars/utils
    • @tars/dyeing
    • @tars/node-agent
    • @tars/winston-tars
    • tars2node
  • K8SFramework
    • [安装和使用说明]
      • 介绍
      • 特性
      • 安装
      • 升级
      • 云原生运维
      • 管理平台
      • 证书
    • [开发环境构建]
      • Dockerfile 说明
      • 服务发布流程说明
      • 制作基础编译镜像
      • 制作业务服务镜像
      • 制作 Helm 包
      • 发布业务镜像到 K8S 集群
      • 服务发布示例
      • 如何调试业务服务
  • 服务扩展
    • 云告警
    • 接口及压测工具
    • 网关服务
    • dcache缓存服务
    • 发送邮件服务
    • 一致性存储服务
    • 一致性存储web管理平台
    • 唯一计数服务
  • 常见问题
    • 安装常见问题
    • Issues
    • Issues-tarscpp
    • Issues-tarsjava
    • Issues-tarsgo
    • Issues-tarsphp
  • 开源合作
    • TarsFramework 项目 Git 合作规范
  • 直播视频
    • B 站 TARS 培训系列课程
  • 相关文章
    • TARS 技术文章
  • 其它资源分享
    • 下载
    • Tars 介绍.pptx
    • TarsPHP 解密.pdf
    • TarsJava 本地调试.pdf
    • 微服务在腾讯的业务实践.pptx
Powered by GitBook
On this page
  • 概述
  • 服务监控原理
  • 服务监控原理概述
  • 服务监控策略

Was this helpful?

  1. 框架关键特性

服务监控

概述

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

Previous业务配置Next无损发布/重启

Last updated 3 years ago

Was this helpful?