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

Appearance

Для QTECH я бы сделал чуть более осторожную инструкцию: у производителя много семейств коммутаторов и маршрутизаторов, а синтаксис CLI между QSW разных поколений может различаться. Ниже — универсальная структура страницы с явным указанием проверять команды по конкретной модели.

QTECH ​

Сетевое оборудование QTECH генерирует системные сообщения о состоянии интерфейсов, сетевых протоколов, аппаратных компонентов, действиях администраторов, изменениях конфигурации, ошибках и других событиях.

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

QTECH выпускает несколько семейств сетевого оборудования с различающимися версиями программного обеспечения и CLI. Приведенные команды следует рассматривать как типовой пример. Перед массовым применением необходимо проверить синтаксис для конкретной модели и версии ПО.

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

В LOGG могут передаваться системные сообщения QTECH, в том числе:

  • изменение состояния физических интерфейсов;
  • события VLAN;
  • STP/RSTP/MSTP;
  • Link Aggregation / LACP;
  • события маршрутизации;
  • изменения состояния соседей;
  • ошибки и предупреждения оборудования;
  • события питания и температуры;
  • события PoE на соответствующих моделях;
  • перезагрузки оборудования;
  • аппаратные и программные ошибки;
  • действия администраторов;
  • успешные и неуспешные попытки доступа;
  • изменения конфигурации;
  • события безопасности;
  • другие системные сообщения.

Конкретный набор зависит от модели устройства, версии ПО и настроенного уровня журналирования.

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

На многих управляемых коммутаторах QTECH для удаленного Syslog используется конфигурация вида:

text
configure terminal

logging server 192.0.2.10
logging level informational

end

Где:

  • 192.0.2.10 — IP-адрес сервера LOGG;
  • informational — уровень передаваемых сообщений.

На других версиях CLI для определения сервера может использоваться команда семейства:

text
logging host 192.0.2.10

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

Типовая схема ​

В большинстве инфраструктур используется классический Syslog:

text
QTECH
   │
   │ Syslog UDP/514
   ▼
 LOGG

UDP/514 остается наиболее распространенным вариантом передачи журналов сетевого оборудования.

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

Уровни журналирования ​

Syslog использует стандартные уровни severity:

УровеньНазваниеНазначение
0Emergencyсистема неработоспособна
1Alertтребуется немедленное вмешательство
2Criticalкритическая ошибка
3Errorошибка
4Warningпредупреждение
5Noticeважное штатное событие
6Informationalинформационное сообщение
7Debugотладочная информация

Для эксплуатационного мониторинга рекомендуется начинать с уровня Informational.

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

Уровень Debug следует включать только при диагностике конкретной проблемы — он способен существенно увеличить поток журналов.

Какие события особенно полезны ​

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

text
Interface Up / Down
        ↓
LAG / LACP Change
        ↓
STP Topology Change
        ↓
Routing Change
        ↓
Service Impact

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

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

Facility ​

Если используемая версия ПО позволяет настраивать Syslog facility, для сетевого оборудования удобно применять единое значение, например:

text
local7

В инфраструктуре можно принять соглашение:

text
Network Equipment → local7 → LOGG

Это упрощает классификацию и последующую обработку сообщений.

Стабильный адрес источника ​

На устройствах с несколькими IP-интерфейсами желательно явно определить адрес или интерфейс, используемый для отправки Syslog.

В зависимости от модели это может быть:

  • management-интерфейс;
  • Loopback;
  • другой стабильный L3-интерфейс.

Типовая логика:

text
QSW-CORE-01
Loopback0: 10.10.10.1
       │
       │ Syslog
       ▼
      LOGG

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

Наличие отдельной команды source-interface и ее синтаксис необходимо проверять для конкретной версии ПО QTECH.

Имена устройств ​

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

Например:

text
DC1-CORE-QSW-01
DC1-AGG-QSW-01
DC1-ACCESS-QSW-023
OFFICE2-QSW-004

Единая схема именования существенно упрощает поиск и сопоставление событий.

Особенно это заметно при эксплуатации сотен коммутаторов.

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

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

При наличии соответствующей функции рекомендуется сохранять часть сообщений в локальном buffer устройства.

Это полезно:

  • при временной недоступности LOGG;
  • при потере management-сети;
  • при диагностике самого устройства;
  • для проверки генерации событий.

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

Несколько серверов ​

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

text
             ┌── LOGG
QTECH ───────┤
             └── SIEM

или:

text
             ┌── LOGG-1
QTECH ───────┤
             └── LOGG-2

Это позволяет реализовать:

  • резервирование;
  • параллельный сбор;
  • интеграцию с SIEM;
  • постепенную миграцию между системами.

Фильтрация ​

При большом количестве оборудования объем журналов может быть значительным.

Обычно имеет смысл управлять потоком как минимум по severity.

При наличии соответствующих возможностей конкретной модели можно дополнительно ограничивать сообщения по:

  • подсистеме;
  • типу события;
  • severity;
  • другим параметрам.

Однако первоначально лучше использовать достаточно полный поток.

Практический подход:

собрать → измерить → классифицировать → фильтровать.

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

Время и NTP ​

Для централизованного анализа критически важна синхронизация времени.

Все QTECH и серверы LOGG должны использовать согласованные источники времени.

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

  • системное время;
  • временную зону;
  • состояние синхронизации.

Это позволяет LOGG корректно выстроить события разных устройств:

text
10:21:14.102  CORE-01     Uplink Down
10:21:14.481  AGG-01      LACP member Down
10:21:15.037  ACCESS-12   STP topology change
10:21:16.204  ROUTER-01   Route changed
10:21:18.671  SERVER-04   Connection timeout

Без синхронизации времени определить реальную последовательность значительно сложнее.

Проверка настройки ​

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

  • текущую конфигурацию Syslog;
  • адрес удаленного сервера;
  • severity;
  • сетевую доступность LOGG;
  • наличие локальных событий.

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

Также следует проверить доступность сервера:

text
ping 192.0.2.10

После этого убедитесь, что устройство появилось среди источников LOGG.

Тестирование ​

Для проверки лучше создать безопасное контролируемое событие.

Например:

  • выполнить административный вход;
  • создать событие авторизации;
  • выполнить другое штатное действие, формирующее Syslog.

После этого необходимо:

  1. найти событие в локальном журнале;
  2. найти его в LOGG;
  3. проверить hostname;
  4. проверить source IP;
  5. проверить timestamp;
  6. проверить severity и facility.

После успешного теста конфигурацию можно распространять на остальные устройства этой же серии.

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

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

  1. Включено ли системное журналирование.
  2. Настроен ли удаленный Syslog-сервер.
  3. Правильно ли указан IP-адрес LOGG.
  4. Правильно ли указан порт.
  5. Доступен ли LOGG с устройства.
  6. Есть ли маршрут до сервера.
  7. Не блокируется ли UDP/514 ACL или межсетевым экраном.
  8. Правильно ли выбран severity.
  9. Правильно ли выбран source interface, если он задан.
  10. Генерирует ли устройство сообщения локально.
  11. Принимает ли LOGG сообщения на нужном интерфейсе и порту.
  12. Синхронизировано ли время устройства.

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

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

text
QTECH
   │
   ├── единый hostname
   ├── единый NTP
   ├── стабильный source IP
   ├── severity informational
   ├── facility local7
   ├── локальный buffer
   │
   └── LOGG

Политика должна определять:

  • адреса серверов LOGG;
  • transport;
  • port;
  • severity;
  • facility;
  • source interface;
  • NTP;
  • локальное журналирование;
  • правила фильтрации.

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

При наличии десятков или сотен устройств QTECH Syslog желательно настраивать не вручную на каждом коммутаторе, а как централизованную эксплуатационную политику.

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

  • серии;
  • модели;
  • версии программного обеспечения;
  • роли устройства.

Например:

text
CORE
AGGREGATION
ACCESS
DATACENTER

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

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

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

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

text
Port Down
LACP Changed
STP Topology Changed

Но это только локальная часть происходящего.

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

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

uplink потерян → агрегированный канал изменился → перестроилась L2-топология → изменились сетевые пути → сервис испытал деградацию.

Так журналы превращаются из набора сообщений в историю поведения инфраструктуры.

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

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

Важно: линейка QTECH включает оборудование с различными поколениями CLI. Перед применением примеров необходимо сверить команды с руководством именно для используемой модели и версии ПО. Для массового внедрения рекомендуется сначала проверить шаблон на одном устройстве каждого типа.