+7 495 320-55-52
- Назад
- Телефоны
- +7 495 320-55-52
- Заказать звонок
info@mikrotik.moscow
г. Москва, ул. Бакунинская, 84
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Префикс логирования — это полный бардак SUP-105353 SUP-144261. Ждём, когда MT добавит поддержку RFC 5424.

Префикс логирования — это полный бардак SUP-105353 SUP-144261. Ждём, когда MT добавит поддержку RFC 5424., RouterOS

Jotne

Guest

06.08.2017 17:49:00

Я логирую пакеты с моего Mikrotik в Splunk. Всё работает нормально, кроме одной проблемы — с категоризацией пакетов. Вот список префиксов, которые я нашёл:

certificate,debug
certificate,info
dhcp,critical,error
dhcp,debug
dhcp,debug,packet
dhcp,debug,state
dhcp,info
dhcp,warning
dns
dns,packet
e-mail,debug
firewall,info
interface,info
ipsec
ipsec,debug
ipsec,debug,packet
ipsec,error
ipsec,info
l2tp,debug
l2tp,debug,packet
l2tp,info
l2tp,ppp,debug
l2tp,ppp,debug,packet
l2tp,ppp,error
l2tp,ppp,info
l2tp,ppp,info,account
ntp,debug
ntp,debug,packet
pptp,debug
pptp,debug,packet
pptp,info
pptp,ppp,debug
pptp,ppp,debug,packet
pptp,ppp,error
pptp,ppp,info
pptp,ppp,info,account
radvd,debug
route,debug
route,debug,calc
route,debug,event
script,error
snmp
snmp,debug
ssh,debug
ssh,debug,packet
ssh,info
sstp,packet
system,e-mail,error
system,error,critical
system,info
system,info,account
upnp

Выглядит так, будто формат: модуль, уровень важности, информация, например ssh,debug,packet. Но это только отчасти правда. А что насчёт:

system,error,critical — это модуль, уровень важности, уровень важности?
system,e-mail,error — модуль, модуль, уровень важности?
ipsec — тут вообще уровень важности отсутствует
pptp,ppp,info,account — модуль, модуль, уровень важности, информация?

Почему бы просто не привести всё к единому виду: модуль, уровень важности, информация? Например:

e-mail,error, какая-то там информация

Во всех сообщениях обязателен уровень важности. E-mail должен быть отдельным модулем, а не подвязан к system. Надеюсь, кто-то займётся этим и упорядочит логи. Тогда работа со Splunk станет значительно проще.

Jo

Jotne Guest	#2 0 13.07.2018 11:50:00 По-прежнему ничего не произошло.

Jotne Guest	#3 0 18.04.2019 07:04:00 Я всё ещё жду, когда это исправят (приведут в порядок). Не должно быть слишком сложно, правда? Если в версии 6.x это невозможно, добавьте в версию 7.x ROS.

Jotne Guest	#4 0 17.06.2020 14:34:00 Вижу, что бета-версия v7 вообще ничего не исправила в формате логов.

neutronlaser Guest	#5 0 11.09.2020 02:19:00 Не думаю, что кому-то это интересно.

jarda Guest	#6 0 11.09.2020 04:29:00 Похоже на то. Но идея неплохая, мне нравится.

Jotne

Guest

11.09.2020 08:16:00

При использовании внешних инструментов для логирования, таких как Splunk, для анализа логов этот старый и неопрятный формат приносит кучу лишней работы. Я уже дважды отправлял запрос в MikroTik, чтобы они об этом знали.

pe1chl

Guest

13.01.2021 09:56:00

Я уже некоторое время назад отправил запрос на добавление функции, которая позволит получить больше контроля над логированием. Конечно, лучше всего было бы, если бы в префиксе лог-сообщения присутствовало гораздо больше деталей, возможно, даже уникальный идентификатор каждого сообщения. (чтобы не приходилось полагаться на сопоставление текста по шаблону, чтобы разделять отдельные ошибки в одной категории) Если у каждого сообщения своя уникальная категория, тогда можно было бы подавлять определённые сообщения и при этом показывать подробный вывод по какой-то конкретной категории (например, если не использовать Splunk, а только внутренний обработчик логов). Пока этого нет, я предложил добавить возможность регулярных выражений для сопоставления тем логов, но, конечно, лучше бы появились более подробные категории.

Jotne Guest	#9 0 08.12.2021 13:00:00 Все еще не исправлено в версии 7.1.

infabo

Guest

#10

02.06.2022 11:09:00

Внутри ROS все просто сваливают в один мешок и называют это «топиками». То есть никакого разделения по модулю и уровню важности нет. Но при этом, похоже, они все же разделяют модуль и уровень важности, когда логируют на syslog-сервер (см. https://help.mikrotik.com/docs/display/ROS/Log).

Jotne

Guest

#11

01.10.2022 08:02:00

В версии 7.x были небольшие изменения, но, как вы видите в списке ниже, невозможно определить уровень серьезности для каждого типа логов. Например, некоторые записи DNS просто показываются как DNS. Всё должно быть в одном формате, разделённом запятыми. Например: l2tp,ppp,info,account вместо l2tp,info. Уровень серьезности — третий или второй элемент? Посмотрите на эти два примера: system,critical,info и system,error,critical. Какие именно сообщения считаются критичными?

Взято из логов 7.5:
bridge,info
bridge,stp
dhcp,debug
dhcp,debug,packet
dhcp,debug,state
dhcp,info
dhcp,warning
dns
dns,error
dns,packet
dns,warning
e-mail,info
firewall,info
info
interface,info
ipsec
ipsec,error
ipsec,info
l2tp,info
l2tp,ppp,error
l2tp,ppp,info
l2tp,ppp,info,account
netwatch,info
ntp,warning
poe-out,info
route,bgp,error
route,bgp,info
route,ospf,info
route,ospf,warning
script,error
script,info
snmp
ssh,info
system,critical,info
system,error,critical
system,info
system,info,account
system,info,critical
upnp
wireguard,debug
wireless,info

Сделайте формат примерно таким: Модуль,Уровень серьезности,Тип,Дополнительно

pe1chl

Guest

#12

01.10.2022 09:06:00

Как я писал выше, я бы предложил добавить ещё один идентификатор, который был бы уникален для каждого сообщения. Например, 8-значное шестнадцатеричное число. Оно будет последним в последовательности. Это позволит подавлять конкретное сообщение или сопоставлять его в скрипте. Номер будет присваиваться одному конкретному сообщению и никогда не меняться. Возможно, первая цифра номера будет указывать на уровень серьёзности, затем несколько цифр — на модуль, а оставшиеся — на номер сообщения.

Jotne

Guest

#13

01.10.2022 09:41:00

Мне нравится эта идея — идентификатор в виде числа или текста. Если посмотреть на сообщения журналов Cisco Router/Firewall, у каждого сообщения есть свой ID:
%CDP_PD-4-POWER_OK
%DOT11-4-BA_FLUSH
%DOT11-6-ROAMED
%EVT-4-WRN
%HA_EM-6-LOG
%ILPOWER-7-DETECT
%LINEPROTO-5-UPDOWN
%LINK-3-UPDOWN
%LINK-5-CHANGED
%LINK-6-UPDOWN
%SW_MATM-4-MACFLAP_NOTIF
%SYS-3-HARIKARI
%SYS-5-CONFIG_I
%SYS-5-RELOAD и так далее.
Они имеют формат Модуль-Серьёзность-Тип_сообщения. Некоторые именно такие, как я и просил выше.

pe1chl

Guest

#14

01.10.2022 09:50:00

Да, большинство профессиональных систем имеют такую структуру. Например, VMS, операционные системы IBM, даже Microsoft Windows используют коды ошибок. По моему мнению, главное — чтобы номер был просто дополнением для программирования (скрипты, логирование во внешних системах и так далее), а не заменой сообщения, как это сделано в Microsoft Windows. (что-то пошло не так, код ошибки 89abcdef, который потом приходится гуглить, чтобы понять, что это вообще значит). Всегда должно быть текстовое сообщение.

Jotne

Guest

#15

01.10.2022 09:58:00

Я не очень доволен системой логирования Microsoft. Да, у каждого сообщения есть свой ID, с этим всё в порядке, но: XML выдаёт слишком большие и длинные сообщения. Стандартные логи — сложно понять, что к чему относится, и к тому же добавляют сообщение с пояснением типа: «Это сообщение было создано из-за ++++». Один и тот же текст добавляется к одному и тому же EventCode ID. Просто удлиняет сообщение, не давая ничего нового. А если на сервере с Citrix или другой мультипользовательской системой установить шведский или другой язык, то в логах появляется смесь английского и шведского…

Jotne

Guest

#16

06.11.2022 18:31:00

Лучшее решение, чтобы сделать логирование снова отличным для syslog: просто используйте rfc 5424 (выпущен в марте 2009 года). Там все модули разделены с правильными именами в нужных местах сообщения. Сообщения, которые связаны между собой, имеют одинаковый ID и так далее… Пожалуйста, MT, соблюдайте стандарты. https://www.rfc-editor.org/rfc/rfc5424

smyers119 Guest	#17 0 07.11.2022 21:13:00 В Mikrotik уже есть галочка для включения совместимости с RFC3164.

Jotne Guest	#18 0 08.11.2022 09:18:00 Откуда ты знаешь?

Znevna Guest	#19 0 08.11.2022 09:26:00 bsd-syslog (да\|нет; по умолчанию: ) — использовать ли bsd-syslog согласно определению в RFC 3164 https://wiki.mikrotik.com/wiki/Manual:System/Log

Jotne Guest	#20 0 08.11.2022 16:13:00 Это совсем не помогает. Логи BSD ещё хуже. Посмотрите на эти отладочные логи DHCP. Логи BSD 2022-11-08T17:06:35.639612+01:00 <31>Nov 8 17:06:34 OVA MikroTik: Client-Id = 01-00-0C-AA-9B-EA-66 2022-11-08T17:06:35.639683+01:00 <31>Nov 8 17:06:34 OVA MikroTik: dhcp-client на bridge получил ack с id 3916435468 от 10.11.10.1 2022-11-08T17:06:35.639744+01:00 <31>Nov 8 17:06:34 OVA MikroTik: ciaddr = 0.0.0.0 2022-11-08T17:06:35.639831+01:00 <31>Nov 8 17:06:34 OVA MikroTik: yiaddr = 10.11.10.141 2022-11-08T17:06:35.639884+01:00 <31>Nov 8 17:06:34 OVA MikroTik: siaddr = 10.11.10.1 2022-11-08T17:06:35.639956+01:00 <31>Nov 8 17:06:34 OVA MikroTik: chaddr = 00:0C:AA:9B:EA:66 2022-11-08T17:06:35.640060+01:00 <31>Nov 8 17:06:34 OVA MikroTik: Subnet-Mask = 255.255.254.0 2022-11-08T17:06:35.640144+01:00 <31>Nov 8 17:06:34 OVA MikroTik: Router = 10.11.10.1 2022-11-08T17:06:35.640210+01:00 <31>Nov 8 17:06:34 OVA MikroTik: Domain-Server = 10.11.10.1 2022-11-08T17:06:35.640285+01:00 <31>Nov 8 17:06:34 OVA MikroTik: NTP-Server = 10.11.10.1 2022-11-08T17:06:35.640349+01:00 <31>Nov 8 17:06:34 OVA MikroTik: Address-Time = 86400 2022-11-08T17:06:35.640431+01:00 <31>Nov 8 17:06:34 OVA MikroTik: Msg-Type = ack 2022-11-08T17:06:35.640493+01:00 <31>Nov 8 17:06:34 OVA MikroTik: Server-Id = 10.11.10.1 2022-11-08T17:06:35.640567+01:00 <30>Nov 8 17:06:34 OVA MikroTik: dhcp-client на bridge получил IP-адрес 10.11.10.141 2022-11-08T17:06:35.640631+01:00 <31>Nov 8 17:06:34 OVA MikroTik: dhcp-client на bridge вошёл в состояние <bound> 2022-11-08T17:06:37.048188+01:00 <30>Nov 8 17:06:36 OVA MikroTik: пользователь jotne вошёл с 10.11.10.32 через winbox 2022-11-08T17:06:37.231730+01:00 <30>Nov 8 17:06:36 OVA MikroTik: локальный запрос: #1 upgrade.mikrotik.com. A 2022-11-08T17:06:37.260367+01:00 <30>Nov 8 17:06:36 OVA MikroTik: ответ на запрос: #1 upgrade.mikrotik.com 159.148.172.226 Без BSD 2022-11-08T17:08:43.989247+01:00 <13>dhcp,debug,packet MikroTik: Client-Id = 01-00-0C-AA-9B-EA-66 2022-11-08T17:08:43.989411+01:00 <13>dhcp,debug,packet MikroTik: dhcp-client на bridge получил ack с id 1310283069 от 10.11.10.1 2022-11-08T17:08:43.989411+01:00 <13>dhcp,debug,packet MikroTik: flags = broadcast 2022-11-08T17:08:43.989506+01:00 <13>dhcp,debug,packet MikroTik: ciaddr = 0.0.0.0 2022-11-08T17:08:43.989571+01:00 <13>dhcp,debug,packet MikroTik: yiaddr = 10.11.10.141 2022-11-08T17:08:43.989619+01:00 <13>dhcp,debug,packet MikroTik: siaddr = 10.11.10.1 2022-11-08T17:08:43.989698+01:00 <13>dhcp,debug,packet MikroTik: chaddr = 00:0C:AA:9B:EA:66 2022-11-08T17:08:43.989748+01:00 <13>dhcp,debug,packet MikroTik: Subnet-Mask = 255.255.254.0 2022-11-08T17:08:43.989859+01:00 <13>dhcp,debug,packet MikroTik: Router = 10.11.10.1 2022-11-08T17:08:43.990017+01:00 <13>dhcp,debug,packet MikroTik: Domain-Server = 10.11.10.1 2022-11-08T17:08:43.990017+01:00 <13>dhcp,debug,packet MikroTik: NTP-Server = 10.11.10.1 2022-11-08T17:08:43.990017+01:00 <13>dhcp,debug,packet MikroTik: Address-Time = 86400 2022-11-08T17:08:43.990114+01:00 <13>dhcp,debug,packet MikroTik: Msg-Type = ack 2022-11-08T17:08:43.990203+01:00 <13>dhcp,debug,packet MikroTik: Server-Id = 10.11.10.1 2022-11-08T17:08:43.990315+01:00 <13>dhcp,info MikroTik: dhcp-client на bridge получил IP-адрес 10.11.10.141 2022-11-08T17:08:43.990362+01:00 <13>dhcp,debug,state MikroTik: dhcp-client на bridge вошёл в состояние <bound> Как видите, с BSD непонятно, к какому модулю относятся данные, но он подсовывает имя роутера как дополнительную информацию. Без BSD — пишет DHCP, DEBUG, PACKET. Было бы здорово, если бы в DHCP-запросе (или других логах с несколькими строками) отправлялся некий ID, чтобы понимать, что к чему относится.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры