Кратко

  • В уведомлении от 20 октября RIPE NCC разделил влияние задержки на разные точки RIPEstat и пояснил, что метаданные Looking Glass указывают на максимальное запаздывание среди имеющихся данных.
  • Запрос, выполненный в 18:04:43 UTC, вернул время последних данных 12:13:37 UTC. Это один снимок для одного ресурса, а не оценка всех пиринговых узлов, ресурсов или API.

Документация Looking Glass описывает поток данных RIS как обычно близкий к реальному времени, хотя и с небольшой задержкой. При этом для маршрута различаются два момента: когда он изменился в последний раз и когда был подтверждён в последний раз. Эти значения не взаимозаменяемы. Точка API также позволяет ограничить период поиска; по умолчанию записи старше 24 часов не возвращаются. Поэтому отсутствие строки нельзя сразу считать доказательством того, что маршрута не было. Сначала нужно знать фильтр и окно наблюдений.

Один запрос в реальном времени позволяет ограниченно проверить, что именно возвращает API. В 18:04:43 UTC Looking Glass RIPE NCC успешно ответил и отметил, что результат не взят из кэша. Время запроса составляло 18:04:43, а время последних данных — 12:13:37. Разница — пять часов, 51 минуту и шесть секунд. В ответе было 23 группы коллекторов и 345 записей пиринговых узлов. Сводное время описывает актуальность, которую показывает эта точка API; оно не доказывает, что все 345 записей имели одинаковый возраст. Этот единичный замер ничего не говорит о другом префиксе, другой точке API или всей сети RIPE NCC.

У RIPEstat нет единого «часового механизма» для актуальности всех данных. RIPE NCC сообщил, что Looking Glass должен показывать актуальные сведения для большинства пиринговых узлов — более 90%, — а метаданные при этом указывают на наибольшую задержку в имеющемся наборе. Эти утверждения не противоречат друг другу. Большинство записей может быть свежим, тогда как меньшая часть отстаёт; поле максимальной задержки показывает этот хвост, но не возраст каждой строки. RIPE NCC не публиковал универсальную гарантию актуальности или единый порог, который определял бы, когда каждый узел считается актуальным.

Новый запрос может завершиться успешно, но вернуть более старые наблюдения. Панель мониторинга легко скрывает эту разницу, если показывает только успешный ответ API, время запроса или единый статус сервиса. 20 октября RIPE NCC обозначил два отдельных факта: часть данных RIPEstat задерживалась из-за проблемы в Routing Information Service (RIS), а степень влияния зависела от конкретной точки API.

Различие важно, потому что RIPEstat одновременно служит публичным интерфейсом данных и источником данных для собственных виджетов и пользовательского интерфейса. API — это не одна таблица с единым графиком обновления. Каждая точка отвечает на свой вопрос. В документации RIPE NCC называет несколько факторов актуальности: периодичность сбора, обычное расписание обновления хранилища, задержка обработки, штатная работа сбора и обработки, а также кэширование. Успешный ответ подтверждает, что запрос получил ответ. Он сам по себе не говорит, когда было собрано каждое исходное наблюдение.

Отдельное уведомление о RIS показывает, что речь идёт о задержке в цепочке обработки данных, а не о сбое маршрутизации. RIPE NCC сообщил о проблеме при копировании BVIEW-файлов из хранилища и задержке обработки сообщений, собранных в RRC25. В том обновлении говорилось, что новые BVIEW-файлы публикуются, кроме файлов RRC25; также задерживались файлы обновлений RIS. Уведомление о RIPEstat связано с этим событием и предупреждает о разном влиянии на отдельные точки API. Ни одно из двух уведомлений не утверждает, что маршруты исчезли из Интернета или клиенты потеряли доступность.

Практический шаг прост: сохранять время данных рядом со временем запроса. Для решения на основе RIPEstat нужно записывать точку API, ресурс, время запроса, время последних данных, состояние кэша и охват ответа. Затем возраст данных следует сопоставить с допустимым интервалом для конкретного решения. Наблюдение с задержкой в пять часов может подойти для исторической тенденции, но быть слишком старым для автоматического действия. Порог задаётся сценарием использования, а не универсальным цветом на панели.

Уведомление RIPE NCC полезно именно потому, что не сводит инцидент к одной цифре. Оценка «более 90%» даёт общее представление о сервисе, а метаданные показывают максимальную задержку. Пользователю не нужно решать, правдиво ли уведомление. Нужно понять, достаточны ли конкретная точка API и окно наблюдения для принимаемого решения. Разделение этих проверок сохраняет ценность данных и не заставляет их доказывать то, чего они не показывают. Первоисточники: инцидент RIPEstat у RIPE NCC, инцидент RIS у RIPE NCC, документация RIPEstat Data API, документация точки Looking Glass, Что такое RIPEstat?, ответ API Looking Glass с временными метками и документация RIS-коллекторов.