Перейти к содержимому
Калькуляторы

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем yakuzzza

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

ротейтит

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Тоже за 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 файлов старше года.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

спасибо за подсказку, хорошо работает с сислог-нг, а вопрос такой возник, там надо на каждый адрес прописывать в конфиге, чтоб по файлам расскладывал, или как то можно унифицировать и в 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);

};

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Изменено пользователем s.lobanov

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Из практики:

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

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

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.