Диагностика RouterOS по логам: читать topic и сверять с counters

Короткий ответ

/log print без фильтра — лента info, в которой тонет причина. Включайте нужный topics на время разбора, смотрите тот же интервал в /ip firewall filter print stats, /interface print stats, /ip dhcp-server lease print. Логи без counters — догадки; counters без логов — не видно, кто стучался. Не оставляйте topics=firewall в memory на гигабитном NAT: RAM кончится.

Время: NTP, иначе timestamps вранье. Для инцидента копируйте log на ПК (/log print file=), не надейтесь, что memory переживёт reboot.

Симптомы и как отличить

Авария была, log пуст — мало memory-lines или reboot. Log полный drop — включён firewall log, CPU тоже высокий. Это не «мало правил», а перелогирование.

Возможные причины

1. Action memory переполнен, старое вытеснено.
2. Нужный topic не в /system logging.
3. Часы с 1970, NTP нет.
4. Ищут firewall в log, а drop без action=log.
5. Remote syslog недоступен, локально ничего не писали.
6. Слишком широкий !debug забыли, или наоборот только critical.

Диагностика

/system logging print
/system logging action print
/system clock print
/system ntp client print
/log print count-only

Дефолт: info → memory. Добавки:

/system logging add topics=dhcp action=memory

Для IPsec на время:

/system logging add topics=ipsec,!packet action=memory

!packet обязателен, иначе утонете.

Связка с counters (firewall пример):

/ip firewall filter reset-counters-all

Воспроизведите; print stats; если drop вырос, а в log тишина — правила без log. Добавьте одно log-правило с prefix на подозреваемый match, не на established.

/log print where message~"FWD"

Решение

1. Зафиксировать

/log print file=incident-log
/system backup save name=incident
/export file=incident

Скачайте файлы. Методика backup — отдельная статья.

2. Сузить topic

DHCP не выдаёт — dhcp + lease print, не ipsec. Туннель — ipsec + active-peers. CPU — не log, а /tool profile, log только если script/error.

3. Вынести с устройства

/system logging action
add name=to-syslog remote=10.0.10.10 remote-port=514 target=remote
/system logging add topics=info,!debug action=to-syslog

10.0.10.10 — ваш syslog. Без него после reboot картина инцидента умрёт.

4. Не логировать fast path

Никакого action=log на FastTrack/established. Только new/drop с лимитом, если есть limit= в вашей версии правила — используйте, чтобы не писать каждый скан.

5. Account

Брутфорс WAN виден в account. Лечение — закрыть управление, не «ещё log».

Как проверить, что проблема устранена

(Что диагностика настроена.)

Воспроизведите известное событие (DHCP renew, WG handshake, неудачный WAN login): строка в log с верным topic и изменение соответствующего counter. NTP: время log = стенка. После удаления временного firewall-log RAM не растёт. Файл incident-log на ПК открывается.

/log print where topics~"dhcp"
/ip dhcp-server lease print

должны согласовываться по MAC/времени.

Если не помогло

• Событие в switch chip offload не видно в firewall log — смотрите hardware offload, зеркало порта.
• Контейнер/скрипт молчит — отдельный log script.
• Нужен packet capture: /tool sniffer коротко, не вместо log, ест CPU.

Для IPsec детали — статья Phase1/2. Для filter — counters.

Профилактика

• NTP сразу после установки.
• Syslog на сервер.
• Мало topics на memory, подробно на remote.
• Регламент: временные debug log удалять в конце окна.
• Не держать debug на проде.
• Перед разбором IPsec включайте topics=ipsec,!packet, после — удаляйте, чтобы memory не превратился в дамп каждого пакета.

Как собрать пакет доказательств, а не ленту info

Для заявки нужны три артефакта с одним timestamp: /log print file=, /ip firewall filter print stats, /export. Без NTP timestamp врёт — сначала часы. Topic выбирайте под гипотезу: dhcp к пустым lease, ipsec к пустым SA, account к brute-force. Не включайте firewall в memory на постоянку.

Связка: reset-counters → воспроизведение → stats → log. Если drop вырос, а log тихий, правила без action=log. Точечный log с prefix на одно правило new/drop, не на established. После поимки удалите log-правило, иначе RAM и CPU повторят mt-08/mt-07.

Remote syslog (target=remote) переживает reboot роутера. Локальный memory — нет. topics=ipsec,!packet на время разбора Phase1; packet log не оставляйте. Script/scheduler ошибки ищите в script/error, не в dhcp.

Sniffer — не замена log: короткие захваты на CPU-критичном шлюзе. Switch-chip offload может скрыть пакет от filter log — тогда counters на CPU-правилах врут «тишиной», смотрите ограничения чипа и зеркало порта.

FAQ

/log print follow?

Живой хвост в CLI. Не оставляйте сессию на сутки.

echo action?

Пишет в консоль. Для отладки скриптов, не для шлюза.

disk logging на USB?

Возможно как action target=disk, убивает флешку частыми записями. Syslog лучше.

Почему нет prefix, который ставили?

Правило filter не сработало (не тот chain) или log-prefix опечатка. Counters на этом правиле — судья.

script error где?

Topic script / error. Scheduler отдельно /system scheduler print. Не ищите в dhcp.

Куда смотреть, если log пуст, а авария точно была?

Либо memory-lines вытеснили событие, либо был reboot, либо topic не писался. Тогда остаются counters (если не reset), файлы syslog на сервере и export. Поэтому remote syslog включают до инцидента. Локально увеличьте memory-lines умеренно, не до OOM. Для повторяемой проблемы включите нужный topic, воспроизведите, сразу /log print file=. Пустой firewall log при растущем drop — норма, если нет action=log; counters всё равно судья. Не делайте reset-configuration, чтобы «почистить журнал».