站点监控 | 外科医生的实战

640?wx_fmt=gif

作者简介

梁飞    百度高级研发工程师

640?wx_fmt=png

负责百度云监控(BCM)系统的研发和可用性建设相关工作,在云监控、系统可用性方面有广泛的实践经验。

网站无法访问、网站内容返回错误、网站响应慢等场景。针对以上场景,本文将从技术角度探究如何实现站点监控

根据之前文章的介绍,设计一个站点监控系统,需要满足以下两个方面需求:

  • 支持多种站点监控需求

    • 支持多种协议类型,比如HTTP、HTTPS等;

    • 支持站点可用性监控,比如域名是否被劫持,接口返回错误码、接口返回语义是否符合预期等;

    • 支持站点性能的监控,比如接口整体响应时间,服务端和网络传输的分阶段时间等;

    • 支持不同域/运营商/网络制式多种探测方式,便于多维度分析和故障定位。

  • 保障探测任务的高可用

做为一个监控系统,站点监控需要保障7*24小时服务稳定运行。通常单个探测点Agent故障是无法避免的,这就需要系统能够进行探测点故障容灾,以保证单个探测点故障的情况下,采集任务仍然能够正常的被执行。

我们需要根据站点的服务类型和服务对外暴露的接口提供包括应用层、传输层协议在内的多种探测协议支持,常见的协议有HTTP(S) 、FTP、SMTP、DNS、PING、TCP、UDP。

一个站点探测任务通常输出多个指标,来表示目标站点的可用性和性能状态。如图1所示,我们通过一个网站从浏览器输入网址开始到浏览器返回内容的过程,来说明一次HTTP探测任务输出的可用性和性能的指标有哪些。

640?wx_fmt=png

图1  一个网址从输入到页面加载完毕的流程

  • 网站连通性

网站连通性主要反应网站是否可以成功建立连接,指标包括DNS解析返回值,TCP连接是否建立,探测任务是否探测成功。

  • 网站语义

网站语义用来探测网站的返回内容是否符合预期,指标包括HTTP响应状态码,HTTP内容校验结果返回值(校验的内容需用户自己配置)。

  • 网站性能

网站性能反应网站的响应速度,指标包括DNS解析时间,TCP建连时间, HTTP内容下载时间,探测任务整体响应时间。

上述过程整理了HTTP探测任务的执行过程和输出的监控项。不同的协议类型会有不同的监控指标产生,如表1所示。

表1  站点监控探测任务说明

640?wx_fmt=png

一个网站通常会被不同省份的用户通过不同运营商和网络制式进行访问,当一个用户反馈网站异常了,我们期望能够快速的发现和定位故障的范围,常见场景如下:

  • 查询在江苏移动4G网络下访问站点的平均响应时间

  • 查询在北京联通网络下访问站点的平均响应时间

  • 查询网站在全网的平均响应时间

通过在全国各省份部署多个探测点,并且探测点接入不同的运营商/不同的网络制式来实现对目标网站的探测。用户在配置站点监控任务时,可以指定具体的省份和运营商,系统根据用户配置进行探测任务的分配,各个探测点执行具体的探测任务,并且把数据回传到监控系统。如图2所示为部署在北京的探测点列表;如图3所示为回传数据模型。

640?wx_fmt=png

图2  北京市探测点分布示意图

640?wx_fmt=png

图3  站点监控数据模型示意图

站点监控的架构如图4所示,分为业务端、数据通路和采集通路三个部分。其中,业务端负责任务管理和采集指标查看;数据通路负责采集指标数据的转发、存储、计算以及对指标的异常检测;采集通路中任务调度模块负责管理当前所有的探测点及探测Agent信息,并将站点监控业务端下发的监控任务分配到具体的Agent执行;探测Agent执行具体的监控任务并将数据回传至站点监控系统。

640?wx_fmt=png

图4  站点监控架构图

系统的高可用,主要体现在系统可单实例故障容灾,系统可动态扩展上(参看:https://en.wikipedia.org/wiki/High_availability)。

在站点监控系统中,业务端为无状态服务,以集群方式

采集通路中任务调度模块为有状态服务,以主备方式部署满足系统的高可用;探测点和探测Agent作为探测任务的执行单元,对保障站点监控任务的高可用至关重要:

  • 一方面需要考虑一个探测点下单个探测Agent的容量问题,当单个探测Agent执行的任务数量已超过该Agent最大容量负载时,需要能够将多出的任务负载均衡到其他的Agent;

  • 另一方面,需要考虑单个探测Agent故障情况,单个Agent故障时,需要将任务迁移到属于同一探测点的其他Agent上。

我们会在每个探测点(即每个省份、运营商、网络制式)下部署多个探测Agent,用于支持探测点的高可用保障需求,具体方案如下:

  • 任务均衡分配&容量可扩展

任务分配采用哈希环算法,利用一致性哈希的平衡性、分散性、平滑性的特点可保证任务均衡分配。针对每个探测点(属于同一个省份+运营商+网络制式下的探测Agent属于同一个探测点)下所属的Agent构建一个哈希环,使用AgentID(每个Agent分配的全局唯一的ID)作为节点的Key,将任务按照“一致性哈希”的方式平均分配到每个探测Agent上,如图5所示。

640?wx_fmt=png

图5  基于一致性哈希的任务分配

  • 探测Agent故障容灾

Agent通过定期心跳信息来上报健康状态。任务调度模块定期检查每个探测Agent上报的心跳时间戳,当心跳时间戳与当前时间差值超过一定阈值,则判定该Agent宕机。

当Agent被判定为宕机后,任务调度模块会将Agent从所属的探测点哈希环中摘除,并根据一致性哈希策略将此宕机Agent上的任务分配至其他探测Agent。

本文从技术角度介绍了站点监控的实现方案,其中,以HTTP探测为例说明如何支持多种探测任务(协议)、多种监控指标采集;在系统高可用方面重点介绍如何解决探测任务均衡分配和探测点故障容灾两个问题。站点监控通过从探测点发送模拟真实用户访问的探测请求,实时获取监控目标的响应时间、DNS解析时间、可用性等信息,为网站的稳定运行保驾护航。

大家对站点监控如有任何疑问,可以直接后台联系我们,欢迎各位一起交流探讨~

640?wx_fmt=jpeg

640?wx_fmt=gif

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章