чем собирать логи со свитчей которые могут слать их на удаленный сервер

[Cramac]

Всем привет. Собственно вопрос. Чем собрать?

В свитчах есть фишка Remote Logs хочется где то централизованно смотреть логи

[EvilShadow]

Скорее всего это обычный syslog. Поднимаете на каком-то узле syslog-демон и шлёте логи туда. А демон их уже складывает, как указано. Рекомендую syslog-ng, у него большие возможности для настройки.

[yakuzzza]

Поддерживаю про syslog-ng. Очень гибкий. Главное 1 раз сконфигурировать. Потом сортирует пишет ротейтит как захотели.

Edited November 16, 2010 by yakuzzza

[s.lobanov]

Тоже за syslog-ng, очень удобно, гибко, особенно если много железа и разного. А в syslog-ng 3 добавили логирование в БД(oracle, pgsql, mysql, ещё что-то), вот мини-манул для сборки http://forum.nag.ru/forum/index.php?s=&amp...st&p=529786 (если нет в дистрибутиве)

 

ротейтит

хм... в самом деле? я думал, что этим занимается logrotate, если я ошибаюсь, то можно пример конфига, где syslog-ng ротейтит

[Cramac]

спасибо, попробуем

[yakuzzza]

Тоже за syslog-ng, очень удобно, гибко, особенно если много железа и разного. А в syslog-ng 3 добавили логирование в БД(oracle, pgsql, mysql, ещё что-то), вот мини-манул для сборки http://forum.nag.ru/forum/index.php?s=&amp...st&p=529786 (если нет в дистрибутиве)

 

ротейтит

хм... в самом деле? я думал, что этим занимается logrotate, если я ошибаюсь, то можно пример конфига, где syslog-ng ротейтит

Вы не ошибаетесь.

Ротейтит как правило logrotate, каюсь.

В моих случаях ротации логов не было. Был сбор логов и сортировка по директориям в формат вида /var/log/$DeviceType/$DeviceID/$Y/$M/$D/$DeviceID.log и потом удаление с помощью find файлов старше года.

[Cramac]

спасибо за подсказку, хорошо работает с сислог-нг, а вопрос такой возник, там надо на каждый адрес прописывать в конфиге, чтоб по файлам расскладывал, или как то можно унифицировать и в 1 правило уписать?

 

у меня с 1 работает так:

 

filter 10.10.10.253 { netmask("10.10.10.253"); };

destination 10.10.10.253 { file("/var/log/10.10.10.253"); };

log {

source(s_all);

filter(10.10.10.253);

destination(10.10.10.253);

};

[s.lobanov]

Можно конечно. Как-то так:

destination BY_IP { file("/var/log/$SOURCEIP"); };

 

Но делать так не советую. Грепнуть по IP из общего файла - пустяк, а смотреть что случилось в период с 14:01 по 14:03 будет проблематично. Самый правильный способ ИМХО - кидать в общий файлик и в базу(потом уже делать селекты по любому критерию)

Edited November 19, 2010 by s.lobanov

[Cramac]

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

[s.lobanov]

Я имею ввиду, что когда надо будет грепнуть по всем свитчам с 14:01 до 14:03 (например если возникла какая-то проблема с stp и нужно посмотреть что они слали в сислог). Если делать что-то типа grep -F '14:01' *.log, то увидите сообщения по первому свитчу, потом по второму и т.д., а хочется видеть "хронологию" событий.

 

Вообщем решать-то всё равно Вам, но общий лог лучше тоже иметь ИМХО.

[Cramac]

да, ситуации разные, об этом и не думал.

[terrible]

Из практики:

собираем всё в БД, все сообщение парсятся и аккуратно складируются в БД.

Хронология события на лицо + возможность вывести сообщения по какому-либо конкретному правилу(тип или id оборудования или порту оборудования, или маку, засветившемуся на каком-либо порту и т.п., короче практически по любым критериям). Тем самым мы получаем полную историю путешествия мак-адреса клиента и статуса работы железок.

 

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

[s.lobanov]

Всё правильно, только в теории надо собирать трапы(где уже всё разложено по блюдечкам), а не парсить логи, но на практике... то, что на практике.