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

Appearance

Arista EOS ​

Сетевое оборудование Arista под управлением EOS (Extensible Operating System) генерирует системные сообщения о работе интерфейсов, протоколов маршрутизации и коммутации, MLAG, аппаратных компонентов, действиях администраторов, изменениях конфигурации и других событиях.

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

Это особенно полезно для современных Leaf-Spine, Data Center и EVPN/VXLAN сетей, где одно изменение может практически одновременно затронуть несколько коммутаторов и сетевых сервисов.

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

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

  • физических и логических интерфейсов;
  • Port-Channel и LACP;
  • MLAG;
  • VLAN;
  • STP;
  • LLDP;
  • BGP;
  • OSPF;
  • IS-IS;
  • EVPN;
  • VXLAN;
  • VRF;
  • MAC и ARP/ND;
  • аппаратных компонентов;
  • питания, вентиляторов и температуры;
  • перезагрузок оборудования;
  • системных процессов EOS;
  • действий пользователей;
  • SSH и AAA;
  • изменений конфигурации;
  • ошибок и предупреждений;
  • отдельных событий очередей и производительности;
  • других процессов и сервисов EOS.

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

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

Arista EOS использует стандартный механизм Syslog.

Журналы могут одновременно направляться:

  • в оперативный буфер;
  • на консоль;
  • в CLI-сессию;
  • в persistent storage;
  • на один или несколько удаленных Syslog-серверов.

Удаленный сервер задается командой:

text
logging host

Уровень сообщений для удаленного Syslog задается через:

text
logging trap

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

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

text
192.0.2.10

Минимальная конфигурация:

text
configure terminal

logging host 192.0.2.10
logging trap informational

end
write memory

По умолчанию стандартным портом Syslog является 514, а типовым транспортом — UDP.

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

text
Arista EOS
    │
    │ Syslog UDP/514
    ▼
   LOGG

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

Для постоянной эксплуатации желательно дополнительно определить стабильный source interface, facility и современный формат сообщения.

Например:

text
configure terminal

logging host 192.0.2.10
logging trap informational
logging source-interface Loopback0
logging facility local7
logging format rfc5424

end
write memory

Такая конфигурация обеспечивает:

  • централизованную отправку событий;
  • единый уровень журналирования;
  • стабильный адрес источника;
  • единую Syslog facility;
  • структурированный современный формат сообщений.

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

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

УровеньНазваниеНазначение
0emergenciesсистема неработоспособна
1alertsтребуется немедленное действие
2criticalкритическое состояние
3errorsошибка
4warningsпредупреждение
5notificationsважное штатное событие
6informationalинформационное событие
7debuggingотладочная информация

Для эксплуатации обычно рекомендуется:

text
logging trap informational

Это позволяет передавать в LOGG сообщения уровней 0–6.

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

Source Interface ​

В сетях Leaf-Spine один коммутатор обычно имеет несколько физических и логических адресов.

Чтобы LOGG всегда идентифицировал устройство одинаково, рекомендуется явно определить source interface.

Например:

text
logging source-interface Loopback0

Это особенно полезно для:

  • Spine;
  • Leaf;
  • Border Leaf;
  • маршрутизаторов;
  • устройств с несколькими uplink;
  • инфраструктуры с ECMP.

Независимо от того, по какому маршруту Syslog достигает LOGG, источником будет стабильный адрес Loopback0.

Facility ​

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

text
logging facility local7

Например, внутри организации можно принять соглашение:

text
Network Equipment → local7 → LOGG

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

RFC 5424 ​

Современные версии EOS поддерживают формат RFC 5424.

Включить его можно командой:

text
logging format rfc5424

RFC 5424 предпочтителен для централизованной машинной обработки, поскольку предоставляет более формализованное представление Syslog-события.

Для LOGG такой формат удобен для:

  • парсинга;
  • нормализации;
  • выделения severity и facility;
  • автоматической классификации;
  • последующего анализа.

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

Точные временные метки ​

EOS позволяет использовать высокоточные timestamp.

Для событий в высоконагруженных сетях это особенно важно.

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

text
10:21:14.102  LEAF-01   Ethernet3 down
10:21:14.187  LEAF-01   Port-Channel12 changed
10:21:14.241  LEAF-02   MLAG peer event
10:21:14.396  SPINE-01  BGP neighbor changed
10:21:14.728  LEAF-04   EVPN route withdrawn

Чем точнее timestamp, тем проще определить реальную последовательность событий.

Современные версии EOS позволяют использовать high-resolution timestamps совместно с настройками logging format.

UDP и TCP ​

Типовая конфигурация использует UDP:

text
logging host 192.0.2.10

Также EOS позволяет явно определить транспорт.

Например:

text
logging host 192.0.2.10 514 protocol udp

или при необходимости:

text
logging host 192.0.2.10 601 protocol tcp

Использование TCP может быть полезно там, где потеря отдельных сообщений нежелательна.

Необходимо убедиться, что соответствующий порт разрешен:

  • на LOGG;
  • на промежуточных firewall;
  • в ACL;
  • в management-сети.

TLS ​

В современных версиях EOS для отдельных вариантов удаленного Syslog доступен также транспорт TLS.

Это позволяет строить защищенную схему передачи:

text
Arista EOS
     │
     │ Syslog / TLS
     ▼
    LOGG

Поддержку TLS и конкретный синтаксис следует проверять для установленной версии EOS и используемой схемы logging/VRF.

Management VRF ​

Для Arista очень характерно использование отдельной management-сети.

Если LOGG находится в отдельном VRF, Syslog можно направить через него.

Например:

text
logging vrf MGMT host 192.0.2.10

И определить source interface внутри этого VRF:

text
logging vrf MGMT source-interface Management1

или другой соответствующий интерфейс.

В результате эксплуатационный трафик:

text
SSH
SNMP
NTP
Syslog

может быть полностью отделен от пользовательского и сервисного трафика.

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

EOS позволяет настроить несколько Syslog hosts.

Например:

text
logging host 192.0.2.10
logging host 192.0.2.11

Это может использоваться для:

  • резервирования;
  • параллельной передачи в несколько LOGG;
  • одновременной передачи в LOGG и SIEM;
  • миграции между системами журналирования.

Например:

text
             ┌── LOGG
Arista EOS ──┤
             └── SIEM

Фильтрация сообщений ​

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

Сообщения можно фильтровать по:

  • facility;
  • severity;
  • process / tag;
  • содержимому сообщения.

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

Для удаленного логирования используются возможности logging trap system.

Пример логики:

text
BGP events        → LOGG
MLAG events       → LOGG
AAA events        → LOGG
critical system   → LOGG

При первоначальном внедрении не рекомендуется слишком жестко фильтровать сообщения.

Практически полезнее:

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

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

Локальный буфер ​

EOS хранит системные сообщения и локально.

Размер и уровень buffer logging можно настраивать:

text
logging buffered

Просмотреть текущие сообщения и настройки можно через:

text
show logging

Локальный буфер полезен:

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

Persistent Logging ​

При необходимости EOS может сохранять журнал на flash между перезагрузками.

Например:

text
logging persistent 1000000

Однако persistent logging следует использовать осознанно.

Интенсивная постоянная запись системных сообщений увеличивает нагрузку на flash-память устройства.

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

Таким образом:

text
локальный buffer → оперативная диагностика

LOGG → централизованная история

NTP ​

Для анализа последовательности событий весь парк Arista должен использовать согласованный источник времени.

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

Например:

text
show ntp status
show ntp associations

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

text
show clock

Особенно важна синхронизация для Leaf-Spine и EVPN/VXLAN инфраструктур, где реакция сразу нескольких устройств может происходить в пределах миллисекунд.

События Leaf-Spine ​

Arista широко используется в Data Center сетях, поэтому централизованный журнал особенно полезен для анализа распределенных сетевых событий.

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

text
LEAF-01:
Ethernet3 down

LEAF-01:
BGP neighbor down

SPINE-01:
BGP route withdrawn

LEAF-07:
EVPN route removed

LOGG позволяет собрать их в единую временную шкалу:

text
Physical Link Failure
        ↓
Port-Channel Change
        ↓
BGP Session Change
        ↓
EVPN Route Withdrawal
        ↓
Traffic Re-convergence

То есть инженер видит уже не просто набор Syslog-сообщений, а развитие сетевого события.

MLAG ​

Для Arista отдельное значение имеют события MLAG.

Журналы могут помочь анализировать:

  • состояние MLAG peer;
  • peer-link;
  • Port-Channel;
  • dual-primary ситуации;
  • изменения состояния связанных интерфейсов.

При аварии LOGG позволяет сопоставить сообщения сразу двух MLAG peers и зависимого оборудования.

Вместо анализа двух отдельных CLI-сессий инженер получает единую временную последовательность.

BGP / EVPN / VXLAN ​

В современных Arista-сетях Syslog особенно полезен при анализе control plane.

Можно сопоставлять:

text
Interface
   ↓
BGP
   ↓
EVPN
   ↓
VXLAN
   ↓
Service

Например:

text
uplink down
    ↓
BGP neighbor lost
    ↓
EVPN prefixes withdrawn
    ↓
remote VTEP reachability changed
    ↓
application connectivity affected

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

Контроль действий администратора ​

EOS генерирует события, связанные с:

  • SSH;
  • AAA;
  • входом пользователей;
  • системными сервисами;
  • изменениями конфигурации.

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

Например:

text
14:05:03  administrator login
14:07:21  configuration changed
14:07:25  interface changed
14:07:26  BGP neighbor down
14:07:27  EVPN routes withdrawn

Это полезно как для эксплуатации, так и для расследования инцидентов.

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

Основная команда:

text
show logging

Она показывает:

  • включено ли журналирование;
  • состояние buffer logging;
  • console logging;
  • persistent logging;
  • trap logging;
  • severity;
  • Syslog hosts;
  • порты;
  • transport;
  • VRF;
  • facility.

Например, в выводе можно увидеть:

text
Trap logging: level informational
Logging to '192.0.2.10' port 514 in VRF default via udp

Текущую конфигурацию также можно проверить:

text
show running-config section logging

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

text
ping 192.0.2.10

Если используется management VRF:

text
ping vrf MGMT 192.0.2.10

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

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

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

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

text
show logging
show running-config section logging
show clock
show ntp status

Рекомендуемая конфигурация ​

Для типовой инфраструктуры без отдельного management VRF:

text
configure terminal

logging host 192.0.2.10
logging trap informational
logging source-interface Loopback0
logging facility local7
logging format rfc5424

end
write memory

Для сети с отдельным management VRF схема может выглядеть так:

text
configure terminal

logging vrf MGMT host 192.0.2.10
logging vrf MGMT source-interface Management1
logging trap informational
logging facility local7
logging format rfc5424

end
write memory

Конкретный синтаксис следует проверить для установленной версии EOS.

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

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

Шаблон должен определять:

  • серверы LOGG;
  • VRF;
  • source interface;
  • transport;
  • port;
  • severity;
  • facility;
  • RFC 5424;
  • NTP;
  • локальный buffer;
  • правила фильтрации.

Для Leaf-Spine инфраструктуры особенно важно обеспечить одинаковую настройку времени и идентификации оборудования.

Например:

text
SPINE-01
SPINE-02

LEAF-001
LEAF-002
LEAF-003
...

BORDER-LEAF-01
BORDER-LEAF-02

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

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

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

text
Ethernet Down
BGP Peer Down
MLAG State Changed
EVPN Route Withdrawn

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

LOGG собирает сообщения от Leaf, Spine, Border Leaf, серверов, операционных систем и приложений и восстанавливает общую последовательность:

физический линк потерян → Port-Channel изменился → BGP-соседство разорвано → EVPN-маршруты отозваны → трафик перестроился → сервис испытал деградацию.

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

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

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