Как мы в ЦИАН укрощали терабайты логов



    Всем привет, меня зовут Александр, я работаю в ЦИАН инженером и занимаюсь системным администрированием и автоматизацией инфраструктурных процессов. В комментариях к одной из прошлых статей нас попросили рассказать, откуда мы берем 4 ТБ логов в день и что с ними делаем. Да, логов у нас много, и для их обработки создан отдельный инфраструктурный кластер, который позволяет нам оперативно решать проблемы. В этой статье я расскажу о том, как мы за год адаптировали его под работу с постоянно растущим потоком данных.

    С чего мы начинали




    Последние несколько лет нагрузка на cian.ru росла очень быстро, и к третьему кварталу 2018 года посещаемость ресурса достигла 11.2 млн уникальных пользователей в месяц. В то время в критические моменты мы теряли до 40% логов, из-за чего не могли оперативно разбираться с инцидентами и тратили очень много времени и сил на их решение. Еще мы часто не могли найти причину проблемы, и она повторялась спустя какое-то время. Это был ад, с которым надо было что-то делать.

    На тот момент для хранения логов мы использовали кластер из 10 дата-нод с ElasticSearch версии 5.5.2 с типовыми настройками индексов. Его внедрили больше года назад как популярное и доступное решение: тогда поток логов был не такой большой, смысла придумывать нестандартные конфигурации не было. 

    Обработку входящих логов обеспечивал Logstash на разных портах на пяти координаторах ElasticSearch. Один индекс, независимо от размера, состоял из пяти шардов. Была организована почасовая и дневная ротация, в результате каждый час в кластере появлялось порядка 100 новых шардов. Пока логов было не очень много, кластер справлялся и на его настройках никто не заострял внимания. 

    Проблемы быстрого роста


    Объем сгенерированных логов рос очень быстро, так как друг на друга наложились два процесса. С одной стороны, пользователей у сервиса становилось все больше. А с другой, мы начали активно переходить на микросервисную архитектуру, распиливая наши старые монолиты на C# и Python. Несколько десятков новых микросервисов, заменявших части монолита, генерировали заметно больше логов для инфраструктурного кластера. 

    Именно масштабирование и привело нас к тому, что кластер стал практически неуправляем. Когда логи начали поступать со скоростью 20 тыс. сообщений в секунду, частая бесполезная ротация увеличила количество шардов до 6 тысяч, а на одну ноду приходилось более 600 шардов. 

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

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

    Мы поставили задачу — полностью исключить потерю логов и сократить время их доставки в кластер ELK максимум до 15 минут во время форс-мажоров (на эту цифру в дальнейшем мы опирались, как на внутренний KPI).

    Новый механизм ротации и hot-warm ноды




    Преобразование кластера мы начали с обновления версии ElasticSearch с 5.5.2 на 6.4.3. У нас в очередной раз лег кластер 5 версии, и мы решили его погасить и полностью обновить — логов-то все равно нет. Так что этот переход мы совершили всего за пару часов.

    Самым масштабным преобразованием на этом этапе стало внедрение на трех нодах с координатором в качестве промежуточного буфера Apache Kafka. Брокер сообщений избавил нас от потери логов во время проблем с ElasticSearch. Одновременно мы добавили в кластер 2 ноды и перешли на hot-warm архитектуру с тремя «горячими» нодами, расставленными в разных стойках в дата-центре. На них мы по маске перенаправили логи, которые нельзя терять ни в коем случае — nginx, а также логи ошибок приложений. На остальные ноды уходили минорные логи —  debug, warning и т. п., а также через 24 часа переезжали «важные» логи с «горячих» нод.

    Чтобы не увеличивать количество индексов малого размера, мы перешли с ротации по времени на механизм rollover. На форумах было много информации о том, что ротация по размеру индекса очень ненадежна, поэтому мы решили использовать ротацию по количеству документов в индексе. Мы проанализировали каждый индекс и зафиксировали количество документов, после которого должна срабатывать ротация. Таким образом мы достигли оптимального размера шарда — не более 50 Гб. 

    Оптимизация кластера




    Однако полностью от проблем мы не избавились. К сожалению, все равно появлялись маленькие индексы: они не достигали заданного объема, не ротировались и удалялись глобальной очисткой индексов старше трех дней, так как мы убрали ротацию по дате. Это приводило к потере данных из-за того, что индекс из кластера исчезал полностью, а попытка записи в несуществующий индекс ломала логику curator’а, который мы использовали для управления. Alias для записи преобразовывался в индекс и ломал логику rollover’а, вызывая бесконтрольный рост некоторых индексов до 600 Гб. 

    Например, для конфига ротации:

    сurator-elk-rollover.yaml
    
    ---
    actions:
      1:
        action: rollover
        options:
          name: "nginx_write"
          conditions:
            max_docs: 100000000
      2:
        action: rollover
        options:
          name: "python_error_write"
          conditions:
            max_docs: 10000000
    


    При отсутствии rollover alias возникала ошибка:

    ERROR     alias "nginx_write" not found.
    ERROR     Failed to complete action: rollover.  <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".
    


    Решение этой проблемы мы оставили на следующую итерацию и занялись другим вопросом: перешли на pull логику работы Logstash, занимающегося обработкой входящих логов (удалением лишней информации и обогащением). Мы поместили его в docker, который запускаем через docker-compose, там же разместили logstash-exporter, который отдает метрики в Prometheus для оперативного мониторинга потока логов. Так мы дали себе возможность плавно менять количество инстансов logstash, отвечающих за обработку каждого вида логов.

    Пока мы совершенствовали кластер, посещаемость cian.ru выросла до 12,8 млн уникальных пользователей в месяц. В результате получилось, что наши преобразования немного не успевали за изменениями на продакшене, и мы столкнулись с тем, что «теплые» ноды не справлялись с нагрузкой и тормозили всю доставку логов. «Горячие» данные мы получали без сбоев, но в доставку остальных приходилось вмешиваться и делать ручной rollover, чтобы равномерно распределять индексы. 

    При этом масштабирование и изменение настроек инстансов logstash в кластере осложнялось тем, что это был локальный docker-compose, и все действия выполнялись руками (для добавления новых концов необходимо было руками пройти по всем серверам и везде сделать docker-compose up -d).

    Перераспределение логов


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



    Следующую итерацию мы начали с обновления железа. С пяти координаторов мы перешли на три, заменили дата-ноды и выиграли по деньгам и по объему хранилища. Для нод мы используем две конфигурации: 

    • Для «горячих» нод: E3-1270 v6 / 960Gb SSD / 32 Gb x 3 x 2 (3 для Hot1 и 3 для Hot2).
    • Для «теплых» нод: E3-1230 v6 / 4Tb SSD / 32 Gb x 4.

    На этой итерации мы вынесли индекс с access-логами микросервисов, который занимает столько же места, сколько логи фронтовых nginx, во вторую группу из трех «горячих» нод. Данные на «горячих» нодах мы теперь храним 20 часов, а затем переносим на «теплые» к остальным логам. 

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

    В результате в кластере получилось шесть «горячих» и всего четыре «теплых» ноды. Это вызывает небольшую задержку на запросах по большим интервалам времени, но увеличение числа нод в будущем решит эту проблему.

    В этой итерации исправили и проблему отсутствия полуавтоматического масштабирования. Для этого мы развернули инфраструктурный Nomad кластер — аналогичный тому, что уже развернут у нас на продакшен. Пока количество Logstash автоматически не изменяется в зависимости от нагрузки, но мы придем и к этому.



    Планы на будущее


    Реализованная конфигурация отлично масштабируется, и сейчас мы храним 13,3 Тб данных — все логи за 4 суток, что необходимо для экстренного разбора алертов. Часть логов мы преобразуем в метрики, которые складываем в Graphite. Чтобы облегчить работу инженеров, у нас есть метрики для инфраструктурного кластера и скрипты для полуавтоматической починки типичных проблем. После увеличения количества дата-нод, которое запланировано на следующий год, мы перейдем на хранение данных с 4 до 7 дней. Этого будет достаточно для оперативной работы, так как мы всегда стараемся расследовать инциденты как можно скорее, а для долгосрочных расследований есть данные телеметрии. 

    В октябре 2019 года посещаемость cian.ru выросла уже до 15,3 млн уникальных пользователей в месяц. Это стало серьезной проверкой архитектурного решения по доставке логов. 

    Сейчас мы готовимся обновить ElasticSearch до версии 7. Правда, для этого придется обновлять mapping многих индексов в ElasticSearch, т. к. они переехали с версии 5.5 и были объявлены как deprecated в 6 версии (в 7 версии их просто нет). А это значит, что в процессе обновления обязательно будет какой-нибудь форс-мажор, который на время решения вопроса оставит нас без логов. Из 7 версии больше всего ждем Kibana с улучшенным интерфейсом и новыми фильтрами. 

    Основной цели мы достигли: перестали терять логи и сократили время простоя инфраструктурного кластера с 2-3 падений в неделю до пары часов сервисных работ в месяц. Вся эта работа на продакшене почти незаметна. Однако теперь мы можем точно определить, что происходит с нашим сервисом, можем быстро делать это в спокойном режиме и не переживать, что логи потеряются. В общем, мы довольны, счастливы и готовимся к новым подвигам, о которых расскажем позже.
    ЦИАН
    0,00
    Компания
    Поделиться публикацией

    Похожие публикации

    Комментарии 42

      +5
      Занятно.
      Одно из неочевидных последствий перехода на микросервисную архитектуру — увеличение количества логов. Что приводит к определенному росту издержек.
        +2
        Да, есть такой фактор. Уровень издержек не на столько высок, что бы отказываться от перехода.
          –4
          Вполне очевидное последствие для тех, у кого достаточно IQ, чтобы проанализировать переход на микросервисы.
            +4
            Во множестве статей про то, как классно сделать переход на микросервисную архитектуру, не акцентируется вопрос о том, что количество логов может существенно вырасти. Поэтому этот аспект я выделил в своем комментарии.
            А вот ваш комментарий это и есть та самая «токсичность». Информации он дает 0. Зато идет такая «не очевидная» (на самом деле очевидная) негативная оценка IQ собеседника.
            Ну ваше ЧСВ получило порцию удовлетворения? Почувствовали себя великим, не таким, как серая масса окружающих? Ну, пусть вам будет хорошо.
              +2
              Дело не в ЧСВ. Да, комментарий немного токсичный, потому что я не люблю демагогию про очевидные вещи.
              Про количество логов:
              У вас монолит или SOA. 1-10 «юнитов» которые сыпят логи. Логично что при переходе на микросервисы уникальное количество «юнитов» — возрастёт, минимум в 3 раза. Плюс горизонтальное маштабирование каждого юнита. Плюс distributed(request) tracing.
              Ну это реально очевидно, если просто подумать.
              Не надо читать про «классные переходы» на микросервисы. Надо думать надо оно вам или нет, какая выгода для бизнеса и команды будет от этого перехода. И «рост издержек» от увеличения трафика логов — поверьте, это 1% от того, с чем можно столкнуться если не правильно провести анализ. Не надо работать по статьям. Надо работать головой.
              По вашим комментариям сформировывается образ человека который отвергает новые технологии/альтернативные пути. Могу предположить что докер для вас был занозой в одном месте, а когда все заговорили про kubernetes и микросервисы — вообще наступила депрессия. «опять эти новые тренды и хипстеры». Вот по этому я и написал немного с токсичностью.
              Кстати оценку IQ по комментариям я не провожу, Вам показалось.
                –1
                Вы со своего олимпа даже не замечаете, что, и главное «как» вы говорите.
                Однажды дочь у меня не сдала физику. Я ее, спросил, почему она не подошла ко мне, я бы ей объяснил тему. На что она дала замечательный ответ: «Если бы я знала, что я это не знаю, я бы сама подготовилась по этой теме».
                Про «докеры, микросервисы и прочее» я смотрю по диагонали. Я работаю с СУБД и эта тема меня напрямую не касается. И не может быть причиной депрессии. Но глядя «по диагонали», я выделил, что рост числа логов ну не обсуждается практически и обратил на это внимание. Что бы кто то, прочитав, узнал «что он не знает эту тему».
                И прочитав, он приблизится к вам «великим» которым сразу все ясно видно, т.к. вы, в отличии от прочих «думаете головой».
                Ощущаете разницу с «демагогией» по вашему?
                Еще я коснулся этой темы, потому, что прямо сейчас мы решаем вопрос загрузки БД, когда команда мобильного приложения и веб приложения стала лить свои логи вдруг, объем которых превысил на порядок другой, объем собственно рабочих данных. С нами (группой СУБД) проконсультироваться забыли, СУБД это же такая фигня, которая «просто хранилище данных», вот «докер, кибернетик и микросервисы» это здорово и круто. Все на свете знать невозможно, даже если думать головой, поэтому люди и читают форумы и обмениваются мнениями, и лучше это делать без «немного токсичности» даже если вы что то не любите.
                Кстати оценку IQ по комментариям я не провожу, Вам показалось.

                Вы это сделали. Вы уже построили образ у себя в голове, не имея на то информации. И сразу выплеснули «немного с токсичностью».
                В свою очередь, читая ваши комментарии, я делаю вывод, что вы не командный игрок. Вы «гений», не знаю оцененный или нет. С вами не комфортно работать. И таких «гениев» лучше не брать в команду, не смотря на компетенции, будет проседать работа окружающих, издержки возрастут.
                Я видел такое не один раз. Работает такой все знающий «гений». Все вокруг просто не желают «работать головой». ТЗ ему пишут не правильные. Тестировщики не правильно тестируют. Коллеги не правильно пишут код. Ну очевидно же, что все можно сделать сразу хорошо. И вот, дарование увольняется ибо тут «нечего делать».
                Приходит на его место другой разработчик. И вдруг — к ТЗ нет вопросов, с тестировщиками нет проблем, а коллеги неплохие ребята. Работа идет, вокруг спокойствие и дружелюбие. И ладно бы косяки поперли, «главная голова то ушла», но нет. Их тоже становится меньше.
                Многие любят смотреть Хауса, и возможно, перенимают его токсичное поведение, не знаю. Не акцентируясь на том, что у Хауса некий талант, за что его и терпят. Без таланта и не находясь в том месте, где именно этот талант востребован, ведут себя токсично. Что плохо. Хорошо быть с талантом Хауса и при этом быть хорошим человеком.
                  +1
                  Извините, если мои высказывания слишком жёсткие для вас, я стараюсь говорить свои мысли искренне и по делу. Замес в комментах не планировал, интереса продолжать — нет.
          0
          Не понял из статьи. Кластер еластика и логстэш не «тюнили» что ли?
            +1
            Logstash у нас раньше были «тюнингованные». В последствии перешли на докер-образы с базовыми настройками по количеству пакетов, и т.п. Кастомными остались только pipeline'ы, отвечающие за обработку и обогащение логов.

            Тюнинг Elasticsearch не настолько крут, что бы об этом писать. Вся кастомизация заключается в настройке кластера и индексов под профиль нагрузки, с указанием удобный watermark'ов, threshold'ов и отключением автоматической балансировки.
              0
              Кубер есть? И почему Logstash? Fluentd не смотрели? Fluentbit — ещё быстрее чем fluentd.
                +1
                Кубера пока нет, смотрим на него, но пока Nomad закрывает 99% потребностей оркестрации.

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

                На fluentd смотрели, когда начинали модернизацию, оценили трудозатраты на переделку всего и поняли, что овчинка выделки не стоит. Возможно пересмотрим еще в будущем, так как сейчас уже вернули rsyslog вместо filebeat по некоторым направлениям.
                  0
                  Я к тому что kafka с zookeeper — скорее всего сложнее чем Fluentd.
                  Но раз нет кубера, я бы тоже не стал заморачиваться с переходом на Fluentd.
                    0
                    kafka+zookeeper это несколько часов гугление о технологии и потом еще несколько на написание роли в saltstack. Все. На этом обслуживание данного стэка заканчивается (в нашем узком случае с логами). В части дополнительных затрат это стоило нам +6 SATA дисков по 2Тб (суммарно на 3 сервера).
                      0
                      А Вы не смотрели в сторону Redis вместо Kafka в качестве промежуточного буфера? Очень простой и невероятно производительный. Наша архитектура логгирования такая:
                      1. Микросервисы пишут логи в формате json в stdout (написана общая библиотека под наши платформы, которая занимается генерацией json, — Node.js, Java, Python, .NET Core).
                      2. Docker демон настроен слать логи в 172.17.0.1 по протоколу Gelf по UDP без сжатия (показал себя с лучшей стороны в части производительности).
                      3. На каждом сервере запущен Logstash (Shipper), который слушает Gelf/UDP трафик и принимает логи от Docker демона. Понимаю, что Logstash выглядит как оверкилл, но в нашем случае хосты достаточно большие (по 130+ контейнеров на хост, Nx64GB RAM), время его запуска мало, а буферизировать в себе он может достаточное для нас количество логов (это если логгинг кластер недоступен).
                      4. Эти инстансы Logstash (Shippers, из #3) никак логи не модифицируют, только добавляют пару тэгов и отправляют в кластер логгирования, в Redis в различные Redis Lists в зависимости от тегов.
                      5. На стороне логгинг кластера логи приезжают в Redis (используем standalone инстансы).
                      6. Далее инстансы Logstash (Indexer) забирают логи из Redis, обрабатывают их (фильтры Json, Grok) и складывают в различные индексы кластера Elasticsearch.
                      7. Дополнительно есть Elastalert, который имеет кучу правил и если что не так — шлет нам сообщения.

                      Несколько замечаний:
                      1. Идея писать логи сразу в формате Json оказалась очень удачной — с одной стороны, используя глобальные общие библиотеки для логгирования, мы можем достаточно хорошо стандартизировать основную часть логов (у нас более 550 различных микросервисов), а с другой стороны — дать гибкость в добавлении любого количества кастомных полей к лог-записям.
                      2. Через Redis мы также пропускаем логи из различных Filebeat.
                      3. Все компоненты системы логгирования (да и вообще всё у нас) запущены в Docker контейнерах
                      4. У нас нет Kubernetes/etc. Старый добрый (на самом деле нет) Swarm (это который ещё до Docker Swarm Mode).
                        0
                        Нет, не смотрели. За счет кафки мы хотели получить несколько плюсов:
                        — возможность накапливать логи какое-то продолжительное время в случае проблем с лог-кластером
                        — возможность повторно направить логи, если индекс по какой-то причине умер (ни разу не пользовались правда еще)

                        У нас сейчас 1.5Тб логово во временном хранилище. Нам это обходится в 3000 рублей в месяц (аренда серверов, дополнительные диски для кафки). Поэтому redis вообще не вариант.

                        Теперь по пунктам.

                        1. Аналогично. У нас на уровне платформы реализовано аналогично. И да, это очень удобно когда все логи в едином формате. У нас еще есть небольшие проблемы с логами монолита, но это временно.
                        2. У нас за логи отвечает Nomad, он их складывает в определенном месте, где их filebeat по маске отправляет в кафку
                        4. Тэги в зависимости от хоста или от контейнера?
                        5. А сколько у вас инстансов Redis? Какой объем памяти? Если падает редис, поток логов переключается на другой инстанс? Сколько логов (по времени) может 1 инстанс продержать и какая политика по удалению старых?
                        7. Elastalert так и не попробовали. Хватает Prometheus+AlertManager его родной + слерты из графаны бэкапом.
                          +1
                          Спасибо за ответ.

                          4. Тэги в зависимости от хоста или от контейнера?

                          У нас в локальный Logstash (Shipper) данные входят не только от Docker демона, но и, к примеру, от HAProxy (он не умеет в stdout, так что наш Logstash слушает отдельный порт — Syslog/UDP). То есть, тэги присваиваются в зависимости от того, откуда пришел эвент.

                          А сколько у вас инстансов Redis?

                          В проде — 4. Средний объем входящих логов в день — 100-150ГБ. Храним в Эластике последний месяц, но индексы старше недели закрываем.

                          Какой объем памяти?

                          Redis контейнеры у нас запущены на тех же хостах, что и некоторые остальные компоненты логгинг платформы, так что им не вся память отдана. Но большую часть времени они пустые и в них задерживается не больше сотни эвентов — остальное выгребается Logstash.

                          Если падает редис, поток логов переключается на другой инстанс?

                          По умолчанию, Losgtash (Shipper) шлёт логи в Redis по принципу Round robin, так что нагрузка сразу распределяется. Если инстанс Redis отгнивает по какой-то причине, Logstash очень быстро это обнаруживает и перестает слать в этот инстанс логи.

                          Сколько логов (по времени) может 1 инстанс продержать?

                          Наш практический опыт — чуть более часа с недоступным Elasticsearch. Прошло всё нормально — после включения кластера, естественно, был большой всплеск нагрузки, но, насколько мы разобрались, мы ничего не потеряли.
            –1
            у нас есть метрики для инфраструктурного кластера и скрипты для полуавтоматической починки типичных проблем.
            Рассмешили. То есть действовать так, чтобы типичных проблем не возникало — это даже рассматривается. А вот чинить в полуручном режиме — к этому готовы.
            Ну, в принципе понятно. Если админу не надо ничего периодически чинить, то он как бы и не нужен. Да и тысячи тонн логов в одной большой компостной куче тоже становятся не очень нужны.
              +7
              В идеальном мире — вы правы. В реальном вы можете столкнуться с проблемами ПО, с которыми вы не можете справиться. И вам никто не поможет — даже разработчики самого ПО, потому что вы просто не можете им повторить конкретную проблему для баг репорта. К примеру, в rabbitmq при непонятных для нас обстоятельствах могут образоваться т.н. «мёртвые очереди» — вы с ними вообще ничего не можете сделать (даже удалить нормально не можете ни через UI, ни через cli). Но в этот момент отправка сообщений, которые роутятся в такие очереди начинают очень сильно тупить и это уже аффектит приложение. Всё это случается, к счастью, не регулярно, но единственным быстрым решением пока является выполнеие некой «магической» cli операции, которая через прямой eval в бэк rabbitmq убивает сломанную очередь.
              Поэтому я бы не был бы так категоричен в своих высказываниях, потому что по моему опыту категоричные люди делятся на две категории: супер-боги-знающие-всё и те, кто просто ещё не встретил свой «пистолет с большой мушкой» на своём профессиональном пути.
              +2
              Думаю, надо не закрывать доступ к Эластику снаружи, а потом при необходимости скачать логи из торрента
                +2
                Отличный лайфхак, но нет ))
                  0
                  Судя по новостям — это новый тренд. Раньше монгу не закрывали, сейчас эластик.
                  +1

                  А были какие-то мысли, как уменьшить количество записываемых и сохраняемых логов?
                  Первая мысль, которая приходит ко мне в голову — сэмплирование трассировок для проверки производительности. Раз логи проходят через кафку, то можно большую часть успешно выполненных запросов просто выкидывать (выкинуть всё межсервисное взаимодействие, логи БД итд, оставляя только запись на входящий nginx), не записывая никуда, они не очень нужны.

                    0
                    Хорошая идея, но при расследовании ошибок иногда очень нужно понять, что запрос дошёл до такого-то микросервиса. Логи БД и пр. мы пишем только очень выборочно (при превышении пороговых значений CPU, read, write, duration). Мы используем jaeger (вероятностный trace) и ещё свою систему автопрофилирования (trace по превышению длительности ответа), т.е. полностью прям всё мы, конечно, не пишем.
                      0

                      У меня идея такая, что если запрос успешно завершился, то это можно понять, вычитав логи по данному запросу из кафки максимум за минуту после запроса, ведь так? Соответственно можно написать относительно простой фильтр-консьюмер, который будет фильтровать логи трассировок из входящей очереди (фильтры можно легко пошардить по reqid, чтоб можно было масштабировать по числу ядер) и перекладывать уже в очередь из которой вычитывает логстеш. Если попало под паттерн семплирования (500я ошибка/время выполнения большое/req_id кратен 1000, итд) — оставляем весь трейс, не попало — выкидываем в мусорку. ЕМНИП Cloudflare про что-то подобное рассказывали.
                      С другой стороны — это лишнее копирование трейсов из очереди в очередь, и я не знаю, есть ли готовые кирпичики, чтоб это быстро сделать.

                        0
                        Запрос проходит через разные микросервисы и монолиты, и попадает в разные топики Kafka и, в результате, в разные индексы эластика. Каждый топик обрабатывает своя пачка Logstash со своим pipeline. Простой фильтр тут вряд ли выйдет, особенно если учесть, что это надо будет писать на встроенном Ruby. Мне кажется что положительный эффект будет сильно меньше, чем затраченное на разработку время. Было бы интересно почитать об опыте Cloudflare, поищу.
                          0

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

                          0
                          Да, годная идея. Но она будет работать только если можно гарантировать 100% прокидывание reqid абсолютно по всем микросервисам. Причём при любых ответах (даже при экстренно завершённых запросах на проксе).
                      +1
                      Попробуйте еще укротить всплывающее окошко «Войдите в ЦИАН через почту Mail.ru». Надоело его КАЖДЫЙ раз закрывать при открытии сайта. Захочу войти — войду с логином и паролем.
                        +2
                        Настройка ES — это хорошо, но у вас неоправданно большой объем логов при такой нагрузке, сдаётся мне, что разработчики логируют слишком много всего на всякий случай, возможно этим компенсируется низкое качество кода или процессов.
                          0
                          Не всегда возможно определить что работает под капотом у интернет-проекта. До прихода в ЦИАН я и не подозревал о том, как это все работает. Поэтому, как мне кажется, количество RPS (количество пользователей, количество запросов, etc) на фронты не единственный верный показатель, но с его помощью можно хоть что-то сравнить.
                            0
                            Микросервисная архитектура, как и любая другая, даёт плюсы, но требует за это ресурсы. В данном случае — увеличение количества запросов. Для бизнеса «развязать» руки и уметь быстро релизить и пробовать различные RnD проекты и эффективнее тратить время дорогостоющих сотрудников гораздо ценнее, чем лишние несколько тачек.
                            0
                            Используете ли логи для создания датасетов для машинного обучения?
                            По сути, имея такой объем, можно интересные штуки делать. К примеру, всевозможные штуки по юзерам считать, используя логи с фронта, или по логам внутренних сервисов отслеживать проблемы ранее, чем это покажет мониторинг по пороговым значениям?
                              0
                              Есть инстуремнты мониторинга, которые предсказывают выход контрольных значений за пороговые. Точно есть у решения от Data Dog, возможно и в других системах тоже. Хотя там особо нейронок и не надо, просто построение прогнозов изменения характеристик по прошлым значениям, там скорее всего что-то типа линейной функции будет.
                                0
                                Мы используем логи в ML не для мониторинга, а как один из компонентов поведенческого анализа. То, что делает Data Dog, похоже на базовые модели предсказания временных рядов (ARIMA, например) и поиск аномалий.

                                Мы сейчас начинаем развивать направление по предсказания завершения капасити кластеров на основе метрик node_exporter'а.
                                0
                                Да, мы параллельно отправляем все access-логи в ML, которые потом используются, например, для работы внутреннего антибота. Это, конечно, не единственная цель :)
                                +1

                                А в чем сложность обрабатывать 50 мегабайт текстовых данных в секунду? Я в однопотоке парсю и валидирую (tsv) данные быстрее чем ссд (400МБ/с +-) может предоставить. Если замасштабировать на типичные 10-20 потоков то процессор уже не будет узким горлышком. Серверная часть тоже не должна вносить много оверхеда если даже на asio делать.

                                  0
                                  Так нужно хранить и фильтровать по запросу, а не просто при получении обрабатывать.
                                    0
                                    Хранение — бесплатная операция с точки зрения ЦПУ. Запись тоже околобесплатное если NVME и DMA + MM.
                                    Обработка по запросу — оно и по-запросу, это запрос событие раз в неделю судя по статье, поэтому скоростью можно пренебречь (да и выборка скорее всего будет небольшая исходя из даты и времени).
                                    Фильтрация — штука дешевая если все правила плюс одна сточка из лога помещаются в кэш L1 процессора, а они скорее всего поместятся, если не будет дополнительных фоновых процессов жадных к кэшу процессора.
                                    Однопоточная архивация это около 1ГБ\с, в зависимости от данных, но можно поискать алгоритмы и побыстрее, например с предварительно обученными на логах словарями.

                                    Вобщем можно свелосипедить экономически выгодное решение решение для замены 10 сетевых нод на 1 (Кажется подобный велосипед делал Антон Полухин antoshkka в яндексе для эффективной замены logstash, гдето в сети была презентация).
                                      +1
                                      Как можно говорить про работу с логами не считая их хранение? Не все в мире измеряется быстрой обработкой на проце сразу при появлении данных.

                                      Типичный пример из моей практики: примерно 50 ТБ логов на одной машинке (это несколько месяцев). И часто нужно искать за фиг знает какое число и по какому-то ключу и куче условий быстро, т.к. разработчики не хотят ждать дольше единиц секунд. А легкие запросы — сотни миллисекунд. И вот тут все упирается далеко не в процессор (хотя и он нагружен тоже нормально так).
                                        0
                                        И вот тут все упирается далеко не в процессор (хотя и он нагружен тоже нормально так).

                                        Так и я о том же. Не ясно зачем нужен кластер на 10 нод (плюс сеть и балансер для них) уж лучше raid на 10 NVME.
                                          0
                                          А, если речь именно про число машин, то да. Я не так понял изначально.

                                          Одной машины (+еще одну хотя бы как можно дальше для отказоустойчивости) вполне может хватить, но тут вопрос по сложности нагрузки читающих запросов. Мы несколько лет назад пробовали эти данные на ELK положить, он не смог на ~20-40 где-то серваках. А тут справляется 1 (+1 реплика) (но там железо разное, нельзя 1к1 сравнивать в штуках).
                                    0
                                    Ну, у нас там логи не только, которые легко представить в чём-то более эффективным для парзинга, чем JSON (к примеру в CSV), а и в виде stack trace-ов, которые уже могут сделать парзинг CSV не таким уж CPU оправданным.

                                    Вообще, я в чём-то с вами согласен — мне тоже давно кажется, что logstash не сильно оптимально написан (хотя, опять же, у нас там кое-где скрипты предобработки выполняются — к примеру, для классификации страниц для просчёта SLA по их типам). Но elasitc corp пилять во всю новые версии со всякими улучшениями производительности и планы по обновлению на последние версии у нас есть.

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

                                  Самое читаемое