[vlad11]

Дано:

коммутаторов доступа L2 - около 500

коммутаторов района L2-L3 - около 20

коммутаторов ядра L3 - 5

серверов - десятка два.

 

Нужно централизовано принимать от всех логи и часть отдавать в NOC.Project

 

Две виртуалки с carp IP из менеджмент влана.

Смотрю в сторону syslog-ng

 

Дополнительные вопросы:

1) На коммутаторах не удасться указать два узла назначения логов?

2) Можно ли заставить коммутаторы слать логи по tcp?

3) Как ретранслировать логи с центрального сервера логов на другой сервер, на котором крутится NOC.Project?

4) Почему вы считаете, что логи надо слать только по udp? Лично я предпочитаю их получать гарантированно по tcp. А лучше вообще закриптованными в туннеле :)

5) Насколько стабильно работает syslog-ng при 100-1000 r/s ? Не надо ли его перегружать?

Изменено 23 июня, 2013 пользователем vlad11

[Abram]

1) Вместо CARP взять LVS.

2) Нет и не надо.

3) http://www.google.ru/search?hl=ru&q=syslog-ng+relay&btnG=%D0%9F%D0%BE%D0%B8%D1%81%D0%BA+%D0%B2+Google&lr=

[Abram]

Вдогонку:

1) Либо два VRRP-инстанса, на коммутаторах вписывать по очереди.

[zi_rus]

3) http://kb.nocproject.org/pages/viewpage.action?pageId=7766145

[vlad11]

3) http://kb.nocproject.org/pages/viewpage.action?pageId=7766145

 

Это только прием в NOC.Project.

А мне еще надо соорудить ретрансляцию логов с центрального хранилища

 

1) Вместо CARP взять LVS.

 

В схеме Linux director будет единой точкой отказа

 

Вдогонку:

1) Либо два VRRP-инстанса, на коммутаторах вписывать по очереди.

Уже интереснее.

Сервера логов будут в виртуалках.

Посмотрим, как на линуксе реализовано vrrp.

[Abram]

В схеме Linux director будет единой точкой отказа

Нет, если два директора.

Но тогда это опять VRRP получается, только через жопу. (:

Посмотрим, как на линуксе реализовано vrrp.

Реализовано в keepalived, есть во всех дистрибутивах страны (с).

 

Пример:

раз:

! Configuration File for keepalived

global_defs {
  router_id lisg1
}

vrrp_instance VI_1 {
   state MASTER
   interface bond0
   virtual_router_id 101
   priority 100
   advert_int 1
   virtual_ipaddress {
       10.0.0.101/24
   }
   notify "/usr/local/bin/rebindPDNS"
}

vrrp_instance VI_2 {
   state BACKUP
   interface bond0
   virtual_router_id 102
   priority 50
   advert_int 1
   virtual_ipaddress {
       10.0.0.102/24
   }
   notify "/usr/local/bin/rebindPDNS"
}

 

два:

! Configuration File for keepalived

global_defs {
  router_id lisg2
}

vrrp_instance VI_1 {
   state BACKUP
   interface bond0
   virtual_router_id 101
   priority 50
   advert_int 1
   virtual_ipaddress {
       10.0.0.101/24
   }
   notify "/usr/local/bin/rebindPDNS"
}

vrrp_instance VI_2 {
   state MASTER
   interface bond0
   virtual_router_id 102
   priority 100
   advert_int 1
   virtual_ipaddress {
       10.0.0.102/24
   }
   notify "/usr/local/bin/rebindPDNS"
}

 

Это моё, там лишнее есть, но суть понятна. VRRP-адреса - 10.0.0.101 и 10.0.0.102, реальные адреса используются только для менеджмента и связи нода-нода.

Плюс в качестве health checker-а можно прикрутить проверку syslog-ng.

[vlad11]

Конфиг CARP в FreeBSD еще короче. :)

Изменено 22 июня, 2013 пользователем vlad11

[sexst]

4) Почему вы считаете, что логи надо слать только по udp? Лично я предпочитаю их получать гарантированно по tcp. А лучше вообще закриптованными в туннеле :)

5) Насколько стабильно работает syslog-ng при 100-1000 r/s ? Не надо ли его перегружать?

4) а) Да в общем-то потому что по-нормальному текстовые логи используются только для "посмотреть что это было" или "а кто это там накосячил". При этом подавляющее число таких ситуаций приводит к тому что логи вообще никак не придут - ни по tcp ни по udp.

б) TCP это целая куча ресурсов и геморроя по сравнению с легким udp.

в) Если у вас в опорной сети настолько сурово теряются udp датаграммы что это вас уже парит, то у меня для вас плохие новости.

г) Если у вас размазанная по миру сеть, то нужно логи слать внутри шифрованного туннеля с гарантией доставки. В таком случае использование tcp - см. пункт б.

5) ~50 000, полет нормальный. Пока не упираетесь в диск и проц, проблем не будет.

[Am1G0]

1) На коммутаторах не удастся указать два узла назначения логов?

зачем?

 

2) Можно ли заставить коммутаторы слать логи по tcp?

это стоит искать в доках самих коммутаторов

 

3) Как ретранслировать логи с центрального сервера логов на другой сервер, на котором крутится NOC.Project?

уже отвечено было ранее - релеить их

 

4) Почему вы считаете, что логи надо слать только по udp? Лично я предпочитаю их получать гарантированно по tcp. А лучше вообще закриптованными в туннеле :)

tcp - это негарантированно, sctp - гарантированно, но известные мне syslog-сервера не умеют его, хотя можно использовать sctp proxy, но это всё-равно фуфло, поддержка должна быть на уровне приложения.

 

5) Насколько стабильно работает syslog-ng при 100-1000 r/s ? Не надо ли его перегружать?

по моим тестам стабильно до 100krps, больше не тестил. в качестве бд сразу рекомендую использовать mongo, дабы не трахаться потом с приколами разных rdbms. бд стоит ставить отдельно и обеспечивать её отказоустойчивость внутренними средствами.

[vlad11]

Опа!

А я думал складировать в директории вида /log/hostname/service/~date~.log логи с ротацией по-суточно.

[Abram]

4) tcp слишком сложен для тупых железяк. А вот udp отправить - как два пальца об асфальт.

5) +1 к mongodb. Только читалку придется делать.

[vlad11]

5) +1 к mongodb. Только читалку придется делать.

 

Т.е. читалки базы mongodb вообще нет?

 

Вижу mojology.

Изменено 23 июня, 2013 пользователем vlad11

[Am1G0]

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

вопрос скорее стоит в том, насколько продвинутую хотите читалку, так как у меня дошло до того, что помимо вебуя со свистоперделками и аналитикой понадобились ещё и консольные инструменты, заменяющие собой tail, grep, head и прочую лабуду.

 

есть, кстати, ещё один интересный вариант: rsyslog + elasticsearch, но это если требуется настоящий и довольно быстрый полнотекстовый поиск. в монго настоящего полнотекстового поиска нет.

[Abram]

5) +1 к mongodb. Только читалку придется делать.

 

Т.е. читалки базы mongodb вообще нет?

 

Вижу mojology.

Нет, монга - это уже из той глубины Интернета, где нужно ручками. :)

[catalist]

А вот udp отправить - как два пальца об асфальт.

надо говорить: как два байта переслать :)

[snark]

надо говорить: как два байта переслать :)

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

Да, вредный - ты и сам это знаешь :)

[terrible]

Протите за вопрос не в тему, но почему-то сильно заинтересовал:

коммутаторов доступа L2 - около 500

серверов - десятка два.

Я примерно представляю абонентскую базу на 500 комутаторов. Вопрос: для чего нужно такое большое количество серверов?

По моим прикидкам должно хватить 7 максимум.

 

У самого 400 комутаторов, сислог-нг справляется на ура на одной машине. На горячую не резервирую. Храню в мускуле. Очень доволен.

[Am1G0]

Протите за вопрос не в тему, но почему-то сильно заинтересовал:

коммутаторов доступа L2 - около 500

серверов - десятка два.

Я примерно представляю абонентскую базу на 500 комутаторов. Вопрос: для чего нужно такое большое количество серверов?

По моим прикидкам должно хватить 7 максимум.

 

У самого 400 комутаторов, сислог-нг справляется на ура на одной машине. На горячую не резервирую. Храню в мускуле. Очень доволен.

например, под кеш. хотя под это, конечно, логичнее было бы собрать 1 хранилку.

[sirmax]

http://graylog2.org/ - еще один вариант если зхочется полнотекстового поиска

[Am1G0]

http://graylog2.org/ - еще один вариант если зхочется полнотекстового поиска

глючная и медленная какаха. по крайней мере именно такой и была, когда тестил. выше 15к событий в секунду на 4 ядрах ксеона e74870 никак не смогла прожевать, хотя как БД и использует офигенный es, который с rsyslog и с полтинником без дропов свободно справлялся.

[sirmax]

http://graylog2.org/ - еще один вариант если зхочется полнотекстового поиска

глючная и медленная какаха. по крайней мере именно такой и была, когда тестил. выше 15к событий в секунду на 4 ядрах ксеона e74870 никак не смогла прожевать, хотя как БД и использует офигенный es, который с rsyslog и с полтинником без дропов свободно справлялся.

ну я уточню какая нагрузка сейчас на проекте и отпишу. Мы тестили, но уж полгода как, не помню что получилось, да и то я краем коснулся. Но вроде работало все нормально, по крайне мере девелоперы были довольны

[sirmax]

http://graylog2.org/ - еще один вариант если зхочется полнотекстового поиска

глючная и медленная какаха. по крайней мере именно такой и была, когда тестил. выше 15к событий в секунду на 4 ядрах ксеона e74870 никак не смогла прожевать, хотя как БД и использует офигенный es, который с rsyslog и с полтинником без дропов свободно справлялся.

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

[_INF_]

Коммутаторов >4k

 

Tcpdump-ом видно, что в секунду идет не более 10 udp пакетов по протоколу syslog (цифру в 1000 rps по syslog сложно представить, вероятнее всего не стоит логировать все подряд)

 

В качестве syslog сервера используется syslog-ng с простейшим конфигом

 

Вот кусок

 

source s_remote {

tcp(ip(0.0.0.0) port(514));

udp(ip(0.0.0.0) port(514));

};

 

destination d_all { file("/logs-servers/all/$YEAR/$MONTH/$DAY/messages" owner("root") group("root") perm(0644) dir_perm(0755) create_dirs(yes)); };

 

filter net_192 {netmask(192.168.0.0/16);};

 

destination d_net_192 {

file("/logs-servers/net_192/$HOST/$YEAR/$MONTH/$DAY/messages" owner("root") group("root") perm(0644) dir_perm(0755) create_dirs(yes) );

};

 

log {source(s_remote); destination(d_all); };

log {source(s_remote); filter(net_192); destination (d_net_192); flags(final);};

 

 

Соответственно логи пишутся в 2 места

 

1 Общий лог валится в /logs-servers/all/$YEAR/$MONTH/$DAY/messages который очень удобно разгребать (в том числе и автоматически скриптами) ибо там хранятся все события на сети и в случае ахтенга можно тупо в него заглянуть и посмотреть кто на что ругается.

 

2 Лог по хостам /logs-servers/net_192/$HOST/$YEAR/$MONTH/$DAY/messages в котором можно проследить хронологию событий по отдельному хосту

 

Нагрузки на syslog сервер нет вообще (трудно ожидать нагрузки на сервер с 10 rps :) ).

[vitalyb]

Логи tcp nat-трансляций с двух серваков, вчера вечером было - 9761 записей в секунду (если усреднить 1 час), фильтров нет, загрузка одного ядра X3330 под 20%. syslog-ng, транспорт для логов tcp, пишет в текстовые файлы.