[mousus]

На сервер с syslog с коммутаторов доступа (очень много) сливаются на local7 логи со всех коммутаторов. Появилась необходимость предоставить диспетчерам на дежурной смене понятный интерфейс для отслеживания истории коммутаторов. Каким ПО можно реализовать требуемый функционал?

[Ilya Evseev]

Планируем добавить в routers_mgmt, обсуждение тут:

http://forum.nag.ru/forum/index.php?showtopic=54023

 

Сейчас думаем, как лучше: слушать syslog через pipe или разбирать /var/log/local7.log?

У вас syslog на freebsd или на linux?

[Cosmonaut]

А почему сразу не складывать логи в БД? Syslog-ng это умеет.

[pliskinsad]

cat, grep ....

[littlesavage]

rsyslog + mysql.

Ну или в сторону mongodb в качестве хранилища логов посмотреть.

[mousus]

у нас freebsd, собственно самыми животрепещущими вопросами являются -- ротация и удобоваримость для оперативного мониторинга, что например очень важно при грозе когда мрёт часть оборудования, а часть сходит с ума и начинает гадить в сеть, после чего становится весело)) собсно говоря тут самое то весёлое отследить именно тенденции аварии по логам что без красивой морды убивает кучу времени

[littlesavage]

Кстати, веб-морда на php: http://loganalyzer.adiscon.com/

И с mongodb, оказывается, вариант уже есть: http://www.graylog2.org/ с веб-интерфейсом на рельсах.

Изменено 14 августа, 2010 пользователем littlesavage

[Negator]

Юзайте не логи а трапы

по событию можно выставить все что угодно

 

[terrible]

Юзаем и логи, и трапы. Всё собирает, парсит и обрабатывает биллинг. По контенту сообщения привязываем к свичу, влану, порту абонента, маку-абонента. Так-же мониторим повышеннение нагрузки, отклика от свичей, есть возможно приоритезирования определённого рода сообщений. Мегаинформативность! Всё самописное, готовых решений аналогичного функционала не встречал.

[s.lobanov]

Кстати, веб-морда на php: http://loganalyzer.adiscon.com/

И с mongodb, оказывается, вариант уже есть: http://www.graylog2.org/ с веб-интерфейсом на рельсах.

Посмотрел я mongodb, самая пакость в том, что на 32ух-битных машинах размер базы может быть не более ~2.5Гб(откуда такая цифра читайте у них на сайте), я конечно понимаю, что новые серваки идут x86_64, но если уже стоит i386 и отлично справляется, то как-то не хочется переносить весь функционал на x86_64

[terrible]

размер базы может быть не более ~2.5Гб

Вы собираетесь хранить логи за полгода? зачем?

[s.lobanov]

Ну вот только за сегодня с коммутаторов доступа уже набежало 14 метров логов, значит к ночи будет 20, за месяц получается 600М, итого хватит на 4 месяца, т.е. я вместо того, чтобы выделить сотню-другую гиг под базу и установить на мониторинг свободное место на разделе, должен каждые 4 месяца(реально, каждые 3) вспоминать о том, что надо бы почистить базу(или проверить как отработает скрипт в кроне).

Это напоминает извращения с лицензиями, когда люди каждый месяц скачивают очередной триальный ключ. Нафиг оно мне, я уже собрал syslog-ng v3 с поддержкой sql (oracle, pgsql, mssql, ещё что-то) через dbi, оно даже работает, буду смотреть на производительность, но и так уверен, что ~200000 insert'ов в день это пустяки для postgres. Если кому интересно, то могу поделиться конфигом для связки syslog-ng 3.0.8 и postgres 8.3

Изменено 16 августа, 2010 пользователем s.lobanov

[littlesavage]

s.lobanov, ограничение вижу только для capped collections.

А там как раз фишка в том, что ничего чистить не надо: новые записи пишутся поверх старых.

 

А вот постгресовскую базу все равно придется временами чистить.

[mousus]

Ну вот только за сегодня с коммутаторов доступа уже набежало 14 метров логов, значит к ночи будет 20, за месяц получается 600М, итого хватит на 4 месяца, т.е. я вместо того, чтобы выделить сотню-другую гиг под базу и установить на мониторинг свободное место на разделе, должен каждые 4 месяца(реально, каждые 3) вспоминать о том, что надо бы почистить базу(или проверить как отработает скрипт в кроне).

Это напоминает извращения с лицензиями, когда люди каждый месяц скачивают очередной триальный ключ. Нафиг оно мне, я уже собрал syslog-ng v3 с поддержкой sql (oracle, pgsql, mssql, ещё что-то) через dbi, оно даже работает, буду смотреть на производительность, но и так уверен, что ~200000 insert'ов в день это пустяки для postgres. Если кому интересно, то могу поделиться конфигом для связки syslog-ng 3.0.8 и postgres 8.3

замечательный вариант решения, если не затруднит то поделитесь пожалуйста на mousus (гав/мяу) rambler.ru

[s.lobanov]

ok, как будет время опишу процесс установки syslog-ng3 и интеграции с postgres

[s.lobanov]

Пишу без зависимостей и прочей ерунды, предполагается, что вывод configure понятен и что доставлять тоже понятно

 

libdbi-0.8.3.tar.gz

./configure --disable-docs

make

make install

ldconfig

libdbi-drivers-0.8.3-1.tar.gz

./configure --with-pgsql

make

make install

ldconfig

 

Проверяем: в /usr/local/lib должны появится файлы libdbi.so и подобные, а также dbd/libdbdpgsql.so и подобные

 

syslog-ng_3.0.8.tar.gz

./configure --prefix=/opt/syslog-ng3

Смотрим, что конфигуре написал в конце, поддержка sql должна быть enable

make

make install

 

 

Создаём файл /opt/syslog-ng3/etc/syslog-ng.conf:

 

@version: 3.0

options {
    use_dns(no); 
};

source src_remote
{
        udp(ip("0.0.0.0") port(514));
        tcp(ip("0.0.0.0") port(514));
};

destination d_pgsql {
        sql(type(pgsql)
        host("IP_DB") username("syslog_USER") password("syslog_PASS")
        database("db_NAME")
        table("rlogs")

        columns("host cidr",  "pri smallint", "msg text")
        values("$HOST_FROM", "$PRI", "$MSGONLY")
#на indexes не обращаем внимание, просто чтоб не было лишнего warning
        indexes("host", "truetime", "pri")
    );
};
#template t_test {template("$ISODATE LEVEL=$LEVEL PRI=$PRI PRIOR=$PRIORITY FAC=$FACILITY TAG=$TAG $STAMP $MSG\n"); template_escape(no); };
#destination d_test {file("/var/log/test.log" template(t_test)); };
#log { source(src_remote); destination(d_test); };

log { source(src_remote); destination(d_pgsql); };

 

ДО ЗАПУСКА syslog_ng в базе db_NAME заводим пользователя syslog_USER, создаём таблицу rlogs:

 

CREATE TABLE rlogs (
    host cidr NOT NULL,
    truetime timestamp with time zone DEFAULT now() NOT NULL,
    pri smallint NOT NULL,
    msg text NOT NULL
);


COMMENT ON TABLE rlogs IS 'Логи с коммутаторов';
COMMENT ON COLUMN rlogs.host IS 'IP адрес утройства';
COMMENT ON COLUMN rlogs.truetime IS 'Время события(по серверу(субд))';
COMMENT ON COLUMN rlogs.pri IS 'Приоритет (facility и severity в одном флаконе)';
COMMENT ON COLUMN rlogs.msg IS 'Само сообщение(включая время по мнению удалённой железки)';
GRANT ALL ON TABLE rlogs TO syslog_USER;

 

Индексы на своё усмотрение, смотря какие выборки вам нужны

 

Прописываем что нужно в pg_hba.conf, делаем reload postgres'а

 

Отладочный запуск syslog_ng:

/opt/syslog-ng3/sbin/syslog-ng -F -v -e

 

шлём на сервер что-нибудь на udp 514, проверяем появляется ли что-нибудь в базе

 

Запуск syslog-ng:

/opt/syslog-ng3/sbin/syslog-ng

 

reload делается стандратно, kill -HUP

[Max P]

а не проще rsyslog привязать к постгресу? оно ж из коробки это умеет, у меня сейчас в тесте как раз такая связка + phplogcon

[s.lobanov]

Я просто уже привык к syslog-ng

[lexius]

Можно ещё посмотреть nocproject.org - ловит и сислог, и трапы, хранит всё в postgres, можно писать правила для классификации событий и многое другое.

Изменено 21 августа, 2010 пользователем lexius

[Max P]

у меня NOC стоит для снмп-трапов, а писать классификацию на кучу сислог мессаг в нем было влом :) поэтому просто поднял рядом с syslog-ng еще и rsyslog

[lexius]

Можно только на нужные написать, остальные - сразу удалять. А snmp-трапы же тоже надо классифицировать...

[antaeus]

splunk может подойдет?

[Max P]

splunk тяжеловат, да и интерфейс не особо удобен