Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Мікросервіси та логи

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Привіт усім,

Починаю працювати із мікросервісами. Цікаві думки людей що до налаштування централізованого логування.

Розкажіть про свої кейси, будь ласка.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Sentry хорошо используется для ловли трейсбэков, но не всех логов.

Спроси Oleg Tsarev он знает торт и просто по ходу много пишет про это.
www.facebook.com/oleg.i.tsarev

На каждом хосте поднимаем fluentd контейнер, в который шлют логи все остальные контейнеры на ноде, потом все пересылается в Splunk, AWS CloudWatch, etc...

Юзаем google logging + big query. Агент на хостах (форк fluentd) собирает логи контейнеров, в контейнерах логи собирает supervisord, приводит их к нужному формату и передает в stdout, дальше fluentd превращает их в json и перебрасывает в google logging.

Так проще некуда выходит. Тот кто занимается логикой в контейнере всего лишь должен обеспечить вывод логов в stdout. fluentd идет из коробки на GKE, и сразу начинает эти логи слать в google logging. Дальше уже можно или работать с google logging или организовать выгрузку во внешние источники. В итоге мы получаем распределенную систему, где узлы практически не связанны между собой, и если нам понадобится мы можем заменить любой из них без проблем. Например отказаться от google loging и подключить что то другое.

Ну я логгировал все входные данные плюс сопровождал тайм-штампами максимальной точностью (в моем случае — микросекундной)

ELK.
PS Еще логи и logstash в частности отлично использовать для тестирования.

Для начала может подойти hosted-решение. Например, www.loggly.com

пользуем rsyslog — elasticsearch — kibana
фактически реалтайм при большом кличестве контейнеров.

у вас колько индексов ?
риалтайм кончается когда кол-во активных шардов переваливает за 15-20К.
по этому мы отделили — отдельно риалаймовая смотрелка , отдельно ретроспектива .

Вместо logstash советую обратить внимание на fluentd. По крайней мере оно памяти кушает в разы меньше

там по инпут плагинам все печально.

Как раз по этой причине в свое время перепрыгнул с fluentd на logstash. В последнем все же возможностей поболее.

я смотрел пару дней назад — все еще печаль-беда.

Если не секрет, каких именно плагинов не хватает?

Инпут плагин редис.
Инпут плагин реббит.
Именно для логов.
Это на вскидку.

Так вроде они же отдают просто файл, который fluentd должен прочитать и пушнуть логи в сторедж. Или как это должно работать?

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

Мне так удобнее и процессинг сообщения легче намного по ресурсам.

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

Мне не надо собирать логи по месту. У меня они в редис пушатся.

Вот и я о том, у вас просто другие задачи.

Или вы хотите что бы он вычитывал из редиса логи, который туда кто то запушил?

Так именно так и работает сейчас логстеш.
Все части экосисиемы пушат логи в редис безшовно.
Каналов овер 1000.
Таким образом отвязан пуш логов от их складирования по производительности. Из редиса логи читают логстеш и отдельная риалтайм тулза самописная

Это даёт возможность сквозного логирования по всему флоу.

Ага, ну вот как вариант на серверах может стоять fluentd и пушить все логи в elastic, redis, mongo, etc. Уже в json формате. То есть это не замена logstash, это немного другой подход.

Так если логи будут разнородные по виду полей (по сервисам и т.д.) будут косяки с индексацией.
А так я уверен что мои логи стандартизированы как надо.

Они не могут быть разнородными, задача fluentd привести их к единому виду. Примерно как это делает logstash. Только в данном случае у вас нет бутылочного горлышка в виде logstash, который должен справляться с потоком. Распределенный подход.

Так так мы и проектировали.
Логстеш выполняет роль роутера по индексам и прикручивает ещё пару полей уже из имени самого канала. на нем вообще нагрузки малые в раене 10-20% cpu на t2.medium инстанции амазонa

Все верно и даже сейчас если вам понадобится собирать дополнительно логи с хостов, или контейнеров, вы можете поставить на ноды fluentd и подключить его к своей системе. :)

В контейнерах приложение тоже шлёт в редис. У нас клиен ориентед он деманд инстанции.
Все продумано.

Это хорошо когда вы можете в своем приложении все реализовать. У нас как раз немного другая ситуация, контейнеры для нас черный ящик. Плюс есть немного других сервисов, который не очень то хотят логи слать туда куда нам нужно )

ps: хотя думаю с таким же успехом можно запустить logstash на каждой ноде. И получить ровным счетом тоже самое.

Вы про вашу ситуевину?
Я бы яву в контейнер не ставил.
А файлбитс не умеет парсить. Он только вотчер-шиппер.
Так что тогда таки флуент.

Еще ключевую роль для нас сыграло то, что google agent сам по себе и есть fluentd. Мы искали решение для быстрого старта, с минимальными усилиями. Так же google logging в данный момент бесплатный, а платная только выгрузка в storage или big query.

на серверах может стоять fluentd
вот на сервера это ruby-поделие как-то не хочется ставить... у меня syslog-ng(nodes)>syslog tcp transport->syslog-ng(filtering/buffering)->fluentd->ES

Кстати syslog-ng нормально справляется с временным хранением довольно больших объемов логов в ОЗУ, на случай креша/обслуживания fluentd/ES.
А application logs — filebeat(json)->logstash->ES

Юзал Splunk в двух проектах, имхо самый удобный способ.

Урезанная по самое не могу :). А платный конечно лучшая альтернатива.

graylog, но потом перешли на splunk. У graylog поиск/аггрегация победней, зато он бесплатный.

Класть в редис или рэббит . Разделять сервисы по каналам. Логи сразу в джисоне с полями сервис, сервер и т.д. плюс месседж сам.
Оттуда забирать логстешем и класть в эластиксерч.
Эта архитектура даёт бонус — написать тулзу для риалтаймового просмотра и вычленения нужных событий/сервисов/нод.

Чи вміє логстеш читати логи з файлу в ріалтаймі?

Для чтения из файлов есть filebeats.
Вы же не хотите ставить яву на сервак/контейнер где она не нужна.

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

На контейнерах і так буде стояти джава із томкатом, саме ті логи мене і цікавлять. За filebeat щиро дякую, якраз інвестігейтаю .

redis|rabbit + elasticSearch + filebeat

Два сервера и три фреймворка. Для логов, Карл.
Это Джава.

Файлбит не нужен в случае редиса — читайте внимательное.

И у меня серверов сбора- обработки логов логов 9 штук ;)

5 эластик НОД, редис, логстеш, кибана, и самописный риалиай лог портал который кормится из редиса.

Но логи собираются мягко говоря не с 3 НОД ;)

И это не джава.

Жду альтернативного решения сбора 200 тыс логов в минуту.

А да, забыл лоадбалансер между логстешем и эластик нодами

То дуже сильно. Скільки нод може опрацьовувати така конфігурація?

Зависит от потока логов. Я ж незнаю ваш апликейшн и архитектуру

Що мається на увазі "

самописный риалиай
"?

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

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

О да. Только вы знаете правильный путь ;)
Так вернёмся к логам. Ваше решение для контейнерных микросервисов которые создаются он деманд и исчезают без следа

Жду альтернативного решения сбора 200 тыс логов в минуту.

Ну давайте попробуем, начнем с самых основ.

Жду альтернативного решения сбора 200 тыс логов в минуту.

При средней длине строчки лога в 100 символов, это получается поток в 20 мб/сек записи на диск для ... парка из 8 серверов. Дальше продолжать ?

1) лог длиннее
2) все должно работать при падении с небольшой избыточностью
3) все происходит в амазоне и вы же не знаете какие инстансы я использую.
4) вы знаете что такое random write?
5) это готовая систем сбора и отображения в разных кейсах . а не только база.

Кароче. Излагайте своё видение решения проблем топикастера.

Гавном может любой кидается.
Ждём технического решения от вас.

1) лог длиннее
2) все должно работать при падении с небольшой избыточностью
3) все происходит в амазоне и вы же не знаете какие инстансы я использую.
4) вы знаете что такое random write?
5) это готовая систем сбора и отображения в разных кейсах . а не только база.

Это не техническое изложение.
Причем тут Амазон к технической части. Длинее. На сколько длинее. Где техническая цифра ? Причем тут рандом врайт для логов, что это за логи, их нельзя делить на разные файлы ? Наверняка логи чистятся/архивируются, когда ? Если это готовая система, то зачем вам техническое решение на 1 сервер плюс зеркало если никто не будет переписывать это ?

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

Подход в работе с эластиксерч не подразумевает хранения файлов там есть индексы, вы кладете туда даныне в джисоне . и делаете оттуда выборки . у меня данные хранятся за 2 недели , потом старые индексы убиваются.
никаких архивов и т.д.

выше описаная мною система покрывает потребности в поиске логов и выборках по произвольным полям + риалтайм мониторинг по любому эвенту.

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

Лол. Просто Лол.
Если вы внимательно почитаете мой ник, то поймете что это ссылка на поисковик. С собственным движком, который молотит 55 мб/сек чистого текста или до 200 мб/сек html. (Вы не забыли ? у вас всего 20 мб) Где складываются не однотиповые лог записи, а целые документы разбитые на десятки тысяч слов, с сжатием индекса до 99%. Вся база под терабайт. И всё это крутится на одном дохлом сервере, вместе с краулером и кучей разного ПО для отладки. Там где подтормаживает, то запрос подразумевает 15 млн вложеных подзапросов, по базе которая даже не в памяти. А еще Алеха в статистике показывает, что сайт входит в 4% самых быстро работающих серверов интернета.

Но вы не отвлекатйесь. Расскажите как 8 серверов занимаются только тем что пишут логи ...

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

Я ежедневно пользуюсь построенной системой , и не только я.
Мне нравится шардинг, 100500 инпут аутпут плагинов и простота интеграции. Ну и производительность.

Стройте под столом свои воздушные замки . кто ж вам мешает.

Мне кажется что вы из тех людей у которых есть мнение «мое» и «неверное».

Человек задал вопрос , получил ответ от меня и поток созанания от вас )

Вы главное не расстраивайтесь. Очень много корпоративного ПО написано, мягко говоря, не оптимально. Крупные компании могут себе позволить оптмизировать свои архитектурные решения, пример с темже Тарантулом где выбросили XXХ серверов и заменили несколькими в Mail.Ru например.
Остальные, держат админов конфигурастов у которых задача налепить побольше и «похвастаться» на форуме. Поэтому я изначально ставил правильный вопрос. Вы хвастаетесь или жалуетесь.

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

Что вы собрались строить, интересно, если даже не были озвучены нагрузки ? Может у него тех логов с десяток мегабайт в сутки, а вы уже три фреймворка и два сервера насоветовали.

сейчас не спроектирует нормально — потом не отмасштабирует.

Все еще жду от вас решения по сбору , индесации , отображению с полнотекстовым поиском, и каким-никаким дженерик интрефейсом.

сейчас не спроектирует нормально — потом не отмасштабирует.

Никому не говорите что у вас нормальная архитектура. Не та что у вас там стоит сейчас, не ту что насоветовали ТС. Этот геморрой никому не нужен. Если логов мало, завести табличку, писать в базу и не морочить себе голову.

За X лет которые дойдет до масштабирования, будет секономлено ХХХХ$ денег админов и на оборудовании. И главное секономлено множество нервных клеток. Чтобы потом не было. «Эй слушай, а что это за Вася Админ тут налепил модулей, конфиги отпали, апдейты стали криво, нужно все перестроить, права слетели .... где мануал как это все настроить. Ну кому бл* пришло в голову сделать обычные логи через одно место».

Решение. Ждём от вас решения для топикастера, а не графоманство.

Если логов не очень много, то в текущей базе данных завести табличку для логов. На колонке поставить ФТС если нужно искать по содержимому, а не по дате. Если логов больше, есть варианты с очередью, дабы сгладить пиковые нагрузки.
Потратить на это часа два времени. Всё.

Если логов не очень много, то в текущей базе данных завести табличку для логов
Топикстартер написал три коротких предложения. Неужели тяжело внимательно прочитать и понять, что вы несёте ахинею?
Давайте тогда уже дальше советуйте — зачем автору микросервисы? можно ведь просто написать php скрипт, вот он и будет логи писать в вашу табличку. Просто и за час всё можно сделать.
А то развелось, понимаешь, конфигурастов — микросервисы они пробуют, кластера строят

Файт. У меня спорить с Boolen Com просто сил уже нет — закончились приличные слова. Воинственному гению ничего не докажешь.

Вы главное не расстраивайтесь
Вот если бы я мог создать движок, который в 100500 раз лучше того что предлагает рынок, но при этом ни смог ни продать его за много миллионов, ни даже заопенсорсить, принеся радость всему сообществу — вот я бы тогда от досады завыл.
А так — да, я понимаю, что ES жрёт ну очень неприлично ресурсов, но поскольку он бесплатен и он РАБОТАЕТ и выполняет возложенные не него функции — я доволен, и Ник, уверен, тоже.

В файбитсе работает декларирование по одному логу. Списком не работает — хз почему. Так что декларируйте в конфиге поочередно.
Ещё один хинт — чем больше отдельных рабочих полей отдельных тем меньше надо использовать grok filter, и тем самым уменьшать нагрузку на логстеш.
Но это не ваш вариант — вы собираетесь грести логи балком. И вам придётся их постпроцессить.

Окей, круто. ДЕ і ЯК поля розділяти?

Прям внутри кода.
Писать либу логирования. Интегрировать во все части апликейшна и вызовами её , вызовами. Т.е. юзать вместо или параллельно с стандартным логгером.

Filebeat може по UDP трансферити?

Понятия не имею. Через паблик сети ничего не идет.
Да и в случае удп — нет гарантии доставки, и не уверен что редис или реббит умеет удп.

А вариант с kafka рассматривали ? он ведь даёт такие возможности

Нет. Не рассматривал. Возможно позже если что-то перестанет устраивать буду по сторонам смотреть.

На хабре было пару статей что это мягко говоря не самый надежный и легковесный вариант

1. Писать в отдельном потоке
2. Если по сети передавать, использовать UDP
3. Иметь возможность включить\отключить логирование в настройках системы
4. В логах должна быть наиболее полная информация. Модуль\Класс\Метод\Дата
5. Если логов много, попробовать разбить по северити
6. Добавить возможность архивировать логи, ежемесячно, еженедельно и тд.
7. Просмотреть чтобы логи не содержали секурной информации. Если содержат — или шифровать, или замылить данные.
8. Поискать и заюзать существующий какойнить фремворк вроде nLog

Круто. Але чи може NLog слати логи IISу наприклад у випадку з .NET?

Підписатись на коментарі