★ FEATURED ARTICLE 一、为什么要盯住 Transfer监控链路里最容易丢数据的一环凡是维护过自建监控系统的人大概率都被同一个问题折磨过数据明明从 agent 发出去了图表上却出现了断点等到想排查的时候几个小时前的原始数据已经无迹可寻。这类问题在最开始部署 OpenFalcon 的时候还不明显一旦 agent 数量上了规模、上报频率拉满Transfer 就成了整条链路里最脆弱、也最容易被忽视的瓶颈。我先把这条链路捋一遍agent 采集数据后通过 HTTP 或 RPC 方式上报给 TransferTransfer 在内存里做短暂缓存再按固定周期批量转发给后端的 Graph用于历史存储、Judge用于告警判断等组件。也就是说Transfer 是所有监控数据的汇聚点像个快递中转站所有包裹都得从它手上过一遍。问题就在这里中转站如果只靠内存缓存一旦进程崩溃、机器重启队列里还没发出去的数据就会全部蒸发而且没有任何找回的余地。有人可能会说那后端 Graph 有数据不就够了吗只要最终图表是完整的中间环节丢失几百条又能怎样。这话放在业务量小的时候确实没毛病但监控系统的价值恰恰体现在故障那一刻。线上真的出了事你急需要靠历史数据回溯的时候发现某个关键指标在故障前出现了一段空白而这段空白恰恰就是问题开始的时间窗口——那种感觉经历过的人都懂。所以“多重备份”这件事我个人的看法是它不是给 Transfer 单纯加几个副本就完事而是要围绕 Transfer 建立一整套冗余机制覆盖进程层面、数据层面、后端链路层面每一层都能独立扛住一部分故障场景。本文会把我实际部署和调整过程中的方案、配置、踩坑经历全部梳理出来对正在用 OpenFalcon 的人或者正在设计类似监控数据管道的朋友应该能省掉不少弯路。二、Transfer 的原始工作模式以及它天然存在的四个风险点动手做备份之前先得把 Transfer 本身的行为模式摸清楚。它不是一个复杂的组件但正是这种简单结构让我们在设计备份方案时有了比较从容的操作空间。2.1 一次数据上报在 Transfer 内部经历了什么在一个典型的 OpenFalcon 部署中agent 每分钟向 Transfer 上报一次数据每个数据点就是一个 Key-Value 结构包含了 metric、endpoint、tags、timestamp、value 这些字段。Transfer 收到数据后先把它们扔进内存里的一个队列队列按照后端目标来区分比如要发给 Graph 的数据排成一队要发给 Judge 的数据排成另一队。Transfer 内部有个后台协程在干一件事每隔一段时间通常是 1 秒左右把队列里积攒的数据打包批量发往各个后端。这个批量发送机制是性能的关键因为如果每来一条数据就同步转发一次TCP 连接的建立成本和多次 I/O 的开销会瞬间拖垮整个转发能力而批量聚合后能显著提升吞吐量。等后端返回成功应答后Transfer 才把对应的数据从内存队列中移除。整个过程其实就是一个内存缓冲加批量转发的经典模型模型简单收益也直接。但是这种模型的隐患也体现在“先收应答、再删缓存”这个逻辑上——如果 Transfer 在等待应答期间崩溃或者后端长时间没有响应数据就一直压在内存里进程一退出就什么都没了。2.2 四个最容易出问题的场景我把实践中遇到过的风险归纳成四类每一类都值得在设计备份时单独考虑。第一类Transfer 进程本身异常退出。最常见的是 OOM内存溢出。监控系统跑得越久内存队列里积压的数据可能就越多如果接收速率短时间激增内存占用就会快速爬升触发系统 OOM Killer。进程被强杀内存队列直接清空未转发的数据一条不剩。还有一种情况是代码缺陷导致的 panic或者人为误操作kill -9结果同样致命。第二类后端组件不可用。Graph 或 Judge 所在的机器磁盘满了、服务挂了、网络分区了Transfer 往它们发送数据时会一直报错数据在内存队列里不断堆积。如果这个状态持续几分钟Transfer 的内存会涨得非常快最终反噬自身。很多人在这种场景下会发现一个尴尬的事实后端组件有备份但 Transfer 的内存缓冲区并没有考虑到后端故障的兜底能力。第三类网络抖动与延迟导致的重试风暴。Transfer 发送数据时如果遇到超时会尝试重发。网络抖动越频繁Transfer 积压的任务就越多处理不过来的时候老数据还没发出去新数据又涌进来。数据最终虽然可能发出去但已经产生了分钟级的延迟监控告警因此失真。第四类人为误操作或配置变更时的数据黑洞。比如后端地址配错、某个后端被临时下线、扩容时改配置忘记重启等。这类问题最气人因为数据看起来一切正常实际上全部发到了错误的地方等你发现的时候历史监控数据又缺了一段。正是这四个场景促使我下决心给 Transfer 做多重备份。这里的“备份”不是事后导一份数据文件那么简单而是在数据流转的每一个关键节点上都留出一份可以独立恢复的冗余副本。三、多重备份的整体架构三份副本、四个层次、进退有据备份方案在动手之前先在纸上画清楚架构比急着写代码重要得多。我实际采用的是“三副本、双链路”的思路这里把整体设计讲透后面的配置和操作都围绕这个架构展开。3.1 备份层次的划分逻辑我把 Transfer 的数据备份划分成四个层次每个层次解决一类故障场景第一层Transfer 进程级冗余。部署多个 Transfer 实例用统一的虚拟 IP 对外提供服务任何一个实例宕机流量自动转移到其他实例。这一层解决的是单点故障问题相当于给中转站准备了几条平行的传送带。第二层接收入口的数据旁路备份。在 Transfer 接收数据的入口处把上报的原始数据包实时记录一份到本地磁盘或远程存储。这一层解决的是“后端全挂、Transfer 进程内存清空”这种极端但真实存在的场景。你已经把数据收上来了那么无论后续发生什么原始数据都有一份落袋为安。第三层转发的双后端副本。让 Transfer 同时把数据发送给两个后端链路一份走主用 Graph一份走备份存储。这一层解决的是数据到达后端之后、主后端数据损坏或丢失的问题。两个后端互不影响任何一个挂了另一个还能提供完整的查询能力。第四层定期快照归档。从备份存储中定期导出离线文件打包归档。这一层主要是为了应对“整个 OpenFalcon 集群不可用”的灾难场景比如机房断电、集群被人为误删等。产生这个想法是因为之前我遇到过一次误删数据库的事故因为没有离线归档最后只能干瞪眼。这四个层次叠起来数据在整个生命周期里始终保有至少两份在物理上相互隔离的副本。任何单点故障发生都能从另一份副本里把数据找回来。3.2 一份数据从采集到归档的完整备份路径按照这个设计一份监控数据的标准流转路径变成了这样agent 采集数据后先写入本地一个小的磁盘缓冲队列然后上报到 Transfer 集群的虚拟 IP某个 Transfer 实例接收数据之后在前置逻辑里把原始数据包同步写入共享的磁盘目录或者远端对象存储然后再进入自己的内存转发队列Transfer 正常转发数据给主 Graph 的同时还通过一个独立的转发器把同一份数据发送给备份存储最后备份存储里的数据会被定期导出为离线文件归档到冷存储中。那这个路径里就有三份完整副本了agent 侧本地缓冲里的那份、Transfer 入口落盘的那份、备份后端里的那份。主 Graph 里的数据算第四份但它主要承担查询职责不算严格意义上的备份。3.3 为什么没有选择直接改 Transfer 源码的方式聊到这一步肯定有朋友会问这些能力 OpenFalcon Transfer 原生不都带吗直接改源码或者官方有支持的话配上不就行了我最初也是这么想的但仔细评估后放弃了这个思路。有两方面原因一是 Transfer 的内存队列模型决定了它本身没有本地持久化能力要在不破坏原有逻辑的情况下加一层磁盘缓冲侵入性太强后续升级维护成本很高。二是 OpenFalcon 这个项目已经到了比较成熟的维护阶段改动核心组件源码会带来很大风险一旦出问题很难判断是备份逻辑的锅还是原逻辑的锅。所以我的原则是能不碰 Transfer 源码就不碰尽量在原组件的入口和出口做无侵入的外挂式设计。这个原则贯彻了整个方案代价是代码量稍多一点但换来了非常高的可维护性而且换一个监控系统这套思路照样能迁移过去。四、第一层和第二层实战多实例高可用与入口落盘备份的完整配置搞清楚了整体架构细节才有意义。这一节讲前两层怎么落地涉及具体的部署架构和代码设计属于可以直接照着操作的部分。4.1 多实例部署与虚拟 IP 的平滑切换Transfer 多实例部署本身不算复杂按官方文档把多个 Transfer 进程跑起来agent 端配置一个统一的入口地址就行。但具体到入口怎么统一有几个选型我把它们的优缺点对照列在下面方案优点缺点DNS 轮询配置简单agent 无感知DNS 缓存导致切换不及时故障实例无法快速摘除LVS / HAProxy负载均衡能力强故障摘除快需要额外维护一套负载均衡组件Keepalived VIP配置直观故障自动切换需要处理 ARP 问题切换耗时取决于检测参数我采用的是 Keepalived VIP 方案两个 Transfer 实例一主一备共用一个虚拟 IP。Keepalived 的配置里最关键的是健康检查脚本。默认的 ICMP 检查用处不大因为 Transfer 进程活着不代表它还能正常处理数据。我写了一个脚本每两秒探测一次 Transfer 的 HTTP 接口只有返回数据正常才判定为健康否则就触发 VIP 漂移把入口切换到备用实例。有一点必须提醒进程级冗余解决的是“单实例宕机”的问题但解决不了“两个实例全部宕机”的问题所以它必须跟第二层的落盘备份配合使用否则毫无意义。另外启动多个 Transfer 实例时agent 采集任务的分布会自动均衡吗坦白说OpenFalcon 的 agent 并不感知 VIP 背后有多少个实例它只知道自己连的是一个地址所以负载均衡完全由 VIP 这一层来完成。如果某一天某个 agent 的上报量特别大也不会影响其他 agent因为入口是统一的。4.2 入口落盘备份不碰源码的前置旁路设计这一层是整套方案的核心。我花了比较多的时间设计它的实现方式因为它必须做到两件事一是不能影响 Transfer 原本的接收流程二是写入磁盘的速度要够快不能拖慢数据链路。我最终的做法是加了一个轻量级的前置接收组件名字随意内部代号叫“数据收集备份器”。agent 上报的地址从原来的 Transfer 直接地址改成了这个前置组件的地址前置组件收到数据后做两件事先把原始数据包完整地追加写入本地磁盘文件按小时切分文件名包含时间戳然后把同一份数据转发给 Transfer 的 VIP 地址。数据转发用的是异步非阻塞模型写入磁盘也是顺序写整体额外开销很小。这里有一个细节很关键磁盘写入不能采用“先写缓存、后批量刷盘”这种常见的优化策略因为那相当于把数据又放回了内存临时区一旦进程卡死还是会丢。我直接用带缓冲的顺序写加fsync策略保证每条数据写入后至少被操作系统持久化到磁盘才返回。代价是单条写入延迟稍高但实测在普通 SSD 上仍然能满足每秒钟几千个数据点的写入需求完全够用。数据文件的格式我用了最简单的二进制格式每条记录依次是数据长度、时间戳、完整的原始 JSON 数据。不搞复杂编码因为备份文件的核心诉求是“事后能解开、能恢复”过度封装反而会增加出错的概率。下面这段代码展示了前置组件里核心的磁盘写入逻辑我已经把关键注释写在了代码里import os import time import struct import threading class DiskBackupWriter: def __init__(self, backup_dir, max_queue_size50000): self.backup_dir backup_dir self.max_queue_size max_queue_size self.current_file None self.current_file_name None self.lock threading.Lock() self.buffer [] self._ensure_dir() self._rotate_file_if_needed() def _ensure_dir(self): if not os.path.exists(self.backup_dir): os.makedirs(self.backup_dir, exist_okTrue) def _rotate_file_if_needed(self): now time.time() hour_stamp time.strftime(%Y%m%d%H%M, time.localtime(now)) file_name f{self.backup_dir}/rawdata_{now}_{hour_stamp}.bin if self.current_file is None: self.current_file open(file_name, ab, buffering0) self.current_file_name file_name elif file_name ! self.current_file_name: # 每小时切一个文件方便归档和恢复 self.current_file.close() self.current_file open(file_name, ab, buffering0) self.current_file_name file_name def write_record(self, raw_data, ts): 同步写入一条记录先写长度再写原始数据。 使用 append 模式保证文件位置在最后。 record struct.pack(I, len(raw_data)) struct.pack(Q, ts) raw_data with self.lock: self._rotate_file_if_needed() self.current_file.write(record) # 调用 fsync 让数据真正落盘防止进程崩溃时丢失 self.current_file.flush() os.fsync(self.current_file.fileno()) def close(self): if self.current_file: self.current_file.close()这里选择的写入方式是每记录一次fsync说实话如果是高频写入场景会明显增加磁盘 I/O 压力。所以我实际部署时留了个开关正常情况下按批次刷盘每批次最多攒 200 条或者 100 毫秒内的数据一次性刷一次。出了故障需要严格保证不丢数据时才切换成每记录必刷模式。具体用哪种取决于你对“丢数据概率”和“写入延迟”的取舍。后面踩坑部分我会专门讲这个开关该怎么调。4.3 前置组件的幂等性与转发逻辑前置组件在转发给 Transfer 时还要考虑一个问题如果 Transfer VIP 暂时不可用数据是丢弃还是缓存重发我的方案里设置了一个内存重试队列转发失败的数据会进入这个队列间隔重试三次三次都失败了才落入失败文件的备查目录。这样设计是为了面对短时抖动时不丢数据同时又不至于在长时间故障时无限堆积内存。重试队列本身也需要限制大小否则后端故障时间长了内存又会爆掉。我设置的阈值是 5 万条超过后优先丢弃最老的数据保证新的数据能进得来。这个阈值看着不大但实际运行中转移 5 万条数据也就是几秒钟的事情完全够用。大家可以结合实际的数据量调整我的经验是没必要设太大。到这里第二层备份的骨架就搭完了。有一份落盘备份数据源头的安全系数已经提高了不少。接下来要解决的是数据到了后端之后的安全问题也就是第三层的能力。五、第三层和第四层实战双后端双链路与离线归档的落地方式如果数据在 Transfer 入口就已经有了完整落盘备份理论上后端存不存备份都不影响“找回数据”这个目标。但问题在于“找回数据”是需要介入的不是自动发生的。双后端的作用就是把“自动冗余”这件事做到底让任何一条链路故障都不影响查询。5.1 Graph 主链路之外再搭一条备份存储链路OpenFalcon 生态里默认的存储后端是 Graph支撑查询和归档完全没问题。备份存储链路我用的是另一种时序存储组件通过 Prometheus 格式的写入协议接收数据。为什么不用同样的 Graph 再搭一套呢因为两个相同组件同时出问题的概率和两个不同组件同时出问题的概率差别并不大但不同组件之间能避免“同一个 bug 造成双副本同时失效”的情况。具体实现是这样的前置组件在转发数据给 Transfer 的同时把同一份数据以 Prometheus 的 remote write 格式发送给备份存储。两份数据路径完全独立Transfer 那条链路走 OpenFalcon 原生协议备份存储那条链路走 Remote Write 协议。这么做的好处很明显主 Graph 查询延迟低、生态完整是平时大家查数据的主要入口备份存储用于应急恢复、离线分析平时基本不承载查询压力所以它对性能的要求不高需要的可靠性却要高于主链路。两条链路的数据格式不同恢复时还需要做一层格式转换。这个转换逻辑我放在恢复工具里不影响主链路运行。我必须提醒一句双后端存储的成本是双份的磁盘占用会翻倍。如果数据量非常大建议在备份存储上把数据采样率调低一些。比如监控数据本来就是 1 分钟一个点备份存储可以设置成每 5 分钟采样一个点保留更长时间的粗粒度数据。这算是一种用精度换容灾空间的思路适合做长时间段的回溯分析。5.2 离线归档的具体策略与操作离线归档的目标很明确把备份存储里的数据导成文件放到和 OpenFalcon 集群物理隔离的存储上比如对象存储、单独的备份服务器。导出的粒度我选择按天导出每天凌晨跑一个定时任务把前一天的数据导出为 CSV 和二进制日志文件两种格式。CSV 是给人读的方便快速检索某一段时间某个指标的数值二进制日志文件是给恢复工具用的保留完整精度。导出的内容覆盖所有指标不做筛选因为归档目的是“全量可回溯”。归档文件的保留周期我设置的是 180 天这个周期可以根据磁盘容量灵活调整但底线是至少跨过一个完整的故障排查周期否则真出了事想查三个月前的数据发现已经清了那就很尴尬。有一点容易被忽略归档任务本身也是需要监控的。我之前遇到过定时任务静默失败、连跑了一周才发现的情况归档文件缺了一周的数据而那个时间段恰好发生了问题需要回溯数据。后来我给归档任务加了一个看门狗脚本每天检查归档目录里前一天的文件是否存在、大小是否异常。这个脚本的优先级我觉得比归档任务本身还要高。5.3 从落盘备份中还原数据的路径设计最后讲一下恢复流程。真正需要恢复数据的场景很少但准备恢复流程非常必要。我的恢复工具支持两种输入一种是前置组件的落盘原始文件一种是归档导出的二进制文件。落盘文件保留的是最原始的 JSON 数据恢复时直接取出来、按时间戳排序、重新发给 Transfer 或者直接写入备份存储归档的二进制文件则按时间范围批量转换写入备份存储后再通过查询接口对外提供。恢复流程虽然不复杂但有一个问题必须提前想好恢复的数据往往和线上正在上报的数据时间上有重叠重复写入会造成数据重复和乱序。OpenFalcon 的 Graph 对相同时间戳的数据处理方式是覆盖写所以重复写入不可怕乱序写入才需要注意。恢复工具里我做了一步时间戳重排把恢复数据按时间排序后分组再分批写入避免大批量乱序触发后端的反查逻辑。这个细节如果不处理恢复后图表上可能出现抖动排查起来非常浪费时间。到这里四层备份方案已经讲完了。从日志读取的全局视角来看这套方案相当于把监控系统的容灾能力提升了一个档次但也引入了一些新的运维负担。下一部分我把实际运行中踩过的坑和调优经验整理出来这些属于书本之外的东西。六、运行半年后的实测经验备份带来的收益、代价与几个关键调优点方案上线到今天已经跑了半年多从真实环境中积累了一些数据。这一部分不打算列一堆完美指标反而重点讲一讲备份机制带来的副作用和几个我反复调整过的参数希望能帮后来者少走弯路。6.1 备份机制带来的额外开销有多大先看收益这半年里我真实遇到过两次 Transfer 实例宕机一次是内存溢出一次是有人误操作kill -9。按照原来的架构那两次必然会造成数据缺口但因为有入口落盘备份我通过恢复工具在二十分钟内就把缺失的数据补了回去图表上几乎没有留下断点。另外还有一次主 Graph 所在机器磁盘故障因为双后端的存在备份存储直接顶上查询整个过程没有业务感知。实事求是地说数据冗余的投入在这半年里已经回本了。再看代价前置组件和备份存储加起来CPU 占用大概增加了 5% 到 8%内存占用增加了约 1GB磁盘占用按数据量翻倍算。对于监控服务器来说这些资源开销在可接受范围内。但如果你所在的机器本身配置就很紧建议优先精简指标数而不是在备份机制上缩减因为备份机制是最后一道防线它的完整程度直接决定了你能恢复多少数据。6.2 三个调优点的具体实测值第一个调优点是磁盘刷盘策略。我最初严格采用每记录必刷每秒钟只能处理大约 1500 个数据点而且磁盘 I/O 等待非常高CPU 有将近 20% 的空转。后来改成批量刷盘每 200 条或 100 毫秒刷一次每秒钟能处理 6000 到 8000 个数据点I/O 等待降了一个数量级。但是在模拟 Transfer 崩溃测试时我确认了批量刷盘确实可能丢最后攒着没刷盘的那一小批数据数量在几十条到两百条之间。我的结论是日常运行用批量刷盘数据敏感场景或大促前切回每记录必刷平时没必要追求极致可靠以免影响主链路。第二个调优点是前置组件的内存重试队列上限。一开始我设置的是 5 万条但后来模拟测试发现当 Transfer 故障超过五分钟时5 万条容量很快就满了新数据被丢弃的比例有点高。我把上限提到 20 万条后可以撑住大约八分钟的故障时间。当然这个上限越大进程 OOM 的风险也越大所以它不是越大越好。如果预计故障时间可能超过十分钟我建议改造恢复通道把超限的数据直接走备份存储那条路而不是在内存里硬扛。第三个调优点是归档的定时任务执行时间。最开始我把归档任务安排在整点零分执行但那个时间点恰好也是监控数据上报的高峰期归档任务和采集任务抢磁盘 I/O导致归档速度极慢。后来我把它挪到凌晨 4 点以后避开所有常规任务的高峰速度提升很明显。这个调整看似微不足道实际对整体稳定性的帮助不小。6.3 恢复演练比备份本身更重要最后必须强调一件事备份机制不能靠“想当然”来验证至少每两个月做一次完整的恢复演练。演练内容很简单挑一天的历史数据从落盘文件里恢复出某几个指标和备份存储里的导出数据做对比确认数值和时间点能对上。这一步看起来枯燥但它能在真正出事之前暴露恢复流程里的所有问题。坏消息是大部分人会跳过这个步骤直到真的出事才后悔好消息是你不需要成为例外。七、这套方案能给你的监控系统留下什么回到最开头的问题监控数据到底会不会丢取决于你为“不会丢”做了多少准备。Transfer 只是整条链路中的一个节点但它是最容易被忽略、也最值得加固的节点。数据到了后端还有找回的可能数据在 Transfer 这一环丢了就真的没了。我最终落地的这套多重备份机制其实没有用什么高级技术就是围绕数据流经的每个关键阶段都留一份独立、可恢复的副本。进程级冗余解决单点宕机入口落盘解决内存清空双后端解决存储故障离线归档解决灾难性场景。每一层独立工作又能互相配合最终的效果就是任何人告诉我某个时间段的监控数据丢了我都能在一个小时内把它找回来。最后分享一个我个人的习惯每次备份机制改动后都手动模拟一次 Transfer 宕机看着告警响起、VIP 漂移、恢复工具跑完心里才踏实。这套流程看起来繁琐但它保证了我对系统说的话永远算数。这套方案不一定适合所有人的环境但备份的思路和设计原则是通用的。你可以从其中某一层做起逐步把冗余补齐别等数据真丢了再动手。
阅读完成 · 觉得有帮助？
