Cramac Опубликовано 16 ноября, 2010 · Жалоба Всем привет. Собственно вопрос. Чем собрать? В свитчах есть фишка Remote Logs хочется где то централизованно смотреть логи Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
EvilShadow Опубликовано 16 ноября, 2010 · Жалоба Скорее всего это обычный syslog. Поднимаете на каком-то узле syslog-демон и шлёте логи туда. А демон их уже складывает, как указано. Рекомендую syslog-ng, у него большие возможности для настройки. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
yakuzzza Опубликовано 16 ноября, 2010 (изменено) · Жалоба Поддерживаю про syslog-ng. Очень гибкий. Главное 1 раз сконфигурировать. Потом сортирует пишет ротейтит как захотели. Изменено 16 ноября, 2010 пользователем yakuzzza Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 16 ноября, 2010 · Жалоба Тоже за syslog-ng, очень удобно, гибко, особенно если много железа и разного. А в syslog-ng 3 добавили логирование в БД(oracle, pgsql, mysql, ещё что-то), вот мини-манул для сборки http://forum.nag.ru/forum/index.php?s=&...st&p=529786 (если нет в дистрибутиве) ротейтит хм... в самом деле? я думал, что этим занимается logrotate, если я ошибаюсь, то можно пример конфига, где syslog-ng ротейтит Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 16 ноября, 2010 · Жалоба спасибо, попробуем Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
yakuzzza Опубликовано 16 ноября, 2010 · Жалоба Тоже за syslog-ng, очень удобно, гибко, особенно если много железа и разного. А в syslog-ng 3 добавили логирование в БД(oracle, pgsql, mysql, ещё что-то), вот мини-манул для сборки http://forum.nag.ru/forum/index.php?s=&...st&p=529786 (если нет в дистрибутиве) ротейтит хм... в самом деле? я думал, что этим занимается logrotate, если я ошибаюсь, то можно пример конфига, где syslog-ng ротейтит Вы не ошибаетесь. Ротейтит как правило logrotate, каюсь. В моих случаях ротации логов не было. Был сбор логов и сортировка по директориям в формат вида /var/log/$DeviceType/$DeviceID/$Y/$M/$D/$DeviceID.log и потом удаление с помощью find файлов старше года. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 19 ноября, 2010 · Жалоба спасибо за подсказку, хорошо работает с сислог-нг, а вопрос такой возник, там надо на каждый адрес прописывать в конфиге, чтоб по файлам расскладывал, или как то можно унифицировать и в 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); }; Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 19 ноября, 2010 (изменено) · Жалоба Можно конечно. Как-то так: destination BY_IP { file("/var/log/$SOURCEIP"); }; Но делать так не советую. Грепнуть по IP из общего файла - пустяк, а смотреть что случилось в период с 14:01 по 14:03 будет проблематично. Самый правильный способ ИМХО - кидать в общий файлик и в базу(потом уже делать селекты по любому критерию) Изменено 19 ноября, 2010 пользователем s.lobanov Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 19 ноября, 2010 · Жалоба почему проблематично? он же в отдельный файл пишет и дату и время, все как в общем. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 19 ноября, 2010 · Жалоба Я имею ввиду, что когда надо будет грепнуть по всем свитчам с 14:01 до 14:03 (например если возникла какая-то проблема с stp и нужно посмотреть что они слали в сислог). Если делать что-то типа grep -F '14:01' *.log, то увидите сообщения по первому свитчу, потом по второму и т.д., а хочется видеть "хронологию" событий. Вообщем решать-то всё равно Вам, но общий лог лучше тоже иметь ИМХО. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 19 ноября, 2010 · Жалоба да, ситуации разные, об этом и не думал. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
terrible Опубликовано 19 ноября, 2010 · Жалоба Из практики: собираем всё в БД, все сообщение парсятся и аккуратно складируются в БД. Хронология события на лицо + возможность вывести сообщения по какому-либо конкретному правилу(тип или id оборудования или порту оборудования, или маку, засветившемуся на каком-либо порту и т.п., короче практически по любым критериям). Тем самым мы получаем полную историю путешествия мак-адреса клиента и статуса работы железок. Если вы считаете, что это в моей схеме есть ошибки и недочеты - очень прошу объяснить. Как программист, я пока ещё не нашёл более подходящей схемы (для системного администратора) для получения всей истории произошедших событий (с абонентом или оборудованием), дальнейшего анализа и принятия решений. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 19 ноября, 2010 · Жалоба Всё правильно, только в теории надо собирать трапы(где уже всё разложено по блюдечкам), а не парсить логи, но на практике... то, что на практике. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...