标签归档:监控

监控的盲点

【背景】
公司已经有较为完善的监控手段。monitor,通过累积量等一维数据监控自身的情况;智能监控,通过多维数据统计成功率和时耗。当然我们一直认为“一切尽在掌握”。

【问题】
某业务B_T的调用方发现出现超时的情况,排除网络问题,在我们看来只可能是后端服务S_T出问题了。而后查询对应的后端自身服务monitor监控正常,智能监控也变化ok。最后经后端童鞋深入排查,发现是自己server假死了。那么问题来了:
1) 为啥监控没啥变化
假死的server,在LB里面权重被放低了,所以请求量就少了,咋眼看去,monitor视图请求量几乎没变化(减少的很小),因此没有产生告警。而因为假死,所以正常的请求并未被S_T处理,所以智能监控不会被上报,成功率和时耗没有变。
2) 为啥其他业务没太大影响
S_T为很多业务服务,量大的服务,由于成功率都很高,所以通常不会有告警。而量小的业务(或者长尾业务)却很容易受到波动。
3) 为啥没有被LB完全踢掉
这个跟后端S_T的异常姿势有关系,由于是假死,偶尔处理一个请求,LB探测到S_T还alive,又会扔正常的业务数据过来,挂一会儿,又踢掉,周而复始。

【思考】
虽说根本上是后端的server开发者的问题,但是后台开发,监控为王。没有完美的程序,只有不完美的监控。这里暴露出来监控的一些特点,就是不能简单的通过自身的监控上报来判断服务质量,这样就会存在上诉的盲点,监控应该是一个纵深,立体化的过程。将调用方视角的后端服务质量纳入后端服务的监控范围,整合上下游的监控或许才能更加精准的为后端服务保驾护航。

轮server监控的层次

监控是服务的晴雨表,对开发者尤为重要,基本是server上线的标配,主要分两个层次。

1. 标准化监控
这里主要有两类 : 标准化的网络设备(主机监控),例如路由器交换机,通常都可以通过snmp协议采集到(即便是私有的od指标也能从生产商处获得);标准化的服务(中间件监控),例如httpd,nginx,mysql,web页面等等,通过对标准服务的特性采集,例如运行端口,进程名称,日志情况等来配置监控参数。
标准化维度的监控,绝大部分开源软件(zabbix,cacti等)都都能满足。

2. 业务服务监控
具体的业务监控,开源的东东就捉襟见肘了,仅仅少部分场景能通过脚本勉强满足,这就是为什么大部分成熟的互联网公司都有自己的一套或几套监控系统。监控 = 上报 + 绘图 + 告警,监控系统 = 上报api + 视图管理 + 告警管理。这里面又大致分成两大类 : 数据量维度的监控和状态维度的监控。

1). 数据量维度
上报点包括总请求量,总失败量,总成功量,各分支请求量,各分支失败量,各分支成功量,特殊上报量,时延区间量(例如50ms以下的处理请求量等)。
数据量是业务监控的最低层次,各项指标不正常,server必然是有问题,但指标正常并不代表server没有问题。

a) server嵌入上报api,monitor_api(int attr_id, int attr_value)
b) monitor_agent周期汇总本机的所有的attr_id的上报值发送给collect_svr
c) collect_svr对数据做处理,按(attr_id, report_ip) -> attr_value存储数据,按attr_id -> report_ip_list和report_ip -> attr_id_list存储索引关系
d) 页面上根据数据和索引关系聚合出各种视图 (attr_id, report_ip, day_timeline),(attr_id, all_report_ip, day_timeline),(report_ip, attr_id_list, day_timeline)
e) 告警模块中针对各个视图关系设置最大值/最小值等告警策略

2). 状态维度
服务的质量通常都是状态量,最常见的指标就是 时延和成功率。这两个指标基本可以反映出某条服务或接口的服务质量。

a) server调用后端结束时嵌入上报api,stat_api(int service_id, int stat_code, uint32_t cost_time)
b) stat_agent周期汇总或者直接转发本机的所有的service_id的上报数据发送给collect_svr
c) collect_svr对数据做处理,按(service_id, called_ip, report_ip) -> stat_value存储数据,按(service_id, called_ip) -> report_ip_list, (service_id, report_ip) -> called_ip_list存储索引
d) 页面上根据数据和索引关系聚合出各种视图 (service_id, report_ip, called_ip_list, day_timeline),(attr_id, called_ip, report_ip_list, day_timeline),(service_id, report_ip, called_ip, day_timeline)
e) 告警模块中对单机或者整个服务的 时延或成功率设置阀值

3. 调用链监控
仅仅是服务自身的监控是不够,还得能够拓扑出一条请求的来龙去脉。这里又分两种:这里业界通用做法都是通过一个traceId贯穿整个调用路径,然后由后端的日志平台离线分析去统计;另外前者必须保证整个公司所有路径都要规范上报,有时候比较困难,局部实现的话,在某一个程序上以调用者的视角去统计所有服务接口的各种信息去上报统计拓扑更容易实施。