Надеюсь, Mikrotik, возможно, пересматривает более строгое форматирование и соответствие RFC после этих публикаций много лет назад. Я думаю, инструменты удаленной логирования и анализа логов стали довольно популярными, и было бы здорово, если бы устройства Mikrotik работали как "plug-and-play". Главный мой запрос — хотя бы кодировать уровень критичности (SEVERITY) в соответствии со стандартами. Например, информация/предупреждение/критичность – они удаляются в сообщениях удаленного логирования? Я не анализировал трафик, чтобы подтвердить, что они не передаются, но надеюсь, что мой удаленный сервер логирования будет их интерпретировать, если они есть. В вики сказано, что логи соответствуют RFC 3164, но этого не происходит с простыми настройками, и я выбрал опцию BSD. Опция BSD включает некоторые параметры для уровня facility и severity, но кажется, что она позволяет только использовать значения по умолчанию. Является ли обходным путем для PRI – настройка различных действий удаленного логирования для каждого приоритета, а затем для каждой темы (или по крайней мере для основных) иметь отдельные правила для каждой темы + уровня критичности (и + facility), которые вы хотите использовать? Если да, то добавление больше информации в документацию было бы полезно. И также – тема удаляется? Добавление этой информации в вывод удаленного логирования, даже просто в MSG, а не в отдельном поле, было бы полезно. Еще одна трудность заключается в том, что некоторые логи MT форматируют события в нескольких сообщениях… по сути, используют новые сообщения в качестве разрывов строк. Таким образом, эти сообщения не имеют своего надлежащего контекста, если их просматривать последовательно и не прерывать другими логами (а на самом деле, другие службы на устройстве также могут генерировать сообщения, которые прерывают форматирование). Например, крайне важно просматривать следующие сообщения последовательно, иначе невозможно связать сообщения с интерфейсом. Таким образом, хотя форматирование и кажется "аккуратным" на устройстве, оно не является таковым по стандартам логирования сообщений и для удаленных серверов логирования. (ОБРАТИТЕ ВНИМАНИЕ: метка времени, показанная здесь, НЕ ЯВЛЯЕТСЯ ДОСТАТОЧНОЙ ДЛЯ ВОССТАНОВЛЕНИЯ ПОСЛЕДОВАТЕЛЬНОСТИ, что может сделать логи бесполезными/ненадежными!) 11:31:34 route,debug,event Изменение интерфейса 11:31:34 route,debug,event interface=host1 11:31:34 route,debug,event status=UP,RUNNING 11:31:34 route,debug,event mtu=1500 11:31:34 route,debug,event Изменение интерфейса 11:31:34 route,debug,event interface=host2 11:31:34 route,debug,event status=UP,RUNNING 11:31:34 route,debug,event mtu=1500 11:31:34 route,debug,event Изменение интерфейса 11:31:34 route,debug,event interface=host3 11:31:34 route,debug,event status=UP,RUNNING 11:31:34 route,debug,event mtu=1500 Без информации о последовательности эти сообщения легко могут потерять контекст и полезность. Но, кажется, лучше просто выводить одну строку для каждого из вышеперечисленных, тогда последовательность не нужна. 11:31:34 route,debug,event Изменение интерфейса interface=host1 status=UP,RUNNING mtu=1500 11:31:34 route,debug,event Изменение интерфейса interface=host2 status=UP,RUNNING mtu=1500 11:31:34 route,debug,event Изменение интерфейса interface=host3 status=UP,RUNNING mtu=1500 #mikrotik
