摘要

  • 2026 年 11 月 8 日，RIPE NCC 的 RIS Looking Glass 数据库碰到配置中的 32k 文件描述符上限。处理查询的内部 API 随即占满全部可用处理槽位，Looking Glass、RIS Peers 等多项 RIPEstat API 无法使用。
  • 数据库与 API 当天下午恢复，但 BGP 消息还要补播。20:06 UTC 的通报称 RRC25 约十分之一的 peer 仍有延迟；次日 05:00 UTC 左右的恢复时间只是预计。本文截稿时，事故状态仍为 Monitoring。

一道 32k 的门槛，堵住了不止一扇门

路由观测平台被自己的文件把手数卡住，听起来像机房笑话，却是 RIPE NCC 事故记录写出的因果链。RIS Looking Glass 所用数据库耗尽文件描述符；配置上限是 32k。随后处理 Looking Glass 请求的内部 API 占满全部可用处理槽位。故障从一个数据库边界扩散到多个公众查询入口，Looking Glass、RIS Peers 及其他 RIPEstat API 一并不可用。

“32k”不是受影响路由、用户或 peer 的数量，而是该数据库的配置限额。公开通报没有给出当时的句柄使用曲线、请求峰值，也没有说明为何采用这个数值。已确认的事实足够尖锐：一个局部配额耗尽后，共用处理槽位成了放大器。平台负责观察网络，平台自身的容量分隔却决定了读者还能否看见这些观察。

通报还暴露了时间线。RIPE NCC 说首张用户工单到于 8 日 00:58 UTC；公开调查通知发布于 12:51 UTC。两者相距 11 小时 53 分钟，但首张工单时间不能直接当作所有接口的故障起点。13:20 UTC，机构确认文件描述符与处理槽位的链式故障；13:39 UTC 则宣布数据库已恢复、API 吞吐接近正常。公众最先拿到的是一张恢复服务的收据。

接口醒了，数据还在赶路

第二张收据更难写。13:39 UTC 的更新同时指出，Looking Glass 正补播过去数小时的 BGP 消息，结果会滞后。RIPE NCC 的 Looking Glass 文档将其定位为接近实时的 RIS 数据视图，按采集器和 peer 组织，还提供 latest_time 等时间字段。查询能返回，与返回的是足够新的观察，是两件事。

到 20:06 UTC，机构仍称 RRC25 约十分之一的 peer 因消息量大而延迟。它预计次日约 05:00 UTC 追上，并承诺再更新；当时没有发布完成时间。RIS Peers 接口文档也把数据按采集器列出，历史查询对齐 00:00、08:00 和 16:00 UTC 的采集点。这些设计本来就要求读者看采集器、peer 与观测时间，不能只看 API 是否亮绿灯。

这起故障落在 RIPE NCC 的路由观测与查询服务。机构先修复了回答问题的窗口，再让窗口后面的证据追上当下。一个是可用性，一个是新鲜度。11 月 8 日，它只给前者提供了明确的恢复通报。