Кратко

  • Если остановился только сборщик, работающий измеритель может сохранить накопленный объём. Восстановление зависит от сохранности записей и сопоставимости показаний.
  • Пропущенные чтения оставляют пробел во временной картине. Позднейший итог не показывает, когда внутри этого пробела возникали всплески нагрузки.

Возвращение к счётчику

Представим гипотетический сбой: программа сбора перестала читать таблицу, а измеритель продолжает наблюдать пакеты и увеличивать счётчики. После перезапуска сборщик получает новые накопленные значения. Если прежние записи сохранились и показания сопоставимы, разность между новыми и последними успешно полученными показаниями позволяет восстановить прирост объёма за паузу. Именно такой случай рассматривает RFC 2063 в § 2.5.

Однако между двумя чтениями мог идти ровный поток или случиться короткий всплеск. По одним итоговым значениям выбрать между этими картинами нельзя. Это аналитическое следствие пропуска наблюдений, а не рассказ о зарегистрированной аварии: среднюю скорость за весь промежуток ещё можно вычислить, распределение нагрузки внутри него уже не наблюдалось.

У каждого компонента своя часть истории

RFC 2063 вышел в январе 1997 года. Его авторы — Nevil Brownlee, Cyndi Mills и Greg Ruth; в документе указаны The University of Auckland, BBN Systems and Technologies и GTE Laboratories, Inc. Для истории IETF существенен его статус Experimental: это экспериментальная архитектура, не стандарт Интернета. В § 1 авторы также оговаривают, что документ структурирует информацию, требования и компромиссы реализации, а не задаёт протокол обмена. Основание: RFC 2063, вводная часть и § 1.

Учётный поток здесь создаётся правилами: наблюдаемые признаки независимых IP-пакетов определяют, в какую запись попадёт трафик. У потока есть начало, окончание и субъект учёта — например, узел, сеть или группа. Такой субъект не обязательно является удостоверенным плательщиком. В схеме RFC каждый пакет учитывается ровно в одном потоке; пересекающиеся аналитические представления требуют достаточно подробных непересекающихся групп и последующей обработки. Определение потока и правила подсчёта: §§ 2.1 и 3.

Измеритель выборочно фиксирует активность и хранит таблицу с накопленными количествами пакетов и байтов. Сборщик переносит данные для анализа. Управляющий компонент задаёт правила потоков, детализацию, параметры таблицы и выборки, а сборщику — измеритель, периодичность, нужные потоки и атрибуты. Эти роли могут находиться на одной машине. RFC 2063 предусматривает одного управляющего для каждого измерителя или сборщика в данный момент; читать всю таблицу, отдельные строки либо атрибуты можно без согласованных моментов сбора. Распределение функций: §§ 2.1–2.4.

Что именно удаётся восстановить

Правила измерителя входят в смысл показаний, поэтому им нужен Rule Set ID. Вместе с идентичностью измерителя и временем начала потока он помогает отличать продолжающуюся запись от новой записи с теми же адресами. Сравнивать счётчики через смену этого контекста без дополнительных оснований нельзя. RFC рекомендует накапливать значения, а не обнулять их при чтении: повторно полученные итоги описывают состояние, их нельзя складывать как новые порции трафика. Ещё одно ограничение — оборот счётчика, способный сделать прирост неоднозначным. Правила и накопительные значения: §§ 3.2–3.3.

Измеритель сохраняет времена первого и последнего пакетов потока. Сборщик записывает идентичность измерителя, отметку времени, идентификатор правил сбора, описание потока и счётчики; записи хранятся в дисковых файлах по измерителям. Эти данные позволяют привязать показания к наблюдаемому состоянию. Но отметки первого и последнего пакетов не заменяют пропущенную последовательность чтений: восстановить по ним внутренние пики нельзя. Последнее — вывод о пределах информации, которую хранит описанная схема. Состав данных: §§ 3.2 и 5.2.

Два сборщика и конечная память

Резервные измерители на одном сегменте защищают от отказа измерителя; резервные сборщики — от перерывов в сборе. Даже при одинаковой периодичности асинхронные сборщики могут читать в разные моменты и получать разные итоги. Само расхождение не доказывает повреждения данных. Складывание перекрывающихся накопительных записей, напротив, способно повторно учесть тот же трафик. Асинхронное резервирование: § 2.5.

Память ограничивает длительность восстановления. По § 3.2 неактивную запись до освобождения должен получить хотя бы один сборщик. В § 4.5 обсуждаются LastCollectTime и удержание записей, но порядок удержания для нескольких сборщиков оставлен для дальнейшей проработки. При заполнении таблицы рассматриваются более грубые резервные правила и учащение сборов; ради продолжения измерений возможна краткая потеря данных. Поэтому переживший сбой измеритель не обещает бессрочно хранить всё для отсутствующего сборщика. Удержание и перегрузка: §§ 3.2, 4.5–4.6 и 5.3.

Где заканчивается версия 1997 года

Современный ей экспериментальный RFC 2064, также опубликованный в январе 1997 года, описывает MIB измерителя. Независимые сборщики обходят таблицу без общего состояния обхода; TimeFilter и GetBulk помогают получать изменившиеся строки и нужные атрибуты. Регистрация сборщиков, времена последнего и предыдущего сбора используются при освобождении памяти, а flowReaderTimeout позволяет удалять просроченную регистрацию. Здесь уже различается главный управляющий. Важно, что проход начинается записью flowReaderLastTime: эта отметка не удостоверяет завершённый атомарный снимок всей таблицы. Ошибка записи или аутентификации может мешать освобождению памяти, хотя чтение продолжается. RFC 2064 уже рассматривает приближение к снимку посредством переключения правил на одном измерителе. Механизм сбора: RFC 2064, § 3.2 и определения MIB.

В октябре 1999 года RFC 2722 со статусом Informational заменил RFC 2063, сохранив оговорку об утрате временной детализации при отказе сборщика. Он уточнил ожидание всех зарегистрированных сборщиков перед освобождением записи и исключение просроченного сборщика, а также работу нескольких наборов правил и управляющих. RFC 2722 подробно описал чередование двух одинаковых наборов правил на одном измерителе, позволяющее сборщикам получать одинаковые записи завершившего работу набора. Одновременное переключение нескольких измерителей не гарантировалось. Эти уточнения нельзя приписывать всем системам 1997 года. Позднейшая редакция: RFC 2722, §§ 2.5 и 4.5.

Предел восстановления и предел утверждений

При отказе управляющего измерения и сбор должны продолжаться. Перед контролируемой остановкой измерителя можно запросить последнее чтение; после внезапного перезапуска отказ может обнаружиться уведомлением или опросом, затем восстанавливаются правила. Повторная загрузка конфигурации не возвращает исчезнувшее состояние или неизмеренный трафик. Архитектура не гарантирует ни доставку уведомления, ни подтверждение его подлинности. Различия отказов: RFC 2063, § 6.3.

Архитектура допускает SNMP, не закрепляя единственный транспорт; целостность и конфиденциальность оставлены протоколам управления и сбора. Тарифы и возмещение затрат вынесены за рамки. Учёт объёма сам по себе не устанавливает действительность счёта, полезную доставку или оплату. Публикация документов не доказывает распространённости внедрений либо совместимости продуктов. Границы архитектуры: §§ 1, 5.3 и 10.

В позднейших эссе Lu Heng различает публикацию схемы и её наблюдаемую работу, минимум общих правил и локальные решения, описание устройства и поддержку определённой позиции. Применительно к измерениям это лишь позднейшая авторская рамка для оценки общего смысла данных и выбранного порядка сбора. Эти взгляды не свидетельствуют о внедрениях 1997 года или намерениях авторов RFC.

Источники