Tars服务监控与特性监控

Tars框架自带服务监控(stat)与特性监控(property)的功能,入口在如下图:

(直接点会是空白,你得先点开你的一个Server才会出现曲线图)

依靠监控功能,你可以快速的定位问题,观察接口的使用状态,进程运行状态,甚至自定义观察数据直观的在Tars管理页面上显示出来。

你可以自行做二次开发,利用入库数据做成自己的短信告警机制。总之就是数据在,想怎么围绕展开都行。

服务监控(stat)

服务监控主要统计(上报)每个请求的成功、失败、超时的调用量,并当调用成功时额外搜集调用耗时

请求包括外部自定义请求和内部模块的RPC,这些已经涵盖了90%的需求,一般来说没有特别需求,不需要手动对服务监控进行修改。

这里先解释一下服务监控界面上查询输入参数的命名规则:

  • 主调:调用发起方;
    • 如果是内部模块的RPC,那么这一栏建议填写AppName.ServerName的组合。比如有一个名字叫tank的App,这个App有一个名字为RouterServer的服务,那么组合起来就是tank.RouterServer;
    • 如果是外部自定义请求,默认固定名字是not_tars_client(上报位置在TarsCurrent析构时);
    • 还有一些特别的固定命名,比如tarsnode,one_way_client,tars.system,都是内部的一些统计监控,一般不用太关心;
  • 被调:被调用方,规则同上;
  • 接口名:被调用方提供的接口名,无特别规则;
  • 主调IP:主调IP地址,形如192.168.1.100;
  • 被调IP:被调IP地址;

对于服务监控其他一些地方需要注意的是:

  1. 支持模糊查询,语法就是sql中like后面的pattern;
  2. 如果输入框为空那么就是匹配所有;
  3. 服务监控数据入库的间隔是5分钟,修改的地方在StatServer.cpp

上图点击监控曲线按钮后,就会产生在从RouterServer调用ConfigServer接口getErrMsg的详细情况(成功、失败、超时、耗时……),这里略去结果图了。

有兴趣的朋友可以自行测试一下输入框参数对结果的影响,还是很好理解的。

 

特性监控(property)

如果说服务监控(stat)主要监控对象是接口(服务)的状态,那么特性监控(property)更聚焦在提供服务者自身的特性,比如:内存占用,队列长度,当前连接数……。它是一个相对灵活的监控,为什么这么说?先分析查询输入参数:

  • 服务名(master_name):自定义;
    • 对于单个Server的特性(局部特性),填写规则一般约定成AppName.ServerName的组合,与服务监控(stat)的主调、被调命名一致;
    • 对于全局特性,比如:所有的外部网络连接总和,建议可以使用服务名Global配合后面提到的特性;
  • IP:提供监控信息的IP地址;
  • 特性(property_name):自定义:
    • 对于局部特性,一般约定成AppName.ServerName.Description的组合,比如内存占用,AppName.ServerName.memsize;
    • 对于全局特性,直接进行描述;
  • 策略:Tars提供了求和、求平均,分布,求最大值,求最小值,计数这些策略,可以参考这里

所以可以看出来,特性监控(property)有很大的自由度,如何使用如何定义全凭自己喜好,下面来说下如何使用:

  1. 找到PropertyReporter.h这个头文件(在源码文件里存在,它没有被列入到Tars公共库里);
  2. 直接拷贝这个文件到自己Tars环境下的目录,#include “PropertyReporter.h”;
  3. 加入目标代码,比如:求和 REPORT_SUM(“your_master_name”, “your_property_name”,count);

后面你就可以在管理页面搜索到监控内容了(略去结果图):

其他一些地方需要注意的是:

  1. 支持模糊查询,语法就是sql中like后面的pattern;
  2. 如果输入框为空那么就是匹配所有;
  3. 服务监控数据入库的间隔是5分钟,修改的地方在PropertyServer.cpp;
  4. 策略是固定填法,类似Max,Avg,Count这种;

 

与Tars服务监控、特性监控相关的知识点

  • 要使用这个2个监控,Tars自带的tarsstat,tarsquerystat,tarsproperty,tarsqueryproperty必须正确的启动工作;
    • tarsstat负责服务监控数据录入,对应DB库表tars_stat.tars_stat_%Y%m%d%H;
    • tarsquerystat负责服务监控数据查询;
    • tarsproperty负责特性监控数据录入,对应DB库表tars_property.tars_property_%Y%m%d%H;
    • tarsqueryproperty负责特性监控数据查询;
  • DB库tars_stat,tars_property数据会一直膨胀下去(一天增加24X2张表,默认情况下也有不少数据),根据业务需要找到合适自己的数据清理/保存/压缩的方法;
  • Tars已经自带服务监控已经提供了接口级的监控,建议自行进入DB库里翻翻数据,对这些监控属性有一个更直观的认识;
  • 最后,监控不是万能的,而且Tars监控默认的实时性不高,不能把宝都压在这个上面;

(全文结束)


转载文章请注明出处:漫漫路 - lanindex.com

3 Comments

 Add your comment
  1. 加入目标代码,比如:求和 REPORT_SUM(“your_master_name”, “your_property_name”,count);
    ——这个说的太简单了,请问具体怎么加?要自己创建线程吗?要自己做定时上报的动作吗?

    • 方便的话,回个email : yarggo@gmail.com
      3x

      • 你可能没细看我写的步骤:
        1、先拷贝PropertyReporter.h这个文件(在Tars/cpp/framework/NodeServer目录下)到自己的Tars工程目录;
        2、然后自己的Server代码包含这个头文件;
        3、REPORT_SUM只是这个头文件实现的一个宏,里面逻辑都是实现好的。

        具体的内部逻辑,Reporter内部维护了上报线程,REPORT_SUM这个接口会把上报内容塞到线程队列,异步进行上报。

Leave a Comment

Your email address will not be published.