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

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

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

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

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

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

Можно ли писать файловые логи, а их уже отправлять куда надо?

те. использовать logstash, fluentd, etc.

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

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

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

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

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

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

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

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

syslog-ng умеет tcp ?

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

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

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

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

оно только снижает производительность, кушая при этом 150% CPU

Что с I/O?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ты дал половину ответа. Писать логи по сети на другой сервер syslog-ng умеет не только сам syslog ^_-

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Логи шли на балансировщик - а за ним уже группа сислогов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

это и по UDP тоже?

там целая стойка BigData

Прозреваю оракал работает на Большого Брата, а данные идут из СОРМа

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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