Skip to main content

Поднимаем SySlogServer (rsyslog) с кооперацией с logrotate и Zabbix

1. Общая информация

1.1. Назначение

Данная инструкция описывает развёртывание централизованного Syslog-сервера на Ubuntu Server 24.04 с использованием:

  • rsyslog — приём и раскладка удалённых syslog-сообщений;

  • logrotate — ежедневная ротация и архивирование логов;

  • Zabbix agent 2 — передача выбранных событий и счётчиков в Zabbix.

Основная задача сервера — централизованно принимать события от сетевого оборудования Cisco, раскладывать их по устройствам, категориям и уровням важности, а также выделять отдельные alert-файлы для дальнейшего мониторинга через Zabbix.

2. Уровни и каталогизация логов

В проекте используется несколько уровней раскладки удалённых syslog-сообщений.

2.1. Полный лог по каждому устройству

/var/log/remote/<IP_ИСТОЧНИКА>/all.log

Пример:

/var/log/remote/192.168.1.250/all.log

В этот файл попадают все сообщения от конкретного устройства.

2.2. Раскладка по facility

/var/log/remote/<IP_ИСТОЧНИКА>/facility/<facility>.log

Пример:

/var/log/remote/192.168.1.250/facility/local7.log

Для Cisco часто используется facility local7.

2.3. Раскладка по severity

/var/log/remote/<IP_ИСТОЧНИКА>/severity/<severity>.log

Примеры:

/var/log/remote/192.168.1.250/severity/err.log
/var/log/remote/192.168.1.250/severity/warning.log
/var/log/remote/192.168.1.250/severity/notice.log
/var/log/remote/192.168.1.250/severity/info.log

2.4. Alert-файлы для Zabbix

Для последующей обработки в Zabbix дополнительно формируются отдельные alert-файлы:

/var/log/remote/_alerts/<ПОДСЕТЬ_ИСТОЧНИКА>/high.log
/var/log/remote/_alerts/<ПОДСЕТЬ_ИСТОЧНИКА>/alerts_critical.log
/var/log/remote/_alerts/<ПОДСЕТЬ_ИСТОЧНИКА>/alerts_warning.log
/var/log/remote/_alerts/<ПОДСЕТЬ_ИСТОЧНИКА>/alerts_behavior.log

Каталоги _alerts формируются по подсети источника, рассчитанной по правилу /24.

Примеры:

192.168.1.250 -> /var/log/remote/_alerts/192.168.1.0/
10.44.100.37  -> /var/log/remote/_alerts/10.44.100.0/

Важно: данный вариант рассчитан на IPv4 и на подсети /24.

3. Уровни severity

Syslog использует следующие уровни важности:

Уровень Назначение
emerg авария максимального уровня
alert критичное событие, требующее немедленного внимания
crit критическая ошибка
err ошибка
warning предупреждение
notice важное служебное сообщение
info информационное сообщение
debug отладочное сообщение

Дополнительно формируются отдельные alert-файлы:

Файл Назначение
high.log все сообщения уровня err и выше
alerts_critical.log немедленные аварийные события
alerts_warning.log важные предупреждающие события
alerts_behavior.log накопительные признаки нестабильности L2-сети

4. Общая логика мониторинга

Обычные события вида %LINK-3-UPDOWN и %LINEPROTO-5-UPDOWN лучше оставлять для истории и разбора, а не делать на них основную аварийную логику через syslog, потому что состояние интерфейсов Zabbix обычно хорошо видит напрямую через SNMP.

Через syslog есть смысл дополнительно забирать именно то, что плохо видно стандартными шаблонами:

  • срабатывания защит второго уровня сети;

  • переход портов в err-disable;

  • BPDU Guard / Root Guard / Loop Guard;

  • UDLD;

  • EtherChannel misconfiguration;

  • MAC flapping / MAC move;

  • частые перестроения STP.

5. Какие события предлагается мониторить

5.1. Немедленная авария

Эти сообщения поднимаем в Zabbix сразу, без накопления:

Событие Смысл
PM-4-ERR_DISABLE порт переведён в аварийную блокировку err-disable
SPANTREE-2-BLOCK_BPDUGUARD на порт с BPDU Guard пришёл BPDU, Cisco отключила интерфейс
UDLD-4-UDLD_PORT_DISABLED UDLD отключил интерфейс из-за ненормального состояния линии
SPANTREE-2-CHNL_MISCFG обнаружена петля из-за неправильной настройки EtherChannel
STORM_CONTROL-3-SHUTDOWN storm-control отключил порт из-за шторма

Эти события складываются в:

/var/log/remote/_alerts/<ПОДСЕТЬ_ИСТОЧНИКА>/alerts_critical.log

5.2. Немедленное предупреждение

Эти сообщения важны, но не всегда означают немедленную потерю связи:

Событие Смысл
SPANTREE-2-LOOPGUARD_BLOCK Loop Guard заблокировал порт из-за прекращения получения BPDU
SPANTREE-2-ROOTGUARD_BLOCK Root Guard заблокировал порт, чтобы не допустить нежелательную смену root bridge
STORM_CONTROL-3-FILTERED storm-control начал фильтровать избыточный трафик, порт ещё не отключён

Эти события складываются в:

/var/log/remote/_alerts/<ПОДСЕТЬ_ИСТОЧНИКА>/alerts_warning.log

5.3. Накопительные признаки

Эти события не обязательно являются аварией по одному сообщению. Их лучше считать за интервал 5–10 минут:

Событие Смысл
MAC_MOVE-4-NOTIF один MAC-адрес появляется на разных портах, актуально для старых Cisco
SW_MATM-4-MACFLAP_NOTIF аналогичный MAC flapping для более новых Cisco, включая Catalyst 9000
SPANTREE-5-TOPOTRAP произошло изменение топологии STP
SPANTREE-5-ROOTCHANGE изменился root bridge или root port для STP-инстанса

Эти события складываются в:

/var/log/remote/_alerts/<ПОДСЕТЬ_ИСТОЧНИКА>/alerts_behavior.log

Начальные пороги можно принять такими:

Событие Warning High
MAC_MOVE-4-NOTIF 2 за 5 минут 5 за 5 минут
SW_MATM-4-MACFLAP_NOTIF 2 за 5 минут 5 за 5 минут
SPANTREE-5-TOPOTRAP 5 за 5 минут 15 за 5 минут
SPANTREE-5-ROOTCHANGE 1 за 10 минут 2 за 10 минут

Это не жёсткое правило Cisco, а стартовая схема, чтобы не утонуть в шуме.

6. Zabbix: log[], logrt[], log.count[], logrt.count[]

Zabbix разделяет мониторинг журналов на несколько типов ключей.

6.1. log[]

log[] используется для обычного файла журнала без ротации. Он читает новые строки, ищет совпадение по регулярному выражению и отправляет в Zabbix саму строку журнала.

Пример:

log[/var/log/cisco/alerts_critical.log,"PM-4-ERR_DISABLE|SPANTREE-2-BLOCK_BPDUGUARD"]

6.2. logrt[]

logrt[] используется для журналов с ротацией. Zabbix отслеживает активный файл и его ротированные копии.

Для аварийных syslog-событий это основной вариант, потому что наши файлы ротируются через logrotate.

Пример:

logrt[/var/log/remote/_alerts/192.168.1.0/alerts_critical\.log,"PM-4-ERR_DISABLE|SPANTREE-2-BLOCK_BPDUGUARD"]

6.3. log.count[]

log.count[] считает количество совпадений в обычном, не ротируемом журнале.

Пример:

log.count[/var/log/cisco/alerts_behavior.log,"MAC_MOVE-4-NOTIF"]

6.4. logrt.count[]

logrt.count[] считает количество совпадений в ротируемом журнале. Это удобный вариант для MAC flapping, частых STP-перестроений и похожих повторяющихся признаков.

Пример:

logrt.count[/var/log/remote/_alerts/192.168.1.0/alerts_behavior\.log,"MAC_MOVE-4-NOTIF|SPANTREE-5-TOPOTRAP|SPANTREE-5-ROOTCHANGE"]

6.5. Итоговая рекомендация по Zabbix-ключам

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

Задача Ключ
Читать аварийные строки из ротируемого файла logrt[]
Читать предупреждающие строки из ротируемого файла logrt[]
Считать повторяемость MAC flapping / STP-событий logrt.count[]

Важно: элементы мониторинга журналов в Zabbix должны быть активными проверками, то есть тип элемента данных — Zabbix agent (active).

Практическая установка

7. Установка Ubuntu Server и базовых пакетов

Устанавливаем Ubuntu Server Minimal 24.04.

Обновляем систему:

sudo apt update
sudo apt upgrade -y

Устанавливаем rsyslog, logrotate, nano и дополнительные утилиты для диагностики:

sudo apt install -y rsyslog logrotate nano iputils-ping tcpdump arping bash-completion lsof

Где:

  • rsyslog — syslog-сервер;

  • logrotate — ротация логов;

  • tcpdump — проверка входящих UDP/TCP-пакетов;

  • arping — сетевые проверки в L2-сегменте;

  • bash-completion — автодополнение в shell;

  • lsof — просмотр открытых файлов, полезно при проверке ротации.

8. Настройка автодополнения Bash

Открываем файл .bashrc:

nano ~/.bashrc

Добавляем в конец:

# Подключаем bash-completion, если он установлен
[[ $PS1 && ! ${BASH_COMPLETION_VERSINFO:-} && -f /usr/share/bash-completion/bash_completion ]] && \
    . /usr/share/bash-completion/bash_completion

Перечитываем конфиг:

source ~/.bashrc

После этого должна заработать автоподстановка по Tab.

9. Настройка часового пояса и времени

Проверяем текущее состояние времени:

timedatectl status

Проверяем наличие часового пояса Europe/Samara:

timedatectl list-timezones | grep Samara

Задаём часовой пояс:

sudo timedatectl set-timezone Europe/Samara

Проверяем результат:

timedatectl status
date

Если всё настроено правильно, в выводе timedatectl status должен быть указан локальный часовой пояс Europe/Samara.

10. Настройка NTP через systemd-timesyncd

На Ubuntu Server в качестве клиента синхронизации времени можно использовать systemd-timesyncd.

Устанавливаем сервис:

sudo apt-mark auto chrony
sudo apt install -y systemd-timesyncd

Открываем конфиг:

sudo nano /etc/systemd/timesyncd.conf

Пример содержимого:

[Time]
NTP=192.168.1.1 0.pool.ntp.org 1.pool.ntp.org
FallbackNTP=2.pool.ntp.org 3.pool.ntp.org

Где:

  • NTP= — основные серверы времени;

  • FallbackNTP= — резервные серверы времени.

После изменения перезапускаем сервис и включаем синхронизацию:

sudo systemctl restart systemd-timesyncd
sudo timedatectl set-ntp true

Проверяем статус:

timedatectl status
systemctl status systemd-timesyncd --no-pager

В нормальном состоянии должно быть:

System clock synchronized: yes
NTP service: active

10.1. Настройка времени без NTP сервера - вручную

Настройка на сервере

Проверяем текущее время

timedatectl status
date

Отключаем NTP-синхронизацию

sudo timedatectl set-ntp false

Проверить:

timedatectl status

В выводе должно быть:

NTP service: inactive
System clock synchronized: no

Устанавливаем часовой пояс

Для Самары:

sudo timedatectl set-timezone Europe/Samara

Проверить:

timedatectl status
date

Ожидаемо часовой пояс должен быть:

Time zone: Europe/Samara

Устанавливаем дату и время вручную

Формат команды:

sudo timedatectl set-time "YYYY-MM-DD HH:MM:SS"

Пример:

sudo timedatectl set-time "2026-04-30 15:30:00"

Проверить:

date
timedatectl status

Рекомендованная настройка RTC

Для Linux-серверов обычно лучше хранить аппаратные часы в UTC:

sudo timedatectl set-local-rtc 0

Проверить:

timedatectl status

Ожидаемо:

RTC in local TZ: no

 

10.1. Настройка статического IP-адреса сервера Syslog и отключение IPv6

Для Syslog-сервера желательно использовать статические IP-адреса. Это нужно, чтобы сетевое оборудование Cisco, Zabbix Server/Zabbix Proxy и другие источники логов всегда отправляли события на один и тот же адрес.

В данной конфигурации используются два сетевых интерфейса:

ens18 — сеть администрирования и обновлений.

ens19 — сеть VLAN 2100 / OT-сегмент для приёма логов.

Параметры интерфейса ens18:

IP Syslog-сервера: 192.168.1.40/24

Шлюз: 192.168.1.1

DNS: 192.168.1.1

Параметры интерфейса ens19:

IP Syslog-сервера: 10.44.100.252/24

Шлюз: не указывается

IPv6 отключается через netplan на обоих интерфейсах. Для этого используются параметры:

dhcp6: false

accept-ra: false

Где:

dhcp6: false — отключает получение IPv6-адреса по DHCPv6.

accept-ra: false — запрещает принимать IPv6 Router Advertisement.

Перед настройкой нужно проверить фактические имена сетевых интерфейсов:

ip -br link
ip -br addr

Пример вывода:

lo      UNKNOWN 127.0.0.1/8
ens18   UP      192.168.1.120/24
ens19   UP      10.44.100.120/24

В данном примере интерфейсы называются ens18 и ens19. В другой системе имена могут отличаться: ens160, enp0s3, enp1s0 и т.п.

Посмотреть текущие netplan-файлы:

ls -l /etc/netplan/

На Ubuntu Server обычно уже есть файл вида:

/etc/netplan/00-installer-config.yaml

или:

/etc/netplan/50-cloud-init.yaml

Чтобы не ломать исходный файл, можно создать отдельный файл с более высоким номером:

sudo nano /etc/netplan/99-static-syslog.yaml

Пример конфигурации:

network:
  version: 2
  renderer: networkd
  ethernets:
    ens18:
      dhcp4: false
      dhcp6: false
      accept-ra: false
      link-local: []
      addresses:
        - 192.168.1.40/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses:
          - 192.168.1.1

    ens19:
      dhcp4: false
      dhcp6: false
      accept-ra: false
      link-local: []
      addresses:
        - 10.44.100.252/24

Важно: основной шлюз указывается только на интерфейсе ens18.

Для ens19 шлюз не указывается, чтобы не создавать второй default route.

Если нужно указать несколько DNS-серверов, блок nameservers можно оформить так:

nameservers:
  addresses:
    - 192.168.1.1
    - 8.8.8.8

После сохранения файла ограничить права:

sudo chmod 600 /etc/netplan/99-static-syslog.yaml

Проверить конфигурацию:

sudo netplan generate

Если ошибок нет, применить настройки безопасным способом:

sudo netplan try

Команда netplan try применит настройки временно и попросит подтвердить их. Если связь с сервером пропадёт и подтверждения не будет, настройки автоматически откатятся.

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

sudo netplan apply

Проверить адреса:

ip -br addr

Проверить маршруты:

ip route

Ожидаемая логика маршрутов:

default via 192.168.1.1 dev ens18
192.168.1.0/24 dev ens18
10.44.100.0/24 dev ens19

Проверить DNS:

resolvectl status

Проверить доступность шлюза:

ping -c 4 192.168.1.1

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

ping -c 4 8.8.8.8

Проверить разрешение DNS-имён:

ping -c 4 ya.ru

Проверить, что IPv6-адреса не назначены:

ip -6 addr

В норме после отключения IPv6 через netplan на интерфейсах ens18 и ens19 не должно быть строк вида:

inet6 fe80::...

Также можно проверить через ip a: на интерфейсах должны остаться только IPv4-адреса.

Проверить, что Syslog-сервер слушает порт 514 после смены адреса:

sudo ss -ulpn | grep ':514'
sudo ss -tlpn | grep ':514'

Ожидаемо rsyslog должен слушать UDP/514 и TCP/514 на IPv4.

11. Подготовка каталогов для логов

Создаём базовый каталог:

sudo mkdir -p /var/log/remote/_alerts

Назначаем владельца:

sudo chown -R syslog:syslog /var/log/remote

Закрываем каталог от лишнего доступа:

sudo chmod 0750 /var/log/remote
sudo chmod 0750 /var/log/remote/_alerts

Проверяем:

ls -ld /var/log/remote
ls -ld /var/log/remote/_alerts

Ожидаемо:

drwxr-x--- ... syslog syslog ... /var/log/remote
drwxr-x--- ... syslog syslog ... /var/log/remote/_alerts

12. Включение rsyslog

Запускаем rsyslog и добавляем его в автозагрузку:

sudo systemctl enable --now rsyslog

Проверяем статус:

sudo systemctl status rsyslog --no-pager

13. Конфигурация rsyslog

Создаём файл конфигурации:

sudo touch /etc/rsyslog.d/10-remote-collector.conf

Открываем файл:

sudo nano /etc/rsyslog.d/10-remote-collector.conf

Вставляем конфигурацию:

# Загружаем модули приема удаленных syslog-сообщений по UDP и TCP
module(load="imudp")
module(load="imtcp")

# ------------------------------------------------------------
# Шаблоны путей для основных логов
# ------------------------------------------------------------
# Каталоги строим по реальному IP источника.
# Это исключает смешивание устройств с одинаковым hostname.

template(name="RemoteAllPath" type="list") {
    constant(value="/var/log/remote/")
    property(name="fromhost-ip" securePath="replace")
    constant(value="/all.log")
}

template(name="RemoteFacilityPath" type="list") {
    constant(value="/var/log/remote/")
    property(name="fromhost-ip" securePath="replace")
    constant(value="/facility/")
    property(name="syslogfacility-text" securePath="replace")
    constant(value=".log")
}

template(name="RemoteSeverityPath" type="list") {
    constant(value="/var/log/remote/")
    property(name="fromhost-ip" securePath="replace")
    constant(value="/severity/")
    property(name="syslogseverity-text" securePath="replace")
    constant(value=".log")
}

# ------------------------------------------------------------
# Шаблон строки для alert-файлов
# ------------------------------------------------------------
# Формат строки делаем коротким и удобным для Zabbix:
# время, IP источника, syslog tag и само сообщение.

template(name="AlertsFileFormat" type="string"
         string="%timereported:::date-rfc3339% %fromhost-ip% %syslogtag% %msg:::drop-last-lf%\n")

# ------------------------------------------------------------
# Шаблоны путей для _alerts по подсетям /24
# ------------------------------------------------------------
# Пример:
# 192.168.1.250 -> /var/log/remote/_alerts/192.168.1.0/...
#
# ВАЖНО:
# Этот вариант рассчитан на IPv4 и подсети /24.

template(name="AlertHighPath" type="list") {
    constant(value="/var/log/remote/_alerts/")
    property(name="fromhost-ip"
             regex.type="ERE"
             regex.expression="([0-9]+\\.[0-9]+\\.[0-9]+)\\.[0-9]+"
             regex.subMatch="1")
    constant(value=".0/high.log")
}

template(name="AlertCriticalPath" type="list") {
    constant(value="/var/log/remote/_alerts/")
    property(name="fromhost-ip"
             regex.type="ERE"
             regex.expression="([0-9]+\\.[0-9]+\\.[0-9]+)\\.[0-9]+"
             regex.subMatch="1")
    constant(value=".0/alerts_critical.log")
}

template(name="AlertWarningPath" type="list") {
    constant(value="/var/log/remote/_alerts/")
    property(name="fromhost-ip"
             regex.type="ERE"
             regex.expression="([0-9]+\\.[0-9]+\\.[0-9]+)\\.[0-9]+"
             regex.subMatch="1")
    constant(value=".0/alerts_warning.log")
}

template(name="AlertBehaviorPath" type="list") {
    constant(value="/var/log/remote/_alerts/")
    property(name="fromhost-ip"
             regex.type="ERE"
             regex.expression="([0-9]+\\.[0-9]+\\.[0-9]+)\\.[0-9]+"
             regex.subMatch="1")
    constant(value=".0/alerts_behavior.log")
}

# ------------------------------------------------------------
# Основной ruleset для удаленных syslog-сообщений
# ------------------------------------------------------------

ruleset(name="RemoteLogs") {

    # Полный лог по устройству
    action(type="omfile"
           dynaFile="RemoteAllPath"
           template="RSYSLOG_TraditionalFileFormat"
           createDirs="on"
           dirCreateMode="0750"
           fileCreateMode="0640"
           dirGroup="syslog"
           fileGroup="syslog")

    # Раскладка по facility
    action(type="omfile"
           dynaFile="RemoteFacilityPath"
           template="RSYSLOG_TraditionalFileFormat"
           createDirs="on"
           dirCreateMode="0750"
           fileCreateMode="0640"
           dirGroup="syslog"
           fileGroup="syslog")

    # Раскладка по severity
    action(type="omfile"
           dynaFile="RemoteSeverityPath"
           template="RSYSLOG_TraditionalFileFormat"
           createDirs="on"
           dirCreateMode="0750"
           fileCreateMode="0640"
           dirGroup="syslog"
           fileGroup="syslog")

    # Общий технический файл ошибок по подсетям.
    # Сюда попадают err, crit, alert, emerg.
    if ($syslogseverity <= 3) then {
        action(type="omfile"
               dynaFile="AlertHighPath"
               template="AlertsFileFormat"
               createDirs="on"
               dirCreateMode="0750"
               fileCreateMode="0640"
               dirGroup="syslog"
               fileGroup="syslog")
    }

    # 1. Немедленная авария
    if ($msg contains "PM-4-ERR_DISABLE"
        or $msg contains "SPANTREE-2-BLOCK_BPDUGUARD"
        or $msg contains "UDLD-4-UDLD_PORT_DISABLED"
        or $msg contains "SPANTREE-2-CHNL_MISCFG"
        or $msg contains "STORM_CONTROL-3-SHUTDOWN") then {
        action(type="omfile"
               dynaFile="AlertCriticalPath"
               template="AlertsFileFormat"
               createDirs="on"
               dirCreateMode="0750"
               fileCreateMode="0640"
               dirGroup="syslog"
               fileGroup="syslog")
    }

    # 2. Немедленное предупреждение
    if ($msg contains "SPANTREE-2-LOOPGUARD_BLOCK"
        or $msg contains "SPANTREE-2-ROOTGUARD_BLOCK"
        or $msg contains "STORM_CONTROL-3-FILTERED") then {
        action(type="omfile"
               dynaFile="AlertWarningPath"
               template="AlertsFileFormat"
               createDirs="on"
               dirCreateMode="0750"
               fileCreateMode="0640"
               dirGroup="syslog"
               fileGroup="syslog")
    }

    # 3. Накопительные признаки
    if ($msg contains "MAC_MOVE-4-NOTIF"
        or $msg contains "SW_MATM-4-MACFLAP_NOTIF"
        or $msg contains "SPANTREE-5-TOPOTRAP"
        or $msg contains "SPANTREE-5-ROOTCHANGE") then {
        action(type="omfile"
               dynaFile="AlertBehaviorPath"
               template="AlertsFileFormat"
               createDirs="on"
               dirCreateMode="0750"
               fileCreateMode="0640"
               dirGroup="syslog"
               fileGroup="syslog")
    }

    # Останавливаем дальнейшую обработку этих сообщений стандартными правилами rsyslog.
    stop
}

# Прием удаленных syslog-сообщений по UDP/514 и TCP/514
input(type="imudp" port="514" ruleset="RemoteLogs")
input(type="imtcp" port="514" ruleset="RemoteLogs")

14. Проверка rsyslog

Проверяем синтаксис:

sudo rsyslogd -N1

Если ошибок нет, перезапускаем сервис:

sudo systemctl restart rsyslog
sudo systemctl status rsyslog --no-pager

Проверяем, что открыт приём syslog на 514 порту:

sudo ss -ulpn | grep ':514'
sudo ss -tlpn | grep ':514'

Если нужно посмотреть входящий UDP-трафик:

sudo tcpdump -ni any udp port 514

15. Проверка записи логов через UDP 514

Важно: если просто выполнить локально:

logger -p user.err -t TEST "Проверка записи в high.log"

то сообщение может уйти в локальную системную схему логирования, а не в наш ruleset RemoteLogs.

Для проверки именно удалённого syslog-приёма нужно отправлять сообщение на UDP/514:

logger -n 127.0.0.1 -P 514 -d -p user.err -t TEST "Проверка записи в high.log через UDP 514"

Проверяем, куда записалось сообщение:

sudo grep -R "Проверка записи в high.log через UDP 514" /var/log/remote/

Так как источник 127.0.0.1, файлы могут появиться в каталоге:

/var/log/remote/127.0.0.1/
/var/log/remote/_alerts/127.0.0.0/

С другого Linux-узла в сети можно отправить тестовое сообщение на syslog-сервер так:

logger --server <IP_SYSLOG_SERVER> --udp --port 514 -p user.err -t TEST "Проверка удаленного syslog по UDP"

Для TCP:

logger --server <IP_SYSLOG_SERVER> --tcp --port 514 -p user.err -t TEST "Проверка удаленного syslog по TCP"

После отправки проверяем:

sudo find /var/log/remote -type f | sort
sudo tail -n 20 /var/log/remote/<IP_ИСТОЧНИКА>/all.log

Если сообщение относится к alert-событиям, дополнительно проверяем:

sudo find /var/log/remote/_alerts -maxdepth 2 -type f | sort
sudo tail -n 20 /var/log/remote/_alerts/<ПОДСЕТЬ_ИСТОЧНИКА>/high.log
sudo tail -n 20 /var/log/remote/_alerts/<ПОДСЕТЬ_ИСТОЧНИКА>/alerts_critical.log
sudo tail -n 20 /var/log/remote/_alerts/<ПОДСЕТЬ_ИСТОЧНИКА>/alerts_warning.log
sudo tail -n 20 /var/log/remote/_alerts/<ПОДСЕТЬ_ИСТОЧНИКА>/alerts_behavior.log

Настройка Cisco для отправки syslog

16. Базовая настройка Cisco

На коммутаторе Cisco нужно включить отправку syslog на сервер.

conf t
!
service timestamps log datetime msec localtime show-timezone
service timestamps debug datetime msec localtime show-timezone
!
logging host <IP_SYSLOG_SERVER>
logging trap informational
logging facility local7
no logging console
!
end
wr

Пояснения:

  • logging host <IP_SYSLOG_SERVER> — адрес syslog-сервера;

  • logging trap informational — отправлять на syslog уровни 0–6, включая события уровня 5 типа SPANTREE-5-TOPOTRAP;

  • logging facility local7 — facility для Cisco-сообщений;

  • no logging console — не выводить массовые события в консоль;

  • service timestamps ... — добавлять нормальные временные метки в сообщения.

Проверка:

show logging
show running-config | include logging

Тестовое сообщение уровня 5:

send log 5 TEST_LEVEL5_SYSLOG

На syslog-сервере:

sudo grep -R "TEST_LEVEL5_SYSLOG" /var/log/remote/

17. Настройка времени на Cisco

Пример для Самары:

conf t
clock timezone SAMT 4 0
service timestamps log datetime msec localtime show-timezone
service timestamps debug datetime msec localtime show-timezone
ntp server 192.168.1.1 prefer
ntp server 192.168.1.2
end
wr

Если требуется, можно явно указать интерфейс-источник для NTP:

conf t
ntp source Vlan1
end
wr

Проверка:

show clock detail
show ntp status
show ntp associations

18. Включение MAC move / MAC flapping notifications

Для старых Cisco, например Catalyst 3750:

conf t
mac address-table notification mac-move
end
wr

Проверка:

show mac address-table notification mac-move

На новых сериях Cisco аналогичные события могут приходить как:

SW_MATM-4-MACFLAP_NOTIF

19. Включение логирования STP

Чтобы получать сообщения вида SPANTREE-5-TOPOTRAP и SPANTREE-5-ROOTCHANGE, на Cisco нужно включить логирование STP-событий:

conf t
spanning-tree logging
end
wr

Проверка:

show running-config | include spanning-tree logging
show logging | include SPANTREE

Для важных uplink/trunk-портов можно дополнительно включить интерфейсные события:

conf t
interface <UPLINK_INTERFACE>
 logging event link-status
 logging event trunk-status
 logging event spanning-tree
 logging event status
end
wr

Если какая-то команда на конкретной модели не поддерживается, её нужно пропустить.

Лабораторная проверка событий

20. Общие условия испытаний

Испытания следует проводить только на отдельном стенде или в изолированной лабораторной VLAN.

Пример стенда:

  • тестовый коммутатор Cisco C3750v2;

  • второй управляемый коммутатор Cisco C9200;

  • два ноутбука или тестовых хоста;

  • Syslog-сервер;

  • медные и оптические uplink-линии;

  • SFP-модули и патч-корды.

Такой стенд позволяет проверить:

  • пользовательские порты и access-защиты;

  • BPDU Guard;

  • storm-control;

  • MAC move / MAC flapping;

  • STP-события;

  • Root Guard / Loop Guard;

  • EtherChannel misconfiguration;

  • UDLD.

На syslog-сервере удобно открыть контроль:

sudo find /var/log/remote/_alerts -maxdepth 2 -type f | sort

Для конкретной подсети, например 192.168.1.0:

sudo tail -f \
/var/log/remote/_alerts/192.168.1.0/alerts_critical.log \
/var/log/remote/_alerts/192.168.1.0/alerts_warning.log \
/var/log/remote/_alerts/192.168.1.0/alerts_behavior.log \
/var/log/remote/_alerts/192.168.1.0/high.log

На коммутаторе удобно использовать:

terminal monitor
show logging | include PM-|SPANTREE|MAC_MOVE|SW_MATM|UDLD|STORM_CONTROL
show interfaces status err-disabled
show spanning-tree summary

21. Рекомендуемый порядок проверки

Рекомендуемый порядок:

  1. BPDU Guard

  2. MAC_MOVE-4-NOTIF

  3. STORM_CONTROL-3-FILTERED

  4. STORM_CONTROL-3-SHUTDOWN

  5. ROOTGUARD_BLOCK

  6. TOPOTRAP

  7. ROOTCHANGE

  8. LOOPGUARD_BLOCK

  9. CHNL_MISCFG

  10. UDLD_PORT_DISABLED

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

Методика воспроизведения событий

22. SPANTREE-2-BLOCK_BPDUGUARD и PM-4-ERR_DISABLE

Назначение теста

Проверка реакции access-порта с PortFast и BPDU Guard на появление BPDU. Это имитирует неправильное подключение коммутатора в пользовательский порт.

Настройка тестового порта

conf t
interface fa1/0/11
 description TEST_BPDU_GUARD
 switchport mode access
 switchport access vlan 1
 spanning-tree portfast
 spanning-tree bpduguard enable
 no shutdown
end
wr

Воспроизведение

Подключить в этот порт другой коммутатор, который отправляет BPDU.

Ожидаемый результат

В alerts_critical.log должны появиться:

SPANTREE-2-BLOCK_BPDUGUARD
PM-4-ERR_DISABLE

Проверка:

show logging | include BPDU|ERR_DISABLE
show interfaces status err-disabled
show errdisable recovery

Возврат в исходное состояние

conf t
interface fa1/0/11
 shutdown
 no shutdown
end

23. MAC_MOVE-4-NOTIF / SW_MATM-4-MACFLAP_NOTIF

Назначение теста

Проверка реакции коммутатора на появление одного и того же MAC-адреса на двух портах одной VLAN.

Для старых Cisco ожидаемое сообщение:

MAC_MOVE-4-NOTIF

Для более новых Cisco, включая Catalyst 9000, аналогичное по смыслу событие может приходить как:

SW_MATM-4-MACFLAP_NOTIF

Настройка на коммутаторе

conf t
mac address-table notification mac-move
!
interface fa1/0/12
 description TEST_MAC_MOVE_A
 switchport mode access
 switchport access vlan 1
 no shutdown
!
interface fa1/0/13
 description TEST_MAC_MOVE_B
 switchport mode access
 switchport access vlan 1
 no shutdown
end
wr

Воспроизведение

Подключить два тестовых хоста к Fa1/0/12 и Fa1/0/13.

На обоих хостах задать одинаковый MAC-адрес и запустить обмен трафиком в одной VLAN.

Важно, чтобы оба хоста реально передавали кадры, иначе коммутатор не начнёт переучивать MAC-адрес между портами.

Ожидаемый результат

В alerts_behavior.log должно появиться одно из сообщений:

MAC_MOVE-4-NOTIF
SW_MATM-4-MACFLAP_NOTIF

Проверка:

show logging | include MAC_MOVE|SW_MATM
show mac address-table dynamic vlan 1
show mac address-table notification mac-move

Возврат в исходное состояние

Вернуть нормальные MAC-адреса на тестовых хостах и очистить таблицу динамических MAC-адресов:

clear mac address-table dynamic

24. STORM_CONTROL-3-FILTERED

Назначение теста

Проверка того, что при превышении порога широковещательного или многоадресного трафика коммутатор начинает фильтрацию и пишет соответствующее предупреждение.

Настройка порта

conf t
interface fa1/0/14
 description TEST_STORM_FILTER
 switchport mode access
 switchport access vlan 1
 storm-control broadcast level 0.001 0.0
 storm-control multicast level 0.001 0.0
 no shutdown
end
wr

Воспроизведение

Подать на интерфейс Fa1/0/14 поток широковещательных кадров, достаточный для превышения заданного порога storm-control.

На Linux-машине можно пинговать широковещательный адрес:

sudo ping -f -b 192.168.1.255 -I ens33

Где:

  • 192.168.1.255 — широковещательный адрес тестовой подсети;

  • ens33 — интерфейс Linux-хоста, посмотреть можно через ip a.

Тест выполнять только в изолированной лабораторной VLAN.

При данном сценарии ожидается фильтрация широковещательного/многоадресного трафика без перевода порта в err-disable.

Ожидаемый результат

В alerts_warning.log должно появиться:

STORM_CONTROL-3-FILTERED

Проверка:

show logging | include STORM_CONTROL
show storm-control
show interfaces fa1/0/14 counters

25. STORM_CONTROL-3-SHUTDOWN

Назначение теста

Проверка более жёсткого режима storm-control, при котором порт не просто режет трафик, а отключается.

Настройка порта

conf t
interface fa1/0/14
 description TEST_STORM_SHUTDOWN
 switchport mode access
 switchport access vlan 1
 storm-control broadcast level 0.001 0.0
 storm-control multicast level 0.001 0.0
 storm-control action shutdown
 no shutdown
end
wr

Воспроизведение

Подать на интерфейс поток широковещательных кадров, как в предыдущем примере.

Убедиться, что порт ушёл в err-disabled:

show interfaces status err-disabled

Ожидаемый результат

В alerts_critical.log должно появиться:

STORM_CONTROL-3-SHUTDOWN

Проверка:

show logging | include STORM_CONTROL
show interfaces status err-disabled
show storm-control

Возврат в исходное состояние

Прекратить генерацию широковещательного трафика.

Затем выполнить:

conf t
interface fa1/0/14
 shutdown
 no shutdown
end

26. SPANTREE-2-ROOTGUARD_BLOCK

Назначение теста

Проверка реакции Root Guard на superior BPDU. Root Guard переводит порт в root-inconsistent и не даёт нежелательному устройству стать корневым коммутатором STP.

Настройка на первом коммутаторе

conf t
interface fa1/0/15
 description TEST_ROOT_GUARD
 switchport trunk encapsulation dot1q
 switchport mode trunk
 spanning-tree guard root
 no shutdown
end
wr

На некоторых моделях команда switchport trunk encapsulation dot1q отсутствует или не требуется. Если команда не поддерживается, её нужно пропустить.

Настройка на втором коммутаторе

conf t
interface fa1/0/15
 description TEST_ROOT_GUARD_2
 switchport trunk encapsulation dot1q
 switchport mode trunk
 no shutdown
end
wr

Воспроизведение

На втором коммутаторе задать более низкий STP priority для VLAN 1, чтобы он начал отправлять superior BPDU:

conf t
spanning-tree vlan 1 priority 0
end

После теста вернуть исходное значение:

conf t
spanning-tree vlan 1 priority <ИСХОДНОЕ_ЗНАЧЕНИЕ>
end
wr

Ожидаемый результат

В alerts_warning.log должно появиться:

SPANTREE-2-ROOTGUARD_BLOCK

Проверка:

show logging | include ROOTGUARD
show spanning-tree inconsistentports
show spanning-tree vlan 1

27. SPANTREE-5-TOPOTRAP

Назначение теста

Проверка уведомления о перестроении дерева STP. По одному сообщению это ещё не авария, но как накопительный признак событие полезно.

Важно: для появления таких сообщений на Cisco должно быть включено:

spanning-tree logging

Воспроизведение

На межкоммутаторном порту без PortFast выполнить:

conf t
interface fa1/0/16
 shutdown
 no shutdown
end

Также можно выполнить тест на стенде с резервной L2-топологией, где изменение состояния uplink реально вызывает STP topology change - подключением патчкорда из одного порта в другой (один из них заблокируется через STP).

Ожидаемый результат

В alerts_behavior.log должно появиться:

SPANTREE-5-TOPOTRAP

Проверка:

show logging | include TOPOTRAP
show spanning-tree vlan 1 detail | include occurr|from|to

28. SPANTREE-5-ROOTCHANGE

Назначение теста

Проверка изменения корневого коммутатора или корневого порта.

Воспроизведение

Проверить отсутствие защиты на портах

spanning-tree guard root

На втором коммутаторе задать более низкий приоритет для VLAN 1, чтобы он начал становиться root bridge:

conf t
spanning-tree vlan 1 priority 0
end

После теста вернуть исходное значение:

conf t
spanning-tree vlan 1 priority <ИСХОДНОЕ_ЗНАЧЕНИЕ>
end
wr

Ожидаемый результат

В alerts_behavior.log должно появиться:

SPANTREE-5-ROOTCHANGE

Проверка:

show logging | include ROOTCHANGE
show spanning-tree vlan 1

29. SPANTREE-2-LOOPGUARD_BLOCK

Назначение теста

Проверка защиты Loop Guard. Loop Guard не даёт alternate/root-порту стать designated-портом при ситуации, похожей на однонаправленный отказ, когда BPDU перестают приходить.

Важно:

  • Loop Guard работает на point-to-point STP-портах;

  • Root Guard и Loop Guard нельзя включать одновременно на одном интерфейсе.

Настройка на тестовом устройстве

conf t
spanning-tree loopguard default
!
interface fa1/0/17
 description TEST_LOOPGUARD_A
 switchport mode access
 switchport access vlan 1
 no shutdown
!
interface fa1/0/18
 description TEST_LOOPGUARD_B
 switchport mode access
 switchport access vlan 1
 no shutdown
end
wr

Воспроизведение

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

После стабилизации STP на втором коммутаторе временно подавить BPDU на одном из ответных портов.

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

Ожидаемый результат

В alerts_warning.log должно появиться:

SPANTREE-2-LOOPGUARD_BLOCK

Проверка:

show logging | include LOOPGUARD
show spanning-tree inconsistentports
show spanning-tree vlan 1

30. SPANTREE-2-CHNL_MISCFG

Назначение теста

Проверка защиты от неправильной сборки EtherChannel. Событие указывает на обнаружение петли или некорректной L2-топологии из-за неправильной конфигурации канала.

Настройка на тестовом устройстве

conf t
spanning-tree etherchannel guard misconfig
!
interface range fa1/0/19 - 20
 description TEST_ETHERCHANNEL_MISCFG
 switchport trunk encapsulation dot1q
 switchport mode trunk
 channel-group 1 mode on
 no shutdown
!
interface port-channel1
 switchport trunk encapsulation dot1q
 switchport mode trunk
 no shutdown
end
wr

На некоторых моделях команда switchport trunk encapsulation dot1q отсутствует или не требуется. Если команда не поддерживается, её нужно пропустить.

Воспроизведение

На втором коммутаторе не собирать обе линии в EtherChannel. Оставить их как отдельные trunk-порты.

Ожидаемый результат

В alerts_critical.log должно появиться:

SPANTREE-2-CHNL_MISCFG

Также может появиться:

PM-4-ERR_DISABLE

Проверка:

show logging | include CHNL_MISCFG|ERR_DISABLE
show interfaces status err-disabled
show etherchannel summary

31. UDLD-4-UDLD_PORT_DISABLED

Назначение теста

Проверка реакции на однонаправленное соединение. UDLD полезен на uplink-портах, особенно на оптике.

Для теста отключения порта лучше использовать aggressive mode.

Настройка на обоих концах uplink

На первом коммутаторе:

conf t
interface gi1/0/1
 description TEST_UDLD_TO_SWITCH_2
 udld port aggressive
 no shutdown
end
wr

На втором коммутаторе:

conf t
interface gi1/0/1
 description TEST_UDLD_TO_SWITCH_1
 udld port aggressive
 no shutdown
end
wr

UDLD должен быть включён на обоих концах uplink. Режим желательно использовать одинаковый на обоих устройствах.

Проверка до теста:

show udld
show udld interface gi1/0/1
show udld neighbors
show interfaces gi1/0/1 status

До начала теста порт должен быть connected, а UDLD должен видеть соседа.

Воспроизведение через MAC ACL

Физическое выдёргивание одной жилы оптического патчкорда часто просто гасит порт на уровне L1. В таком случае будет link down/notconnect, но не обязательно будет UDLD-срабатывание.

Для контролируемого теста лучше заблокировать UDLD/control-кадры через MAC ACL на одном из концов.

На одном из коммутаторов:

conf t
!
mac access-list extended TEST_BLOCK_UDLD
 deny any host 0100.0ccc.cccc
 permit any any
!
interface Gi1/0/1
 mac access-group TEST_BLOCK_UDLD in
!
end

Важно: этот MAC используется Cisco L2 control protocols. Такой тест проводить только на отдельном стенде и только на тестовом uplink, не задействованном в боевой сети.

Ожидаемый результат

Один из концов тестового uplink должен перейти в err-disabled по причине UDLD.

Противоположный конец при этом может перейти в состояние notconnect/link down, так как соседний порт был отключён протоколом UDLD.

То есть нормальная картина может быть такой:

C9200     Gi1/0/1  err-disabled
C3750v2   Gi1/0/1  notconnect

или наоборот.

В alerts_critical.log должно появиться:

UDLD-4-UDLD_PORT_DISABLED

Проверка на обоих коммутаторах:

show logging | include UDLD|ERR|LINK|LINEPROTO
show udld interface gi1/0/1
show interfaces status err-disabled
show interface gi1/0/1 status

Возврат в исходное состояние

На том коммутаторе, где применялся MAC ACL:

conf t
interface Gi1/0/1
 no mac access-group TEST_BLOCK_UDLD in
exit
no mac access-list extended TEST_BLOCK_UDLD
end

Затем сбросить UDLD-состояние:

udld reset

Если порт не поднялся, выполнить shutdown/no shutdown:

conf t
interface Gi1/0/1
 shutdown
 no shutdown
end

32. Минимально достаточный набор проверок

Если задача — не проверить вообще всё, а убедиться, что схема _alerts работает, достаточно сделать:

  1. BPDU Guard

  2. MAC_MOVE-4-NOTIF или SW_MATM-4-MACFLAP_NOTIF

  3. STORM_CONTROL-3-FILTERED

  4. STORM_CONTROL-3-SHUTDOWN

  5. ROOTGUARD_BLOCK

  6. TOPOTRAP

  7. ROOTCHANGE

LOOPGUARD_BLOCK, CHNL_MISCFG и UDLD_PORT_DISABLED требуют более сложного межкоммутаторного стенда, поэтому их можно выполнять вторым этапом.

Настройка logrotate

33. Создание конфига logrotate

Создаём файл:

sudo touch /etc/logrotate.d/remote-syslog

Открываем его:

sudo nano /etc/logrotate.d/remote-syslog

Вставляем:

/var/log/remote/*/*.log
/var/log/remote/*/*/*.log
{
    daily
    rotate 30

    missingok
    notifempty

    compress
    delaycompress

    dateext
    dateyesterday
    dateformat -%Y%m%d

    create 0640 syslog syslog

    sharedscripts
    postrotate
        systemctl kill -s HUP rsyslog.service >/dev/null 2>&1 || true
    endscript
}

Пояснение:

  • daily — ротация раз в день;

  • rotate 30 — хранить 30 ротаций;

  • missingok — не считать ошибкой отсутствие файла;

  • notifempty — не ротировать пустые файлы;

  • compress — сжимать старые логи;

  • delaycompress — не сжимать самый свежий ротированный файл сразу;

  • dateext — использовать дату в имени архива;

  • dateyesterday — использовать дату предыдущего дня;

  • dateformat -%Y%m%d — формат имени, например all.log-20260426;

  • create 0640 syslog syslog — создать новый файл с правильными правами;

  • postrotate ... HUP rsyslog — заставить rsyslog переоткрыть файлы после ротации.

34. Проверка logrotate

Проверяем синтаксис и логику без реального выполнения:

sudo logrotate -d -f -v /etc/logrotate.d/remote-syslog

Ключи:

  • -d — debug, ничего реально не переименовывает;

  • -f — force, принудительно показывает сценарий ротации;

  • -v — подробный вывод.

В выводе должно быть видно:

dateext suffix '-20260426'
renaming /var/log/remote/192.168.1.250/all.log to /var/log/remote/192.168.1.250/all.log-20260426
creating new /var/log/remote/192.168.1.250/all.log mode = 0640

Если вместо даты видно .1, например:

renaming .../all.log to .../all.log.1

значит в реальном конфиге не применились строки:

dateext
dateyesterday
dateformat -%Y%m%d

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

sed -n l /etc/logrotate.d/remote-syslog

После проверки можно выполнить реальную принудительную ротацию:

sudo logrotate -f -v /etc/logrotate.d/remote-syslog

Важно: -f принудительно ротирует подходящие файлы. На боевом сервере использовать аккуратно.

Проверяем результат:

sudo find /var/log/remote -type f | sort

После первой ротации будет примерно так:

all.log
all.log-20260426

После следующей ротации с учётом delaycompress:

all.log
all.log-20260427
all.log-20260426.gz

35. Проверка записи после logrotate

После реальной ротации отправляем тестовое сообщение:

logger -n 127.0.0.1 -P 514 -d -p user.err -t TEST "Проверка после logrotate"

Проверяем:

sudo grep -R "Проверка после logrotate" /var/log/remote/

Если сообщение появилось в новом текущем .log, значит связка logrotate + HUP rsyslog работает корректно.

При необходимости можно посмотреть, какие файлы сейчас держит открытыми rsyslog:

sudo lsof -p $(pidof rsyslogd) | grep /var/log/remote

Установка и настройка Zabbix agent 2

36. Установка Zabbix agent 2

Скачиваем пакет подключения репозитория Zabbix 7.0 для Ubuntu 24.04:

wget https://repo.zabbix.com/zabbix/7.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_latest_7.0+ubuntu24.04_all.deb

Устанавливаем пакет репозитория:

sudo dpkg -i zabbix-release_latest_7.0+ubuntu24.04_all.deb

Обновляем список пакетов:

sudo apt update

Устанавливаем агент:

sudo apt install -y zabbix-agent2

37. Доступ Zabbix к логам

Так как логи создаются с владельцем и группой syslog:syslog, пользователя zabbix нужно добавить в группу syslog:

sudo usermod -aG syslog zabbix

Проверяем:

id zabbix

В выводе должна быть группа syslog.

После изменения групп лучше перезапустить агент:

sudo systemctl restart zabbix-agent2

38. Настройка Zabbix agent 2

Открываем файл настройки:

sudo nano /etc/zabbix/zabbix_agent2.conf

В соответствующих разделах задаём:

# Кто имеет право опрашивать агент по passive checks.
# Разрешаем подключения от серверов и/или proxy из сети 10.10.99.0/24.
Server=10.10.99.0/24

# Куда агент сам будет подключаться за active checks
# и куда будет отправлять данные по active items.
ServerActive=10.10.99.7:10051;10.10.99.8:10051

# Имя этого хоста в Zabbix.
# Должно совпадать с именем хоста, созданного в веб-интерфейсе Zabbix.
Hostname=syslog-collector

ServerActive нужно заменить на реальные адреса Zabbix Server или Zabbix Proxy.

39. Запуск Zabbix agent 2

Добавляем агент в автозагрузку:

sudo systemctl enable --now zabbix-agent2

Перезапускаем и проверяем:

sudo systemctl restart zabbix-agent2
sudo systemctl status zabbix-agent2 --no-pager

40. Примеры элементов данных Zabbix

Аварийные события

Файл:

/var/log/remote/_alerts/192.168.1.0/alerts_critical.log

Тип элемента:

Zabbix agent (active)

Ключ:

logrt[/var/log/remote/_alerts/192.168.1.0/alerts_critical\.log,"PM-4-ERR_DISABLE|SPANTREE-2-BLOCK_BPDUGUARD|UDLD-4-UDLD_PORT_DISABLED|SPANTREE-2-CHNL_MISCFG|STORM_CONTROL-3-SHUTDOWN"]

Предупреждения

Файл:

/var/log/remote/_alerts/192.168.1.0/alerts_warning.log

Ключ:

logrt[/var/log/remote/_alerts/192.168.1.0/alerts_warning\.log,"SPANTREE-2-LOOPGUARD_BLOCK|SPANTREE-2-ROOTGUARD_BLOCK|STORM_CONTROL-3-FILTERED"]

Накопительные признаки

Файл:

/var/log/remote/_alerts/192.168.1.0/alerts_behavior.log

Общий ключ:

logrt.count[/var/log/remote/_alerts/192.168.1.0/alerts_behavior\.log,"MAC_MOVE-4-NOTIF|SW_MATM-4-MACFLAP_NOTIF|SPANTREE-5-TOPOTRAP|SPANTREE-5-ROOTCHANGE"]

Отдельные ключи под разные триггеры:

logrt.count[/var/log/remote/_alerts/192.168.1.0/alerts_behavior\.log,"MAC_MOVE-4-NOTIF"]
logrt.count[/var/log/remote/_alerts/192.168.1.0/alerts_behavior\.log,"SW_MATM-4-MACFLAP_NOTIF"]
logrt.count[/var/log/remote/_alerts/192.168.1.0/alerts_behavior\.log,"SPANTREE-5-TOPOTRAP"]
logrt.count[/var/log/remote/_alerts/192.168.1.0/alerts_behavior\.log,"SPANTREE-5-ROOTCHANGE"]

41. Финальная проверка после настройки

Проверяем rsyslog:

sudo systemctl status rsyslog --no-pager
sudo ss -ulpn | grep ':514'
sudo ss -tlpn | grep ':514'

Проверяем тестовую запись:

logger -n 127.0.0.1 -P 514 -d -p user.err -t TEST "Финальная проверка syslog"
sudo grep -R "Финальная проверка syslog" /var/log/remote/

Проверяем logrotate:

sudo logrotate -d -f -v /etc/logrotate.d/remote-syslog

Проверяем Zabbix agent:

sudo systemctl status zabbix-agent2 --no-pager
id zabbix

Проверяем отправку с Cisco:

send log 5 TEST_LEVEL5_SYSLOG
show logging

На syslog-сервере:

sudo grep -R "TEST_LEVEL5_SYSLOG" /var/log/remote/

Если сообщение найдено, базовая связка Cisco -> rsyslog работает.

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

Back to top