Comments 53
Хм, интересно, а почему именно C? Неужели не хватало производительности настолько?
В основном это потребление памяти, нежели производительность. Но в целом производительность тоже важна.
Почему у нас больше всего демонов на Си?
Вопрос многогранный.
Во-первых, потому что мы хорошо знаем и любим Си.
Во-вторых, Badoo существует давно и 10 лет назад было такого большого выбора вкусных языков, как Go или Rust.
В третьих, у нас действительно очень высокая нагрузка. Мы, к примеру, в некоторых демонах используем JIT компиляцию для конвертации поискового запроса по битовому массиву в sse/avx/avx2 машинный код.
Сейчас же, если нам не требуется супер высокой производительности, мы предпочитаем Go.
Вопрос многогранный.
Во-первых, потому что мы хорошо знаем и любим Си.
Во-вторых, Badoo существует давно и 10 лет назад было такого большого выбора вкусных языков, как Go или Rust.
В третьих, у нас действительно очень высокая нагрузка. Мы, к примеру, в некоторых демонах используем JIT компиляцию для конвертации поискового запроса по битовому массиву в sse/avx/avx2 машинный код.
Сейчас же, если нам не требуется супер высокой производительности, мы предпочитаем Go.
О, ну поскольку тема Go на хабре очень популярна, то позволю себе спросить — насколько просадка по сравнению с С?
У меня нет для вас готовых цифр и красивых графиков до\после, к сожалению.
Мы используем Go очень давно. На ранних этапах мы постоянно боролись с GC. Даже делали доклад на тему оптимизации Go на meetup, который проходил в нашем офисе. Но с каждой новой версией Go становится лучше и более приспособленным для высоких нагрузок и сервисов, которые используют много памяти.
Если говорить про Си VS Go в плане производительности, то Go, конечно, проигрывает. Но Go на порядки удобнее для программирования. Делать многопоточную систему на Go — удовольствие, а на Си — морока. Если посмотреть чуть шире, то за счет этого удобства вы сможете написать распределенную систему на Go, которая будет работать лучше, чем система на Си. Не за счет банальной скорости, а за счет того что к моменту как система на Go уже будет вовсю работать и работать отлично, на Си вы будете искать ошибки в многопоточном коде.
Мы используем Go очень давно. На ранних этапах мы постоянно боролись с GC. Даже делали доклад на тему оптимизации Go на meetup, который проходил в нашем офисе. Но с каждой новой версией Go становится лучше и более приспособленным для высоких нагрузок и сервисов, которые используют много памяти.
Если говорить про Си VS Go в плане производительности, то Go, конечно, проигрывает. Но Go на порядки удобнее для программирования. Делать многопоточную систему на Go — удовольствие, а на Си — морока. Если посмотреть чуть шире, то за счет этого удобства вы сможете написать распределенную систему на Go, которая будет работать лучше, чем система на Си. Не за счет банальной скорости, а за счет того что к моменту как система на Go уже будет вовсю работать и работать отлично, на Си вы будете искать ошибки в многопоточном коде.
У нас в целом машины с демонами в процессор обычно не упираются. Но даже для случаев, когда CPU очень важен, никто не мешает использовать готовые библиотеки на Си, которые хорошо оптимизированы. Марко об этом не сказал, но вообще говоря у нас есть несколько демонов на го, которые именно так и делают. Например, используют RocksDB для хранения данных на диске, и при этом внутренние гошные структуры в качестве индекса и имеют много воркеров, которые с этими структурами как-то по-хитрому работают.
Тоже используем ELK, правда доставляет всё logCourier, т.к. сервера в основном виндовые. А вы на riemann для алертинга не смотрели? Если не учитывать clojure и отсутствие кластерности, довольно мощная штука
Мы используем Paasta для деплоя и мониторинга живости сервисов. Возможно на первый взгляд может показаться, что это слишком сложно и мутно, да оно сложно, но довольно сильно унифицирует все сервисы и принципы работы с ними.
http://engineeringblog.yelp.com/2015/11/introducing-paasta-an-open-platform-as-a-service.html
http://engineeringblog.yelp.com/2015/11/introducing-paasta-an-open-platform-as-a-service.html
Меня смущает строка «Мы выделили три сервера для кластера Elastic Search и настроили его так, чтобы каждый индекс имел одну реплику...»
Вы реплицируете индекс целиком? Один шард на индекс?
Вы реплицируете индекс целиком? Один шард на индекс?
Верно. Один индекс = 1 шард + 1 реплика.
Такое число мы выбрали сознательно, основываясь на документации, нашей задаче и некоторым статьям с рекомендациями в интернете.
Один шард — это один Lucene индекс, а поиск по индексу должен затронуть все шарды. Т.е. если два разных шарда находятся на двух разных нодах, поиск затронет обе ноды. Т.к. у нас один индекс на день и он не супер-пупер большой, то мы посчитали правильным ускорить поиск за счет использования одного шарда.
По вашему тону я могу судить что вы считаете это неправильным?
Такое число мы выбрали сознательно, основываясь на документации, нашей задаче и некоторым статьям с рекомендациями в интернете.
Один шард — это один Lucene индекс, а поиск по индексу должен затронуть все шарды. Т.е. если два разных шарда находятся на двух разных нодах, поиск затронет обе ноды. Т.к. у нас один индекс на день и он не супер-пупер большой, то мы посчитали правильным ускорить поиск за счет использования одного шарда.
По вашему тону я могу судить что вы считаете это неправильным?
Отнють. Просто поинтересовался этим моментом. Извините, если тон комментария показался резким.
При шардинге в ES поиск (и фильтрация) осуществляется параллельно на всех шардах, поэтому, потенциально можно получить профит в скорости, но при этом возрастёт нагрузка на узлы. Возможно использование роутинга запросов, при котором запрос отправляется лишь на определённый шард и не затрагивает другие. Но необходимо отталкиваться от специфики хранимых данных и задач их обработки.
Поэтому уверен, что вы всё сделали правильно.
При шардинге в ES поиск (и фильтрация) осуществляется параллельно на всех шардах, поэтому, потенциально можно получить профит в скорости, но при этом возрастёт нагрузка на узлы. Возможно использование роутинга запросов, при котором запрос отправляется лишь на определённый шард и не затрагивает другие. Но необходимо отталкиваться от специфики хранимых данных и задач их обработки.
Поэтому уверен, что вы всё сделали правильно.
Добавлю:
Мы тоже используем ELK, тоже ES для хранения логов развернули на 3-х серверах. Но решили, использовать 3 мастер-шарда (по одному на каждую ноду) и одну реплику, подумав, что в случае вылета узла, recover индексов займёт меньше времени за счёт меньшего размера шардов.
Спасибо за интересную статью!
Мы тоже используем ELK, тоже ES для хранения логов развернули на 3-х серверах. Но решили, использовать 3 мастер-шарда (по одному на каждую ноду) и одну реплику, подумав, что в случае вылета узла, recover индексов займёт меньше времени за счёт меньшего размера шардов.
Спасибо за интересную статью!
При шардирование скорость обработки увеличивается, НО съедается место под словарь и управляющие структуры, так как он практически дублируется для каждого шарда.
А при вашем подходе у вас активен только один сервер в день, при выделенных.
Может 2 шарда на индекс + 1 реплика на шард.
А почему вы не поставите haproxy перед 2-мя logstash?
Основное отличие Graylog2 от Logstash, у него встроенный журнал Kafka, то есть сначала он пишет все в журнал, и только потом Elastic.
А при вашем подходе у вас активен только один сервер в день, при выделенных.
Может 2 шарда на индекс + 1 реплика на шард.
А почему вы не поставите haproxy перед 2-мя logstash?
Основное отличие Graylog2 от Logstash, у него встроенный журнал Kafka, то есть сначала он пишет все в журнал, и только потом Elastic.
У вас есть многострочные логи? И если да, то как вы их пишете в syslog?
Рассматривался ли fluentd для буфферизированной доставки логов?
Если говорить о нагрузке, то на данный момент в течение дня приходит от 600 до 2000 строчек с логами в секунду, с периодическими всплесками до 10 тысяч строчек. Данную нагрузку система переваривает без каких-либо проблем.
А можно поинтересоваться мощностью ваших машин выделенных под ELK стек?
Спасибо за статью. Тоже сейчас присматриваемся к ELK. Скажите, есть ли у вас в системе ситуации, когда один объект(запрос) проходит
обработку в нескольких сервисах?
Пример: пришел запрос от пользователя, он попадает сначала в сервис1, затем сервис1 в рамках обработки этого запроса обращается в сервис 2, сервис 2 лезет в сервис 3 и т.д.
Если да, то отслеживаете ли вы в логах историю его обработку в разных сервисах и как у вас это реализовано(можно ли вытащить все логи из всех сервисов по этому запросу и понять, допустим, какой сервис тормозил)?
обработку в нескольких сервисах?
Пример: пришел запрос от пользователя, он попадает сначала в сервис1, затем сервис1 в рамках обработки этого запроса обращается в сервис 2, сервис 2 лезет в сервис 3 и т.д.
Если да, то отслеживаете ли вы в логах историю его обработку в разных сервисах и как у вас это реализовано(можно ли вытащить все логи из всех сервисов по этому запросу и понять, допустим, какой сервис тормозил)?
У нас в Си отделе есть такие ситуации. Не так много, но есть. К примеру один узел кластера какого-либо сервиса может что-то спросить у другого узла или у под-сервиса. Но того, о чем вы говорите, у нас нет. Т.е. посмотреть что где тормозило можно только в большом масштабе, не по конкретному изначальному запросу. Но фича была бы классной, я согласен.
А почему лог за 26.03 почти на порядок больше, чем за последующие (27-29) дни?
Имхо костыль на костыле:
Парни, ну это же азы...
Зачем вообще нужны такие логи?
Пишите в локальные файлы или буферизирующий сервис, оттуда пробрасывайте куда хотите, таким образом развязав создание логов и их процессинг.
- не docker way для контейнеризированных демонов
- блокирующая отправка сообщений в лог и каскадные падения
- возможность потерять логи
- нет стектрейсов
- лишь слегка поднапрягшись, можно было бы сделать структурированную часть лога, которую пишет программист, и получить нормальный поиск по ней
Синхронные вызовы в event loop демона — непозволительная роскошь
Парни, ну это же азы...
Но мы не хотели тратить время на него и быстро сделали третий, т.е. начали писать в syslog по UDP
Зачем вообще нужны такие логи?
Пишите в локальные файлы или буферизирующий сервис, оттуда пробрасывайте куда хотите, таким образом развязав создание логов и их процессинг.
Ваши замечания абсолютно верны, если строить всю инфраструктуру с нуля и у вас нет большого кол-ва уже существующих и работающих сервисов.
Когда вам нужно сделать что-то на летящем самолете, большую роль играет кол-во изменений которое придется сделать для достижения устраивающего всех результата.
Конечно азы. Но вы будете удивлены сколько разных подводных камней зарыто в libc. Выделение памяти в snprintf, если вы используете %f или блокировки для получения таймзоны в localtime_r(). Или как у нас, блокирующая запись в syslog(). Такие вещи не лежат на поверхности. Легко говорить "ну что же вы так" постфактум.
Когда вам нужно сделать что-то на летящем самолете, большую роль играет кол-во изменений которое придется сделать для достижения устраивающего всех результата.
Парни, ну это же азы...
Конечно азы. Но вы будете удивлены сколько разных подводных камней зарыто в libc. Выделение памяти в snprintf, если вы используете %f или блокировки для получения таймзоны в localtime_r(). Или как у нас, блокирующая запись в syslog(). Такие вещи не лежат на поверхности. Легко говорить "ну что же вы так" постфактум.
если строить всю инфраструктуру с нуля и у вас нет большого кол-ва уже существующих и работающих сервисов.
Во многих случаях верное, это замечание сейчас вообще не релевантно.
Такие вещи не лежат на поверхности
Ничего не говорю про другие вещи, только про синхронную запись в асинхронном коде.
Как вы вообще обходились без логов, если у вас допускаются такие вещи?
Я правильно понял, что между локальными для физической машины rsyslog демоном и центральным демоном ЦОДа у вас был TCP? Ведь протокол syslog изначально подразумевает UDP.
Скорее всего и сейчас между rsyslog-ами и сейчас идет tcp. На 100% не уверен. Возможно banuchka ответит.
UDP у нас только от сервиса к rsyslogd. Не потому что нам там так нужны свойства UDP или не нужен оверхед TCP, а потому что посылку по UDP проще сделать асинхронной.
UDP у нас только от сервиса к rsyslogd. Не потому что нам там так нужны свойства UDP или не нужен оверхед TCP, а потому что посылку по UDP проще сделать асинхронной.
Я к тому, что ваша проблема с каскадным отказом возможно решалась не написанием "собственного syslog по UDP", а просто переключением связи между главным демоном цода и демоном машины в UDP режим. Да, вы бы теряли логи, но не теряли стабильность. Честно говоря я ни разу не видел случая, что кто-нибудь включал TCP на передачу syslog в сети.
TCP
При использовании UDP в качестве транспорта для событий есть одна мелочь, на которую я нарывался. Протокол syslog предполагает необязательность поля TIMESTAMP. В этом случае метку времени обычно проставляет принимающая сторона, но UDP может задержаться в пути и так как никакого контроля очередности (как в TCP) нет, то пакеты обработаются в другом порядке, что может сильно осложнить исследование логов. Поэтому приложение должно проставлять таймстамп при генерации события, а принимающая сторона не должна эти стампы игнорить (а есть соблазн так сделать, чтоб синхронизировать логи от разных источников). Оригинальный код libc проставляет время, но сторонние реализации могут на это забить, а зря.
Вообще со временем в syslog засада. Поле таймстамп это просто текст. В этот текст должно вставляться смещение относительно GMT. Но на деле эта информация бывай кем-нибудь да дропится (особенно в собственных костылях), и в результирующий текстовый лог попадает локальное время клиента не пересчитаное во время принимающей стороны. Если у вас куча серверов работает в разных таймозонах тут вам придется походить по граблям. Ну или перевести все сервера в GMT (не всегда возможно, к сожалению).
Вообще со временем в syslog засада. Поле таймстамп это просто текст. В этот текст должно вставляться смещение относительно GMT. Но на деле эта информация бывай кем-нибудь да дропится (особенно в собственных костылях), и в результирующий текстовый лог попадает локальное время клиента не пересчитаное во время принимающей стороны. Если у вас куча серверов работает в разных таймозонах тут вам придется походить по граблям. Ну или перевести все сервера в GMT (не всегда возможно, к сожалению).
Как я понимаю, ELK прекрасно решает задачи «показать крутой дэшборд полный графиков, чтобы сразу было видно общее здоровье систем» и «удобно и быстро посмотреть все сделанные записи по нужному критерию.» Но, скажите пожалуйста, а вот аналога классического tail -f вы на ELK не делали?
Возможно это неправильный подход, но у меня еще есть привычка что когда прилетел алерт, условно говоря, «у нас что-то с гладилкой кота, кот уже 15 минут требует, но все еще неглаженный» то первый же порыв — сделать некое tail -f /var/log/pet.log | grep -w cat | grep -vi meow (за'grep'ав до состояния когда выделено только самое важное и активность логов приемлема для глаз), посмотреть что там такое прямо сейчас творится, а затем так и оставить на соседнем мониторе, чтобы краем глаза можно было именно что вживую наблюдать происходящие процессы и изменения в них.
Возможно это неправильный подход, но у меня еще есть привычка что когда прилетел алерт, условно говоря, «у нас что-то с гладилкой кота, кот уже 15 минут требует, но все еще неглаженный» то первый же порыв — сделать некое tail -f /var/log/pet.log | grep -w cat | grep -vi meow (за'grep'ав до состояния когда выделено только самое важное и активность логов приемлема для глаз), посмотреть что там такое прямо сейчас творится, а затем так и оставить на соседнем мониторе, чтобы краем глаза можно было именно что вживую наблюдать происходящие процессы и изменения в них.
Мы так не делали и не делаем. Для tail заходим на конкретный сервер.
Но я предполагаю что такое делать нужно не в ELK, а до него. Транспорт должен такое поддерживать.
Но я предполагаю что такое делать нужно не в ELK, а до него. Транспорт должен такое поддерживать.
Не вижу никаких проблем делать в Kibana в секции Discover: запрос по конкретному серверу + auto refresh 1 sec
В Graylog 2 новом тоже сделали автообновлялку www.graylog.org/blog/50-announcing-graylog-v2-0-beta-1
#Live taile
В Graylog 2 новом тоже сделали автообновлялку www.graylog.org/blog/50-announcing-graylog-v2-0-beta-1
#Live taile
Спасибо за отличную статью! Скажите, есть ли планы открыть в опенсоурс вашу систему алёртинга для эластика?
Не понимаю, Python чем-то не устроил, но решили переписать на РНР.
Не вижу принципиальной разницы между двумя скриптовыми не типизированными языками.
Sign up to leave a comment.
Сбор и анализ логов демонов в Badoo