DOCS ЖУРНАЛЛИСТ LOGG

Appearance

MikroTik RouterOS ​

Маршрутизаторы, коммутаторы и другие устройства MikroTik под управлением RouterOS генерируют подробные системные сообщения о работе интерфейсов, маршрутизации, Firewall, VPN, беспроводной сети, действиях пользователей, изменениях конфигурации и состоянии самого устройства.

Централизованная отправка этих сообщений в LOGG позволяет хранить историю работы оборудования, искать события сразу по всей сети, анализировать их последовательность и сопоставлять журналы MikroTik с событиями других компонентов инфраструктуры.

Что можно собирать ​

RouterOS разделяет журналы по topics — функциональным источникам сообщений.

В LOGG можно передавать события:

  • системы и перезагрузок;
  • интерфейсов;
  • Firewall;
  • DHCP;
  • DNS;
  • BGP;
  • OSPF;
  • RIP;
  • MPLS;
  • VRRP;
  • IPsec;
  • WireGuard;
  • PPP / PPPoE;
  • L2TP / SSTP / OpenVPN;
  • RADIUS;
  • SNMP;
  • Wi-Fi;
  • LTE;
  • PoE;
  • bridge;
  • scripts;
  • watchdog;
  • NTP;
  • действий пользователей;
  • ошибок и предупреждений;
  • других компонентов RouterOS.

RouterOS предоставляет большое количество отдельных topics, что позволяет достаточно точно определять состав данных, отправляемых в LOGG.

Как устроено журналирование RouterOS ​

Конфигурация состоит из двух основных частей:

Action определяет, куда отправлять сообщения:

text
/system logging action

Logging rules определяют, какие сообщения туда направлять:

text
/system logging

Таким образом, сначала создается направление:

text
RouterOS → LOGG

а затем определяется, какие события должны использовать это направление.

Минимальная настройка ​

Предположим, LOGG доступен по адресу:

text
192.0.2.10

Создадим отдельное действие для LOGG:

text
/system logging action
add name=logg target=remote remote=192.0.2.10 remote-port=514 remote-log-format=syslog

Затем направим основные системные сообщения:

text
/system logging
add topics=info action=logg
add topics=warning action=logg
add topics=error action=logg
add topics=critical action=logg

Получаем схему:

text
MikroTik RouterOS
       │
       │ Syslog UDP/514
       ▼
      LOGG

Рекомендуемая настройка ​

Для обычного Syslog можно дополнительно определить facility и формат времени:

text
/system logging action
add name=logg \
    target=remote \
    remote=192.0.2.10 \
    remote-port=514 \
    remote-log-format=syslog \
    syslog-facility=local7 \
    syslog-time-format=iso8601

Затем определить необходимые категории:

text
/system logging
add topics=info action=logg
add topics=warning action=logg
add topics=error action=logg
add topics=critical action=logg

Для сетевой инфраструктуры можно дополнительно отправлять интересующие функциональные topics:

text
/system logging
add topics=interface action=logg
add topics=firewall action=logg
add topics=system action=logg
add topics=ospf action=logg
add topics=bgp action=logg

Набор следует выбирать в соответствии с ролью конкретного устройства.

Topics — важная особенность MikroTik ​

В отличие от простой настройки «отправлять все события до определенного severity», RouterOS позволяет строить политику журналирования по функциональным категориям.

Например:

text
/system logging add topics=bgp action=logg
/system logging add topics=ospf action=logg
/system logging add topics=interface action=logg
/system logging add topics=ipsec action=logg

Это позволяет для маршрутизатора уделить особое внимание BGP/OSPF, для VPN-шлюза — IPsec, а для коммутатора — interface и bridge.

Одно сообщение RouterOS может относиться сразу к нескольким topics.

Исключение ненужных сообщений ​

RouterOS позволяет исключать отдельные категории с помощью !.

Например, можно собирать отладочную информацию NTP, исключив подробные packet-сообщения:

text
/system logging
add topics=ntp,debug,!packet action=logg

Это полезно при диагностике, когда нужен подробный журнал работы конкретного компонента, но передавать весь низкоуровневый поток не требуется.

Фильтрация по содержимому ​

Правила RouterOS также поддерживают фильтрацию сообщений через регулярные выражения.

Это позволяет направлять в LOGG только сообщения, соответствующие определенному условию.

Например, можно создавать отдельные правила для конкретных типов событий или исключать известный информационный шум.

На первом этапе эксплуатации, однако, рекомендуется не применять слишком жесткую фильтрацию.

Сначала полезно собрать реальный поток в LOGG, определить полезные события и только затем оптимизировать политику на источнике.

Firewall ​

Особый интерес представляет журналирование Firewall.

Правила RouterOS могут генерировать журнал при помощи:

text
log=yes

или отдельного действия:

text
action=log

Например:

text
/ip firewall filter
add chain=input protocol=tcp dst-port=22 action=accept log=yes log-prefix="SSH-ACCESS "

Сообщения попадут в системный журнал RouterOS, откуда могут быть переданы в LOGG.

log-prefix позволяет добавлять собственный идентификатор:

text
SSH-ACCESS
BLOCKED-WAN
VPN-DENIED
ADMIN-ACCESS

Это существенно упрощает последующий поиск и построение правил анализа.

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

Выбор Source Address ​

Если MikroTik имеет несколько IP-адресов, для удаленного журналирования можно явно определить source address:

text
/system logging action
add name=logg \
    target=remote \
    remote=192.0.2.10 \
    remote-port=514 \
    remote-log-format=syslog \
    src-address=10.10.10.1

Это особенно полезно для маршрутизаторов с несколькими uplink и management-интерфейсами.

LOGG будет стабильно идентифицировать устройство по одному адресу независимо от текущего маршрута передачи пакетов.

Использование VRF ​

В современных версиях RouterOS 7 remote logging может работать через определенный VRF.

Например:

text
/system logging action
add name=logg \
    target=remote \
    remote=192.0.2.10 \
    vrf=mgmt

Это удобно для инфраструктуры с отдельной management-сетью.

Поддержка параметра vrf для remote logging появилась в RouterOS 7.19.

Формат Syslog ​

RouterOS поддерживает передачу журналов в BSD Syslog-совместимом формате.

Для LOGG можно использовать:

text
remote-log-format=syslog

и, например:

text
syslog-facility=local7

RouterOS позволяет использовать стандартные Syslog facilities, включая:

text
daemon
auth
authpriv
kern
syslog
user
local0
...
local7

Для сетевого оборудования удобно принять единую корпоративную политику, например:

text
Network Equipment → local7 → LOGG

CEF ​

Начиная с RouterOS 7.18 поддерживается CEF — Common Event Format.

Например:

text
/system logging action
add name=logg-cef \
    target=remote \
    remote=192.0.2.10 \
    remote-port=514 \
    remote-log-format=cef \
    syslog-time-format=iso8601

После этого необходимые topics направляются в созданный action:

text
/system logging
add topics=info action=logg-cef
add topics=warning action=logg-cef
add topics=error action=logg-cef
add topics=critical action=logg-cef

CEF особенно интересен при интеграции журналов с системами информационной безопасности и другими средствами централизованного анализа.

UDP, TCP и TLS ​

Для обычного Syslog RouterOS использует UDP.

Для CEF современные версии RouterOS поддерживают:

text
remote-protocol=udp
remote-protocol=tcp
remote-protocol=tls

Таким образом, для защищенной передачи CEF можно построить схему:

text
MikroTik
   │
   │ CEF / TLS
   ▼
 LOGG

При использовании TLS RouterOS также предоставляет возможность проверки сертификата принимающей стороны.

Важно: согласно документации MikroTik, TCP и TLS применяются для remote-log-format=cef; обычный Syslog отправляется по UDP.

Локальный журнал ​

RouterOS по умолчанию умеет хранить сообщения в оперативной памяти.

Посмотреть текущий журнал можно командой:

text
/log print

Для отдельных задач можно создавать дополнительные memory buffers или сохранять журналы на диск.

Однако интенсивное журналирование непосредственно во flash/NAND устройства следует использовать осторожно.

Для потоков вроде Firewall или Web Proxy MikroTik рекомендует учитывать износ встроенного накопителя и использовать удаленное журналирование либо внешнее хранилище.

Централизованная передача таких данных в LOGG позволяет хранить большой объем истории без расходования ресурса локального flash устройства.

Время ​

Для анализа последовательности событий все устройства должны иметь синхронизированное время.

Рекомендуется настроить NTP и проверить:

  • дату;
  • время;
  • timezone;
  • состояние NTP;
  • единый источник времени для инфраструктуры.

Для удаленного журналирования удобно использовать:

text
syslog-time-format=iso8601

Точная временная шкала особенно важна, когда LOGG сопоставляет события MikroTik с журналами серверов, приложений и другого сетевого оборудования.

Проверка конфигурации ​

Посмотреть logging actions:

text
/system logging action print

Посмотреть правила журналирования:

text
/system logging print

Просмотреть локальный журнал:

text
/log print

Проверить доступность LOGG:

text
/ping 192.0.2.10

После настройки необходимо убедиться, что устройство появилось среди источников LOGG и новые сообщения поступают в систему.

Если сообщения не поступают ​

Последовательно проверьте:

  1. Существует ли action logg.
  2. Установлен ли для него target=remote.
  3. Правильно ли указан адрес LOGG.
  4. Правильно ли указан порт.
  5. Созданы ли logging rules с action=logg.
  6. Правильно ли выбраны topics.
  7. Есть ли IP-маршрут до LOGG.
  8. Не блокирует ли трафик Firewall самого MikroTik.
  9. Не блокируется ли Syslog промежуточным Firewall или ACL.
  10. Правильно ли выбран src-address, если он задан.
  11. Правильно ли выбран VRF.
  12. Принимает ли LOGG сообщения на указанном протоколе и порту.
  13. Корректно ли настроено время.

Для первичной диагностики полезны:

text
/system logging action print detail
/system logging print detail
/log print
/ping 192.0.2.10

Рекомендуемая политика ​

Для большого парка MikroTik имеет смысл определить единую базовую политику:

text
MikroTik RouterOS
       │
       ├── NTP
       ├── стабильный source IP
       ├── info / warning / error / critical
       ├── необходимые functional topics
       ├── local7
       │
       └── LOGG

А затем расширять ее в зависимости от роли оборудования.

Маршрутизатор:

text
system
interface
bgp
ospf
warning
error
critical

VPN-шлюз:

text
system
interface
ipsec
wireguard
ppp
radius
warning
error
critical

Коммутатор:

text
system
interface
bridge
poe-out
warning
error
critical

Пограничное устройство:

text
system
interface
firewall
ipsec
bgp
warning
error
critical

Такой подход позволяет получать достаточно полную картину, не превращая централизованный журнал в неконтролируемый поток диагностических сообщений.

Массовая настройка ​

RouterOS хорошо подходит для унифицированной настройки большого количества устройств.

Шаблон журналирования может определять:

  • адрес LOGG;
  • порт и транспорт;
  • source address;
  • VRF;
  • формат Syslog или CEF;
  • facility;
  • topics;
  • фильтрацию;
  • NTP.

Политику можно адаптировать по роли оборудования, сохраняя единые принципы для всей инфраструктуры.

Что дает подключение MikroTik к LOGG ​

Сам MikroTik показывает собственные события:

text
interface down
OSPF neighbor lost
route changed
IPsec tunnel disconnected
firewall blocked connection

LOGG позволяет сопоставить их с событиями других маршрутизаторов, коммутаторов, серверов и приложений.

Вместо набора отдельных сообщений появляется последовательность:

интерфейс потерян → соседство OSPF разорвано → маршрут изменился → VPN стал недоступен → сервис перестал отвечать.

Это уже не просто журнал одного устройства, а история поведения инфраструктуры.

Множество устройств — единая картина событий.

LOGG: события, связи, влияние.