本帖最后由 FYIRH 于 2020-12-6 23:34 编辑
首先,Borgmon实例的配置文件中配置了需要收集的目标列表,目标位置可以使用各种地址解析服务支持的格式。这个目标列表通常是动态变化的,所以一套服务发现体系可以降低监控系统的配置维护难度,允许监控系统自动扩展。
Borgmon 按照配置规定的周期,定时抓取/varz URI。将得到的信息解码,存储在内存中。Borgmon 能够自动将每个目标的收集工作均匀地分散在整个周期内。在多级 Borgmon的配置中,这样做可以避免上游 Borgmon总是在同一个时间间隔抓取下游 Borgmon的信息。
Borgmon同时还为每个监控目标记录了一些自动生成的"合成指标",以便区分以下几种情况∶ ● 目标地址是否成功解析为IP 和端口。 ● 目标是否响应了一次收集请求。 ● 目标是否响应了一次健康检查请求。 ● 数据收集成功结束的时间点。
这些自动生成的监控指标,可以用在检测被监控任务不可用状态的规则编写中。
很有趣的一点是,varz 体系和SNMP(简单网络监控协议)非常不同。SNMP协议在设计中需要最简单的传输协议支持,保障在其他网络应用失败的时候也能正常工作(参见文献【MicO3】)。利用 HTTP协议收集监控信息好像和这个设计理念正好相反。但是,实践经验告诉我们这不是一个问题。"整套监控系统已经可以很好地应对网络和物理服务器故障,同时Borgmon还允许开发者使用上文提到的合成监控指标写出更好的报警规则。
时间序列数据的存储 一个服务通常由很多软件服务器组成,运行在分布于很多集群的物理服务器上。Borgmon 需要将所有收集到的信息统一整理存储,同时允许灵活地查询相关数据。
Borgmon将所有数据保存在一个内存数据库中,定时保存到硬盘上。这些数据都是以类似(timestamp,value)的格式存储在一个按时间排序的链表里,该链表称为 Time-series。同时,每个time-series 链表用一组唯一的标签命名(name=value)。
如图10-1所示,一个time-series 链表实际上是一个单维数字矩阵,以时间为Y轴。当我们给time-series 加上各种标签时,这个矩阵就变成多维矩阵了。
在实际实现中,这个数据接口存放在一个固定大小的内存块中,我们称之为 time-series 存放区(arena)。time-series 存放区存满后,同时有一个垃圾回收器,将过期的数据从内存中清除。time-series中最老和最新的数据间隔称之为数据地平线距离(horizon)。数据地平线距离代表了在内存中存放了多久的历史数据可供查询。通常情况下,数据中心和全局 Borgmon中一般至少需要存放12 小时左右的数据量,以便渲染图表使用。下游的数据收集 Borgmon,可以存放得更少。每一个数据点大概占用24字节的内存,所以存放100万个time-series,每个time-series每分钟一个数据点,同时保存12小时的数据,仅需17GB 内存。
Borgmon 会定时将内存状态归档至一个外部数据库(TSDB)。Borgmon可以通过查询TSDB 获取历史数据。虽然TSDB容量要比 Borgmon内存更便宜,也更大,但是查询速度会更慢。
|