本文讲述了Certora在加入Solana基金会委托计划时,为了满足高性能和低延迟的要求,没有采用传统的监控框架,而是选择从头开始构建自己的监控“反框架”。该系统基于Unix哲学,利用小型、简单和可组合的工具处理文本数据,避免了不必要的复杂性和抽象层,实现了快速开发和部署。
构建基础设施和系统通常感觉像是在两个令人不满意的选项之间做出选择:采用每个人都在使用的大型框架,并花费数周时间学习它们的特性,或者自己构建一些东西,并面对不可避免的,关于忽略已建立和标准的解决方案的质疑。前一种方法提供了传统的舒适感;后一种方法则带来了为每个决定辩护的不适感。
当 Certora 加入 Solana 基金会委托计划 时,通过为 Mainnet 和 Testnet 设置 Solana Validator 节点,该计划的严苛要求以及 Solana 网络的高性能、低延迟特性从一开始就需要做出关键且快速的设计决策。
我们选择了不适。
并非出于顽固或对流行工具的本能不信任,而是因为传统的解决方案对于我们所需要的来说过于沉重,并且因为从头开始意味着我们可以对复杂性做出有计划的选择,而不是继承别人的。接下来是关于构建一个有意识地拒绝主流架构模式的系统的描述。
第一个非显而易见的任务是选择合适的 裸金属托管服务提供商,并附加要求避免在已经人口稠密的数据中心进行搭配,正如 委托标准 中明确规定的那样。但我们仍然希望以合理低的延迟接触到最密集枢纽中的“酷孩子”。
但是,如果延迟对日常性能至关重要,那么一个重要且经常被忽视的网络方面是连接性:你希望你的托管服务提供商不仅拥有相当数量的 upstream,而且你还关心这些 upstream 是谁;Tier-1 运营商是你要寻找的。这同样适用于 Peering:你应该在托管服务提供商的对等列表中首选 internet exchanges 和大型 peer factories。
大量的 upstream 对于网络弹性至关重要:只有一个 upstream 的提供商具有单点故障,而正确的 peering 确保减少了通往互连的 Solana 集线器的跃点。
选择合适的提供商、安装和微调 Solana validator 实际上是最简单的任务。最困难的部分是确保顺利的日常运营,这需要具有足够灵活性的安全和监控架构。传统智慧(今天几乎所有现成的解决方案都遵循)指出 数据收集代理 必须在被观察的机器上运行,并将这些数据定期发送到将数据组织到 时间序列数据库 中的主机。这是 Prometheus、InfluxDB 和 Grafana 等使用的方法。
但是,维护一个完整的 Prometheus/Grafana 栈,升级并使其安全,吸收其文档到能够快速排除问题的程度,是一项重大的任务。例如,在阅读了许多数据收集代理的文档后,我们仍然无法找到一种明确的方法来限制 数据传输的带宽,而无需 应用程序级别的流量整形器。在处理最终的 leader-scheduled slots 期间的数据爆发时,流量可预测性是一个需要牢记的重要因素。
我们最终决定编写自己的监控“反框架” 以完全放弃专用代理,并依靠 久经考验的 Unix 设施,例如 cron、logrotate 和 rsync 的 –bwlimit。数据点只是附加到远程计算机上的文件中的 JSONL;使用 flock(1) 安排对这些文件的写入以实现互斥访问。
我们完全避免在验证器机器上进行压缩:Solana 验证器的日志记录可能非常冗长,即使是最聪明的压缩算法也可能偶尔会占用大量的 CPU 周期或此类大型文件的整个核心。因此,日志和指标在轮换后保持未压缩,并未压缩发送到远程监控主机。
我们最终实施的“反框架”体现了 Unix 哲学:在文本数据上运行的小型、简单且可组合的实用程序。平面文本文档 使我们摆脱了符合 “中心”数据库模式 或二进制格式的束缚,并能够轻松地 将数据处理与数据存储分离。不需要特定的 查询语言 来推理数据,数据可以被 简单的 Python 管道 摄取,从而鼓励轻松 知识转移,而无需依赖小众查询语言专家。
即使是数据的 图形表示 也遵循相同的范例。一个使用 ChartJS 渲染仪表板并由 nginx 提供的 静态 HTML 文件 被认为 绰绰有余:

警报系统 只是一个从同一个 平面文档 中读取的脚本。警报规则 只是 Python 代码。所有脚本都由 cron 安排,因此没有真正的事件循环等待做某事,或者更糟的是,由于不可避免的 “Exception” 而容易被停止。这消除了对 用于监视监控系统本身状态的附加工具 的需求。唯一运行的系统是 nginx 和 cron。开发、测试和部署仅花费了 几天,代码总行数 少于 1000 行。
这种方法有意识地背离了避免“重新发明轮子”或“滚动你自己的”解决方案的传统工程建议。这种选择是故意的,因为采用大型新技术意味着接受别人的通用愿景,这总是会引入我们不想承诺的不必要的抽象和复杂性。相反,我们避开了复杂的框架,而赞成一种 “Unix” 哲学,即使对于 企业和任务关键型部署,它也可以成为一种可行的 系统工程 方法。
- 原文链接: certora.com/blog/operati...
- 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!