вообще? Приклад по tcp сразу в него логи кидает?
Да, логи идут в редисы от сервисов, оттуда логстеш собирает
Ну кидайте сразу в логстеш, зачем вам эта прослойка? Логстеш же умеет в PQ
Поднимаете для каждого приклада отдельный пайп сл своей отдельной очередью и со своим отдельным оутпутом в свой датастрим елк. Приклад учите писать раунробином в пару логсташей, радуетесь. У себя при такой схеме вижу стабильный поток по одному конвееру в 600к/мин на обоих логсташах, т.е. в сумме 1200. Перестанет тянуть - поставлю третий и не буду дуть стек там где это не требуется
Думали насчет писать напрямую в логсташ, но в таком случае все сервисы начинают знать про него, считаю не очень хорошо так делать + все сервисы расположены в разных сетях и разных дц, а логстеш в отдельном и проще организовать туннели от него к сервисам, чем от сервисов к логсташу Но может когда-то все же к этому придем
Ну будут знать они про логсташи или про кафку с редисом вообще без разницы. Кидайте по 1-2 логсташей в каждом дц, в зависимости от количества денег и необходимой HA.
Хм, интересный вариант с меньшим количеством промежуточных точек. Предложу на рассмотрение, звучит хорошо. Получается приклады пишут прямо в логстеши, а логстеши уже в эластик передают
Да. Мысль вы поняли верно. Вообще можно напрямую в елк писать, но я этот вариант для себя отмел т.к. в случае какой то жопы хочу быстро устранить влияние, например отправкой в даун одного из логсташей/пайплайнов/пользователей. Ну и не пишу конвееры/парсеры под несколько разных прикладов в одном, чтобы как раз минимизировать модификацию в LS. Удалять поля порой дороже чем хранить кстати. Если это рил лишние поля, дайте CR разрабам чтобы они их выпилили на уровне приклада.
Там удаление мета полей типа [agent] [host] [ecs] + у меня однострочный руби фильтр, который берет несколько полей из каждого лога и делает из них уникальную md5 строку и добавляет ее в отдельное поле (это мой личный костыль для сервиса уведомлений, чтобы потом лог можно было найти)
Вроде есть похожий фильтр в ls который хэш вычисляет из поля. Посмотрите на него, может он быстрее.
ruby { code => ' require "digest/md5"; event.set("computed_id", Digest::MD5.hexdigest(Time.now.to_s() + event.get("[log][@timestamp]").to_s() + rand(100).to_s()))' } мой выглядит так) сейчас перечитал и даже призадумался над тем, насколько это может быть медленнее чего-то встроенного)
А куда вы потом этот хеш засовываете кроме эластика? Это просто из любопытства
У меня есть самописный алертер на го, в который логсташ кидает ерроры и фаталы, а тот в свою очередь в месенджеры пишет. Вот там этот хеш и использую, чтоб потом быстро найти лог
Скажите, инженеры вас недолюблювают или вы их?)
А пишете вы на каждое сообщение хеш или только на эрооры/фаталы? :)
Если прикдад начинает срать ерроами, сколько алертов отправляется ?)
Сейчас на все, но теперь задумался, что можно только на ерроры и фаталы, так как в остальных он не нужен
Как хорошо что Вы догадались о моих мыслях :)
Ин мемори кеш использую, проверяю месседж лога, если такой в кеше есть, то на час кеширую. Каждые 100 вхождений в кеш тоже уведомляю
md5 - очень дорогая функция. Это криптоустойчивый хэш и поэтому медленный.
хм, спасибо, пересмотрю решение
Ммм, а что значительно быстрее?
murmur например. 64битный вполне себе коллизиоустойчивый. для обычного хэширования (с целью дедупликации) вполне себе подходит
fingerprint filter и в нем concatenate_sources
Обсуждают сегодня