Веб скейл.

заменил в рабстве logstash на rsyslog @ выключил два сервера // тру стори

@plhk осло http://www.rsyslog.com/doc/master/configuration/modules/omelasticsearch.html

@plhk Довольно очевидно. Но сколько логов у вас там высирается, что вам два сервера на их разбор нужно? Или вы очередные эти, которые парсят access.log?

@komar много, access.log втч

@plhk Блядь. Шо у вас за задачи вообще? Давайте я вам соображу что попрямее, еще пару серверов выкините.

@komar Я просто все равно собирался.

@komar шаред хостинг собираем логи апача экзима всфтпд мускуля внутренних сервисов ~100Mb/s

@plhk Так вы их храните или парсите?

@komar централизованно парсим только хостнейм и identity потом храним но даже на этой тупой задаче логстеш жидко обсирался (32 ядра в полку, ~20 гб рам)

@plhk Ясно, тогда хуй с ним. Это не то.

rsyslog не умеет в многострочные сообщения в отличие от syslog-ng. либо же я лох и не нашёл в манах

>journald Ортогонален рсислогу, т.к. применим, фактически, только локально. В лучшем случае, чтобы переслать логи с одного локалхоста на другой. Позволяет поиметь на, например, своем десктопе/ноутбуке индексируемую БД с логами, не заморачиваясь с связкой рсислогом + мускуль/постгре. >хуястиксерч Это тупо БД для жсон-говн с их индексацией. Профит по сравнению с РСУБД в том, что, если у тебя логи в один сервер не влезают, то можно легко понатыкать рядом еще 10, что в случае с РСУБД грозит геморроем (также учти, что индексы могут занимать не меньше, что сами данные, если ты хочешь иметь возможность быстро искать по любым полям, а ты это определенно захочешь, т.е. полезная емкость одного сервера уменьшается в два раза). Притом, что большинство фич даже какого-нибудь мускуля нафиг не упали для задачи "получить жсон, положить на диск, проидексировать все поля и выдавать по тупым запросам вида select * from logs-2017-02-31 where foo = 'bar'"

@etw > Позволяет поиметь на, например, своем десктопе/ноутбуке индексируемую БД с логами, не заморачиваясь с связкой рсислогом + мускуль/постгре. Возможно, вы имели в виду: корраптящуюся

@etw > Это тупо БД для жсон-говн с их индексацией. Профит по сравнению с РСУБД в том, что, если у тебя логи в один сервер не влезают, то можно легко понатыкать рядом еще 10, что в случае с РСУБД грозит геморроем (также учти, что индексы могут занимать не меньше, что сами данные, если ты хочешь иметь возможность быстро искать по любым полям, а ты это определенно захочешь, т.е. полезная емкость одного сервера уменьшается в два раза) Больной, да у вас NoSQL.

@komar Если у тебя диск коррпатится так, что превращает чтение базы journald в нереальную задачу, то тебе обычно уже не до логов (а если бы они были для тебя важны, ты бы позаботился). Алсо, формат документирован и не выглядит сложным для восстановления на тот случай, если логи тебе важны, но ты пофакапил их сохраннось.

@etw Лёня, перелогинься.

@komar Я на тебя бы посмотрела, как бы ты админил кластер из десятка серверов с РСУБД, да еще и в нескольких датацентрах. Тем более, что для тупой хранилки логов РСУБД не требуется.

@etw О, я бы брал две ставки!

@komar Если у меня покорраптится диск на локалхосте - волноваться о том, как бы достать логи я буду в последнюю очередь. Возможно, в твоем случае это не так, но подозреваю, что это редкий кейс, для которого можно сохранять все в текстовом виде через любой сислог-демон, не кладя ничего в базу journald. Получается примерно такая же ситуация, как с systemd юнитами vs скриптов на баше: первые покрывают 99% случаев, при этом остается возможность использовать вторые для оставшегося 1%.

@etw У тебя мозги там не покорраптились? Какой диск, че ты несешь?

@komar Проще воткнуть elasticsearch, не иметь головной боли с кластером из РСУБД там, где оно не требуется.

@etw Да, и потом, РСУБД — это не вебскейл.

@komar А какую ситуацию ты тогда имеешь в виду под "покорраптится", которая была бы настолько ужасной, что бы могла сильно ударить по append-only db?

@etw Я не знаю, че там поттеринг придумал, что у него append-only db корраптится.

@komar Руководствоваться принципами "фу, это носкуль" при выборе хранилища под задачу примерно так же глупо, как руководствоваться принципами "это модно и вебскейл". Если разные классы задач, для каждого из которых лучше подходят разные виды хранилищ. "Нужно хранить кучи логов для оперативной работы с ними (выборки по достаточно тупым запросам за относительно небольшой промежуток времени)" явно не относится к тем, для которых требуется РСУБД, особенно за ту цену, которую для этого потребуется заплатить.

@etw Действительно, две ставки за эту хуйню платить.

@komar Я, вроде, не говорила, что это какая-то волшебная бд, которая в принципе не может покорраптиться. Намекну еще прозрачнее: в каких ситуациях у тебя коррпатится база journald так, что она становится нечитаемой и почему ты считаешь, что в данном случае тебе обязательно нужны логи и ты при этом используешь правильную систему под свои задачи? Мне видится 2 ситуации, в которых эта бд может покорраптиться: сбой на диске, когда сбойные секторы приходятся на важные для этой бд структуры (в данном случае в тех ситуациях, когда это БД используется, до логов тебе меньше всего дела), либо, допустим, из-за выключения питания данные не до конца записались и база осталась в неконсистентном состоянии, что для append only БД совершенно некритично, особенно, в типичных для journald случаях применения.

@komar Про какие ставки ты несешь?

@etw Блядь, у тебя конкурс сочинений в школе, или в инторнете кто-то неправ? Нахуя ты мне эти простыни рисуешь?

@komar Мне хочется понять, обоснована ли чем-то твоя критика (возможно, мне что-то неизвестно, но что было бы неплохо узнать).

@etw Нет. я просто так кукарекаю. потому что у меня бутхерт от успешности лёнчика. Съеби уже, пожалуйста.

@komar > Съеби уже, пожалуйста. нет, ты.

@etw Но ведь это мой тред.

@komar Но ты же зачем-то опубликовал свой баттхерт на ресурсе, где принято комментировать посты?

@etw Извини, не подумал. В следующий раз припишу «etw иди нахуй заранее спасибо».

@komar Да, disclaimer бы в таких случаях не помешал.