Я проверял CLI, но мы можем получить максимально возможное количество обращений (что не является показателем последнего использования политики)
Возможно, у вас могут быть вспомогательные файлы журнала только с журналами RTFLOW SESSION CREATE
Затем периодически может запускаться сценарий «Входящие» и обновлять файл с содержимым «policy-name last-наблюдаемое-timestamp»
Эти журналы также будут включены в «сообщения», но, еслибрандмауэр довольно занят и генерирует много системных журналов, мы можем потерять некоторую информацию, если junos сжимает файл сообщений из-за достижения максимального размера (если мы не запускаем скрипт очень часто… но как насчет влияния на устройство?)
Потенциально это может работать, но у меня есть некоторые опасения:
- Влияние на устройство с точки зрения производительности
- Если SRX много работает, вспомогательный файл журнала получитзаполнено быстро и выполнение скрипта будет длиннее
- Это будет работать только с «сейчас» (поскольку мы реализуем скрипт), не можетя думаю, что прошлое
- Требуется ведение журнала в политике (по крайней мере, сеанс init или закрытие сеанса, чем создание файла журнала с правильными сообщениями системного журнала). Альтернативно, сценарий отключен, и мы периодически получаем вспомогательный журнал.файл с внешнего сервера;таким образом мы берем на себя задачу разбора файла журнала на устройстве, поскольку вся «грязная работа» будет выполняться нашим внешним сервером (этот подход требует, чтобы наше устройство было доступно с помощью модуля SCP python, который доступен в PyEzупаковка)