Некоторые экспортеры IPFIX избегают этой проблемы, используя новые абсолютные поля временной метки, такие как flowStartSeconds (150), flowEndSeconds (151). Существуют варианты для миллисекундной точности, микросекундной точности и т. Д. См: http://www.iana.org/assignments/ipfix/ipfix.xhtml
(Кроме того, обратите внимание, что абсолютная отметка в заголовке IPFIX должен быть близок к тому, когда пакет был фактически завершен и отправлен, так что вы по крайней мере, есть шанс при моделировании часы смещения между экспортером и ваш коллектор: https://tools.ietf.org/html/rfc7011#page-14)
Но, как вы отмечаете, проблема возникает тогда, когда экспортер IPFIX отправляет наследие поля flowEndSysUpTime (21) и flowStartSysUpTime (22). Это было нормально для NetFlow v1-9, потому что временная метка заголовка также была выражена в sysUpTimeSeconds, но с IPFIX она оставляет вас в затруднении.
Одно простое решение состоит в предположении, что потоки всегда продувают быстро, вычислить их продолжительность, и выровнять их с ТЕПЕРЬ:
duration = flowEndSysUpTime - flowStartSysUpTime
start = (NOW - duration)
end = NOW
Другой подход заключается в предположении, что по крайней мере некоторые потоки смываются быстро и поддерживать оценку для каждого устройства времени загрузки, используя номера flowEndSysUpTime:
boot-time = MIN(NOW - flowEndSysUpTime)
start = boot-time + flowStartSysUpTime
end = boot-time + flowEndSysUpTime
но тогда вы должны быть осторожны, чтобы обнаружить изменение шага в вашей оценке для загрузки времени, если деви ce фактически перезагружается. И это изменение шага может составлять ~ 30 секунд, если оно будет перезагружено дважды подряд. Что-то о чем подумать - но поскольку эти унаследованные поля только точные до 1 секунды, неясно, что быть умным стоит того.