LINUX.ORG.RU
ФорумAdmin

Самый быстрый Syslog-сервер?

 , , ,


0

3

Привет, камрады.

Есть задача логгировать запросы нагруженного DNS-сервера (Unbound) на сторонний коллектор.

Без логгирования на 4 тредах я могу выжать из него где-то 550к запросов в секунду, чего более чем достаточно. Если включить логгирование, то упираюсь в syslog-демона (100% ядра съедает).

С syslog-ng получаю 130к без regexp-матчинга и около 95к с ним (отфильтровываю только логи DNS-запросов для отправки на коллектор).

В последних версиях syslog-ng добавили мультитрединг, но оно только снижает производительность, кушая при этом 150% CPU.

Может есть какие-то более производительные syslog-сервера? Или может имеет смысл влезть в исходники Unbound и научить его писать в два syslog-сокета в round-robin и повесить на них два syslog-сервера.

Кто-то решал подобную задачу?

★★★★★

Последнее исправление: cetjs2 (всего исправлений: 1)

А если отправлять логи на удалённый сервер и там уже мутить RR?

Т.е. схема вида:

syslog на тачке с unbound шлёт логи (матчинг по facility, не по регэкспам) куда-то ещё.

В этом куда-то ещё стоит балансировщик нагрузки.

Этот балансировщик распихивает запись на 2-3 куда-то-ещё.

svr4
()
Последнее исправление: svr4 (всего исправлений: 1)

гм. А если поступить иначе - миррорить запросы на коллектор? IMHO трафик сопоставимый.

syslog-ng умеет tcp ? rsyslog умеет. Я бы посмотрел на возможность передавать логи через tcp.

Или похакал бы unbound чтоб он сразу логи на ремотный syslog пихал.

vel ★★★★★
()

550k DNS запросов в секунду - это более, чем дофига. у нас на серверах, на которых сидят десятки миллионов юзеров, в сто раз меньше нагрузка. китайские DNS флудеры все разом столько запросов не генерят. даже для контроллера большой зоны это как-то слишком.

у тебя в любом случае Unbound будет шустрее, чем syslog. посчитай из объёма логов в секунду, какой тебе нужен канал для передачи этого поноса, умножь на два, для надёжности (не забудь, что там ещё DNS пакеты болтаются в такой дикой концентрации). обеспечь достаточно шустрые сетевухи и прямой канал соответствующего класса. ещё чуть-чуть логирование можно ускорить, если писать на RAM-диск, например. но любой текстовый логгер будет жрать проц. это неизбежно. тут сама задача как-то неправильно поставлена. не нужно такой сетевой понос логировать. разве что в целях отладки, на очень кратких промежутках.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)

550к запросов в секунду

Остановись. Ты что-то делаешь не так.

Я о том, что логгить over 500k rps — это всё равно, что ничего не логгить. Утонешь (что ты в прочем уже и делаешь).

beastie ★★★★★
()
Последнее исправление: beastie (всего исправлений: 1)
Ответ на: комментарий от vel

syslog-ng умеет tcp ?

Умеет. Использую его как раз с tcp и на бездисковых клиентах, и на сервере.

viewizard ★★
()

нет, быстрее ничего не умеет. если тебе действительно надо это делать и это не праздный интерес, то следующие вопросы такие: какая гранулярность данных тебе нужна? какого вида запросы предполагаются, и как часто? когда тебе нужны ответы и насколько точные (через минуту? через день? 80% данных учтено в первые 5 минут, остальные в течении часа?)? сколько данных можно потерять? допустим ли сэмплинг? со скольки серверов будут сниматься данные? я занимаюсь в том числе проблемой логирования гиганских обьемов данных и в зависимости от ответов применяются разные подходы. в лоб ты это не решишь, для таких обьемов. будет кастомный солюшен, возможно отдельный для каждого типа логов и/или типа запросов. могу реально помочь, если оно тебе реально надо.

val-amart ★★★★★
()
Ответ на: комментарий от beastie

Ты что-то делаешь не так.

Я так понял 550К это потолок железа вообще, а не реальный текущий показатель rps
Т.е. на деле там вероятно порядка 300К в ЧНН

zolden ★★★★★
()
Ответ на: комментарий от zolden

550k x 100 байт ( обычно ) это меньше 5Гбит/с

Я так понимаю, что это похоже на ddos, чем на нормальную ситуацию.

Но тогда это не протоколировать нужно, а анализировать или агрегировать.

Изначально ТС спрашивал чем это логировать.

IMHO в виде .pcap в самый раз.

vel ★★★★★
()
Ответ на: комментарий от svr4

Регекспы снижают скорость на 20% от силы (130к против 95к), так что от такой схемы я особо не выиграю, судя по всему.

blind_oracle ★★★★★
() автор топика
Ответ на: комментарий от Iron_Bug

550к это потолок виртуалки на которой оно крутится, столько там не ожидается запросов даже в теории. В принципе, мне на какое-то время вполне хватит и потолка в 90к в текущем виде, но хотелось бы иметь какие-то варианты на случай резкого роста кроме как увеличивать количество серверов (что не факт что получится с архитектурной точки зрения).

Куда это всё будет логгироваться - это отдельная тема, там целая стойка BigData со всякими Hadoop/Kafka/Storm/Flume/итд и сотнями терабайт места, она сожрёт это дело без особых проблем, тут речь не об этом, а как туда отправлять.

blind_oracle ★★★★★
() автор топика
Ответ на: комментарий от vel

в виде .pcap в самый раз

В теории идея хорошая, но tcpdump дропнет кучу пакетов на таких скоростях.
Может уже что пооптимальнее есть?

zolden ★★★★★
()
Ответ на: комментарий от beastie

550к логгировать никто не будет, столько там не будет. Но до 200к хотелось бы, потенциально. Обработка логов за рамками задачи, она уже реализована. Они там не хранятся, а обрабатываются потоком и делается аналитика.

blind_oracle ★★★★★
() автор топика
Ответ на: комментарий от gh0stwizard

Там нет I/O, только приём из /dev/log и отправка по syslog/UDP.

blind_oracle ★★★★★
() автор топика
Ответ на: комментарий от blind_oracle

Куда это всё будет логгироваться - это отдельная тема

Т.е. ты тестировал syslog в холостую, получив цифру в 95к? Не хочу разочаровывать, с логированием на диск ты получишь цифру еще меньше.

Самый оптимальный способ это выкинуть из системы с unbound все. Отправлять напрямую на log-сервер по сети. При этом это будет только точкой сбора, далее распределить по нагрузке I/O на разные сервера/диски. В один логфайл у тебя 550к пер секонд строк не будет писаться.

Чтобы этого достичь нужен сервак с хранилищем в виде lmdb или аналогом. Вобщем, R&D-job на несколько тыщ. баксов =)

gh0stwizard ★★★★★
()
Последнее исправление: gh0stwizard (всего исправлений: 2)
Ответ на: комментарий от vel

Миррорить запросы - интересное решение, надо подумать. Проблем только три:

1) DNS, падла, бывает ещё и по TCP работает, хоть это лишь малая доля запросов. А миррорить TCP смысла нет.

2) Я не уверен что коллектор сможет их правильно парсить (это другой проект и я с ним не очень знаком пока, но можно доработать)

3) Коллекторов должно быть несколько, чтобы распределять по ним нагрузку - в syslog-ng я отправляю round-robin-ом сислог по нескольким коллекторам. Можно ли миррорить таким же образом пакеты через iptables я хз, но думаю можно каким-нибудь юзерспейс-тулзом это делать без особых потерь.

blind_oracle ★★★★★
() автор топика
Ответ на: комментарий от blind_oracle

к стойкам с бигдата обычно прилагаются выделенные оптические каналы толщиной с мою ногу. такое обычно используется в телекоме. собсна, если уж куплены сервера под бигдата, то и выделенный канал проложить не проблема.
но гипотетически таких нагрузок на DNS не бывает. опыт наблюдений показывает, что даже при атаках на сервер может привалить от силы 10-20k в секунду. но в сетях всё кэшируется и реальная нагрузка на средний DNS-сервер достаточно мала, в пределах 1K в секунду для очень хорошо нагруженного сервера.

Iron_Bug ★★★★★
()
Ответ на: комментарий от gh0stwizard

Это и будет отдельный сервер, точнее много серверов. См. выше. На самом сервере ничего кроме unbound и syslog не будет ессесно.

blind_oracle ★★★★★
() автор топика
Ответ на: комментарий от blind_oracle

На самом сервере ничего кроме unbound и syslog не будет ессесно.

Зачем syslog рядом с unbound? Последний не умеет в сокеты? Конечно, если на все-про-все хватает CPU, тогда оставляй.

gh0stwizard ★★★★★
()
Ответ на: комментарий от Iron_Bug

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

Канал - не проблема, там 10Гбит везде и всюду через толстые цыско нексус 9к. Проблема в том как быстро доставить сислог-сообщения коллектору, не упираясь в однопоточный сислог-демон, ещё раз повторю.

что даже при атаках на сервер может привалить от силы 10-20k в секунду

У меня в данный момент такие цифры - это средняя нагрузка на каждый из двух рабочих серверов. А потенциально может быть больше.

blind_oracle ★★★★★
() автор топика
Ответ на: комментарий от gh0stwizard

В какие сокеты? unbound логгирует тупо в сокет /dev/log, откуда читает syslog-ng и пересылает дальше коллектору.

blind_oracle ★★★★★
() автор топика
Ответ на: комментарий от blind_oracle

что-то у вас там не так настроено, сдаётся мне. в мире всего зарегистрировано около 500 миллионов доменов, даже меньше. прикинь, сколько запросов нужно, чтобы запросить их все. при том, что TTL отнюдь не нулевой. в общем, при правильной настройке сетей не возникает аномальной активности в потоке DNS запросов. а если вдруг возникает, то, скорее всего, это какой-то дурной роутер размножает пакеты или в сети кольцо, или Китай объявил вам войну.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

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

blind_oracle ★★★★★
() автор топика
Ответ на: комментарий от gh0stwizard

Ну, патчить unbound на отправку syslog на коллекторы самостоятельно - это тоже вариант, но мне не хотелось бы к нему прибегать если есть варианты попроще, собсно об этом и тред - о стандартных решениях.

Кастомных я могу напридумать целую кучу, но это уже затраты времени и денег, возможно лишние.

blind_oracle ★★★★★
() автор топика
Ответ на: комментарий от blind_oracle

Была у меня как-то задача логировать access_log хайлод вебсервера. Перебрал все известные логгеры и остановился на rsyslog. В итоге логи валились в буфер, после наполнения которого сжимались и пачками отправлялись на другой rsyslog в локалке где парсились и клались в базу. Решением был доволен.

iron ★★★★★
()
Ответ на: комментарий от iron

Тут хайлоад, скорее всего, по запросам в секунду в несколько раз повыше будет чем вебсервер... Буффер имеется в виду локальный на диске? Или в памяти? И еще компрессия...вряд-ли это взлетит если я сейчас упираюсь просто в отправку.

blind_oracle ★★★★★
() автор топика
Ответ на: комментарий от blind_oracle

И еще компрессия...вряд-ли это взлетит если я сейчас упираюсь просто в отправку.

По идеи тот-же lzo жрать много не должен, и возможно что хорошо сожмет данные для пересылки.

V1KT0P ★★
()
Ответ на: комментарий от blind_oracle

Буффер имеется в виду локальный на диске? Или в памяти?

В памяти. У меня упора в отправку не было, так как отправлялось в сжатом виде и с небольшой задержкой.

iron ★★★★★
()

Как уже верно сказали

но в сетях всё кэшируется и реальная нагрузка на средний DNS-сервер достаточно мала, в пределах 1K в секунду для очень хорошо нагруженного сервера.

Здесь вопрос только в балансировке. Те кто сходу говорит что 500к в секунду это DDOS/нереально/etc просто не сталкивались м.б с такими нагрузками, но не более того. Тот же Google, при запуске Google Public DNS, ЕМНИП, еще в 2011 анонсировал цифры в 60-70 млрд. запросов в сутки. (что при делении на 86400 и даст вам 700-800к/sec). Конечно мы знаем цену анонсов в этом плане, мы можем смело поделить этот «галдеж» на 2, и все равно получим ~350-400к.

Дело не в том сколько вы обрабатывает запросов, дело в том, как вы их распределяете.

Теперь по теме:

Да, с syslog-ng вы можете получить вполне неплохой результат, и не нужно будет лезть ни в чьи кишки, но здесь вопрос все же не в этом. Думается мне, что вы собираетесь логировать не то, что нужно. Я, конечно же, ни в коей мере не хочу сказать что вы не ведаете что делаете, но здесь хотелось бы отталкиваться от реальных данных. Вы можете показать один complete-пакет, который потенциально должен быть в лог-хранилище? Вы собираетесь логировать все что попало?

Есть задача логгировать запросы нагруженного DNS-сервера

Если вам грузят ddos с 10к-ного ботнета общей сложностью в ~150-200к/sec, вы, перед тем как отпинывать такие запросы, тоже хотите их логировать?=) Вообщем-то хотелось бы узнать вес/содержимое одного complete-пакета, м.б. все-таки вы собираетесь отсылать ненужные данные. Можно конечно логировать каждый чих, но нужно понимать - для чего такой лог нужен, и какой профит я получу от него впоследствии.

Тут можно как в том анекдоте:

Прикупить специально для этого дела рам. Потом на эти рамы, от конкретного вирт. адреса «кучковать» данные, при достижении же определенного порога, отдавать попутными запросами по отдельному каналу туда, где у вас стоит уже «решенная задача обработки логов» :) Смешно, но что делать, если нужно логировать такие кучи?=)

znenyegvkby
()
Ответ на: комментарий от anonymous

Логстеш дохнет на более-менее приличной нагрузке.

ipeacocks ★★★★★
()
Ответ на: комментарий от znenyegvkby

Вы можете показать один complete-пакет, который потенциально должен быть в лог-хранилище?

Я не знаю алгоритмов, какими стек бигдатовских систем будет анализировать эти данные и их хранить, этим другие люди занимаются. Моё дело - отправить эти данные на Flume коллекторы (пока что) и всё. При перегрузке коллекторов их добавят ещё и мне нужно будет по ним распределить нагрузку.

Пакет там простой - клиент с IP таким-то запросил A запись хоста domain.com, всё.

Если вам грузят ddos с 10к-ного ботнета общей сложностью в ~150-200к/sec, вы, перед тем как отпинывать такие запросы, тоже хотите их логировать?=)

Доступ к этим резолверам есть из достаточно ограниченной сети (по сути - большой интранет), поэтому ботнетов и ддосов в привычном понимании там нет.

blind_oracle ★★★★★
() автор топика
Ответ на: комментарий от ipeacocks

Я не могу слать логи со скоростью выше 130к запросов в секунду, в этом и задача. Упирается в локальный сислог.

blind_oracle ★★★★★
() автор топика

В общем пока увидел систему dnstap, буду курить её подробнее.

blind_oracle ★★★★★
() автор топика
Ответ на: комментарий от blind_oracle

Я не знаю алгоритмов, какими стек бигдатовских систем будет анализировать эти данные и их хранить

Пакет там простой - клиент с IP таким-то запросил A запись хоста domain.com, всё.

Да, я подразумевал под «complete-пакет» именно вашу начальную запись, которую вы отдаете.

Доступ к этим резолверам есть из достаточно ограниченной сети (по сути - большой интранет), поэтому ботнетов и ддосов в привычном понимании там нет.

Если нет, то тогда, даже если у вас не теоретически, а практически будет ~300-500к запросов, вы вполне себе, при учете правильного распределения можете их обрабатывать. И даже вполне себе логировать (если уж вам это так нужно), но только при учете, что вы избавитесь от вот этого вашего условия:

но хотелось бы иметь какие-то варианты на случай резкого роста кроме как увеличивать количество серверов (что не факт что получится с архитектурной точки зрения).

Ибо, сам по себе DNS-м-сервер должен рассматриваться в плане горизонтальной масштабируемости (не берем вертикалку, ибо там огромные DB/DB транзакций/хранилища/etc), вы не должны замарачиваться за предыдущие запросы. Если дело в архитектуре - тут только следует выкидывать архитектуру на помойку. Что за архитектура DNS-системы, которая вместо траты N$ на доп. кластеры, заставляет меня париться над обходом реализации? Ведь судя по кол-ву ваших запросов, у вас не самая мелкая контора. Все должно быть агрегированно (в контексте логов), если вы сетуете на

Я не могу слать логи со скоростью выше 130к запросов в секунду, в этом и задача. Упирается в локальный сислог.

Агрегируйте в отдельные рамы и устанавливайте порог. После достижения порога - параллельно отсылайте запросы, я ведь не думаю что вам потребуется тут же отдавать данные этих логов, через несколько секунд после запроса пользователем (я сейчас не о самом ответе на dns-запрос, а о логах). Тогда у вас и не будет проблемы с N/sec запросов. Для логов - это вообще не должно быть проблемой=) Это же логи=)

znenyegvkby
()
Ответ на: комментарий от ipeacocks

Это и есть UDP, у TCP больше накладных расходов поэтому я его не рассматриваю особо...

blind_oracle ★★★★★
() автор топика
Ответ на: комментарий от zolden

Не, не совсем, но рядом :) Это рекламная аналитика, таргетинг покупателей, всё такое. Запросы DNS там только один из источников данных.

blind_oracle ★★★★★
() автор топика
Ответ на: комментарий от znenyegvkby

Ибо, сам по себе DNS-м-сервер должен рассматриваться в плане горизонтальной масштабируемости (не берем вертикалку, ибо там огромные DB/DB транзакций/хранилища/etc), вы не должны замарачиваться за предыдущие запросы. Если дело в архитектуре - тут только следует выкидывать архитектуру на помойку. Что за архитектура DNS-системы, которая вместо траты N$ на доп. кластеры, заставляет меня париться над обходом реализации? Ведь судя по кол-ву ваших запросов, у вас не самая мелкая контора. Все должно быть агрегированно (в контексте логов), если вы сетуете на

Это всё хорошо, да, но только в теории. Архитектуру, бывает, изначально проектируют не самые компетентные спецЫялисты, так что иногда приходится работать в той экосистеме, которая есть, ибо снести и заново построить равносильно невозможному либо очень дорого.

Агрегируйте в отдельные рамы и устанавливайте порог. После достижения порога - параллельно отсылайте запросы, я ведь не думаю что вам потребуется тут же отдавать данные этих логов, через несколько секунд после запроса пользователем (я сейчас не о самом ответе на dns-запрос, а о логах). Тогда у вас и не будет проблемы с N/sec запросов. Для логов - это вообще не должно быть проблемой=) Это же логи=)

Это опять теория. Есть конкретная задача, с конкретным ПО, мне интересно как её решить. В вашем варианте я упрусь не в отправку по сети а в складывание в кеш, и не факт что скорость при этом будет выше...

blind_oracle ★★★★★
() автор топика
Ответ на: комментарий от blind_oracle

Это всё хорошо, да, но только в теории. Архитектуру, бывает, изначально проектируют не самые компетентные спецЫялисты, так что иногда приходится работать в той экосистеме, которая есть, ибо снести и заново построить равносильно невозможному либо очень дорого.

Ну тогда уж извиняйте=) Здесь я ничем не смогу вам помочь

Это опять теория. Есть конкретная задача, с конкретным ПО, мне интересно как её решить. В вашем варианте я упрусь не в отправку по сети а в складывание в кеш, и не факт что скорость при этом будет выше...

Ну давайте отталкиваться от того, что ни «конкретной задачи» (адекватного ТЗ) ни «конкретного ПО» (Unbound+s-ng, ок, но вы хоть покажите тесты реальных нагрузок нам, и хар-ки машин и каналов) мы не увидели.

А что вы предлагаете? Вы задали вопрос, и что кто лучшее вам сможет здесь предложить? Я вам даю гарантию, что нигде вам никто лучшее не предложит, хоть вы весь мир обойдите=) (исключая спец. коммерц. ПО, но вам его точно не посоветуют) Если вы не можете горизонтально масштабироваться, то вы все равно не побьете планку выше той что есть у вас в доступных ресурсах, и пусть вам хоть Торвальдс напишет свой rsyslog/syslog-ng (а по сути, лучше их вы вряд-ли найдете, если без коммерции, а многие коммерц и им проиграют) вы все равно не получите профита, которого хотите. Ну вы сами себя упираете в ресурсы, никакое ПО вам не поможет. Это, конечно же, мое ИМХО. Ищите тогда прогеров, что выжмут их ваших ресурсов последние копейки. Тут вам уже ни rsyslog ни syslog-ng не помогут.

znenyegvkby
()
Ответ на: комментарий от znenyegvkby

А что вы предлагаете? Вы задали вопрос, и что кто лучшее вам сможет здесь предложить? Я вам даю гарантию, что нигде вам никто лучшее не предложит, хоть вы весь мир обойдите

Ну, как видно, решение всё же есть - dnstap. Этот протокол поддерживается в unbound и логгирует в локальный сокет используя Google Protocol Buffers и File Streams, есть уже готовый сервер (правда, на Go) который умеет слушать и парсить эти потоки. Это не готовое решение, придётся писать самому конвертер из dnstap в syslog/udp, но уже что-то.

По скорости падение всего на 10% относительно режима без логгирования вообще, а не в 5-6 раз как с syslog.

blind_oracle ★★★★★
() автор топика
Последнее исправление: blind_oracle (всего исправлений: 1)
Ответ на: комментарий от blind_oracle

По скорости падение всего на 10% относительно режима без логгирования вообще, а не в 5-6 раз как с syslog.

Это вы уже реальные результаты с нагрузок снимали, или это какие-то стресс-тесты?

За инфу спасибо, сейчас гляну его. Судя по поверхностному описанию, он под вашу задачу специализирован прям-таки.

dnstap is a flexible, structured binary log format for DNS software

Раньше никогда не сталкивался.

znenyegvkby
()
Ответ на: комментарий от znenyegvkby

Вот тут есть ближе к концу графики: http://dnstap.info/slides/dnstap_nanog60.pdf

Раньше никогда не сталкивался.

Я слышал, но как-то не до конца осознал видать зачем оно. Тут задача появилась - вкурил :)

blind_oracle ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.