Комментарии 34
На сколько я вижу, кафка у вас является такой жииирной точкой отказа - что делать, если она свалится?
Нужно сильно постараться, чтоб уронить многонодовый кластер кафки.
У нас 3 ЦОЦ и между ними есть избыточная связанность. Надежность для нас достаточная.
Почему Кафка, а не балансировка между n-нодами Vector? Уже много времени прошло, но на сколько помню свои исследования, Кафка из 9 год проживал 250к строк в секунду, один вектор прожевал 50-60к строк. Поставить балансировщик и 5 вектор прокси по идее выгоднее.
P.S. мы не смогли отказаться от кибаны, т.к. потребители логов админы и дежурка, но тоже рассматривали данную схему, т.к. она более выгодна с точки зрения утилизации ресурсов . Остались на OVK(opensearch, vector, kibana)
Что сказать, в момент выбора мы полагались на официальную документацию Vector в которой уже было описано решение с Kafka, как готовое для прод применений. Так как время дорого, а все для ее воплощения было под рукой, то мы ее и применили.
Можете поподробнее рассказать про вашу схему с балансировщиками (что за балансировщики применяли)? И что за вектор-прокси? Как в этой схеме обеспечивается защита от потери логов в моменты перезагрузки vector (например в нашем случае буфер на агенте точно не спасет, так как логов очень много)
Vector-proxy - это тот же самый vector, который выполняет только проксирование трафика(у вас на схеме это Vector-агрегатор). В нашем случае используется F5 балансировщик, который распределяет трафик между N Vector-proxy. Можно вполне использовать и HA-Proxy для этих целей. Т.к. при взаимодействии между Vector -> Vector, успешно доставленным сообщение считает только при подтверждении его доставки приемником, то перезагрузка одного из N Vector-proxy не приводит к потере сообщений, т.к. не доставленное сообщение отправляется повторно по новому адресу полученному от балансировщика.
А рассматривали OpenSearch, Filebit, logstash ?
OpenSearch не рассматривали, logstash - отказались еще до перехода на ELK, причины поросли мхом уже. А Filebit да смотрели, но vector победил - вот тут https://medium.com/ibm-cloud/log-collectors-performance-benchmarking-8c5218a08fea можно посмотреть сравнение
Рассматривали ли Loki/Promtail ?
А логи проходят ревью на актуальность? Без понимания инфраструктуры остаётся лишь гадать, но выглядит будто есть значительный объем избыточных логов/мощностей для их хранения.
200 Гб логов ежедневно
Мы храним логи только за последние 5 часов
Логи продовых систем теперь хранятся 4 дня вместо 5 часов
В тексте не ошибка и логов всего 200Гб(Гигабайт) в день?
Сейчас у одного из клиентов с 1Тб (Терабайт) логов в день отлично справляется 2 кластера (dev + prod) Loki в simple scalable конфигурации с хранением в S3 и логи хранятся за сколько угодно давно, т.к. S3 относительно дёшев и логи более чем за год нужны для compliance и т.п. Впрочем и на дисках используя Minio тоже будет не так дорого и достаточно производительно и поддерживается Loki из коробки. И даже Kafka не используется, хотя в теории не помешает. И это на версии 2.9, а сейчас 3.0 вышла с bloom фильтрами, которые на 70-90% должны снизить объём скачиваемых при поисковых запросах логов.
Метрики в двух VictoriaMetrics cluster.
По-моему на 1Tb/день логов в день, даже без аналогичных требований по длительности хранения, ваше решение сильно проигрывает по стоимости и сложности архитектуры и необходимости её поддерживать.
Но снизить стоимость решения в 10 раз - это отличное достижение, поздравляю!
200 Гб в день - это верно для нашей инфраструктуры. Мы можем и 1Тб генерить, только разреши писать все от DEBUG уровня и все запросы с телом запроса )) Но нам и 200 хватает )
Уже давал коммент по поводу Loki выше. В 2018 году он был совсем зелен и не рассматривался как готовое в прод решение.
Я бы с удовольствием прочитал о вашем решении, чтобы посмотреть и сравнить. У нас используются bloom фильтры в Clickhouse, вероятно в вас тоже он?
Говоря о нашем решении мы сразу оговариваемся, что мы были ограничены в ресурсах, потому мы выбирали компромиссное решение, а не лучшее.
Говоря bloom фильтры я имел ввиду то, что реализовала команда Loki https://grafana.com/blog/2024/04/09/grafana-loki-3.0-release-all-the-new-features/, как это реализовано в Clickhouse хз
Мы не ограничиваем разработку в том, что им необходимо.
Наше решение - это несколько EKS кластеров + 2 Loki кластера simple scalable + promtail из того же helm chart'а + AWS S3, но у других облачных провайдеров тоже можно использовать block storage. Да и на дисках на Minio я бы тоже рассмотрел, я уже говорил.
С учётом даты 2018 вашего внедрения обсуждать сравнение с Loki действительно несколько бессмысленно, т.к. для меня он стал Production ready только недавно.
Но сейчас Loki - это решение которое наиболее дешёвое и функциональное, никаких компромиссов.
У нас есть Minio, а в S3 в принципе можно прямо из Clickhouse настроить выгрузку для холодного хранилища. Пока у нас все на своих ресурсах внутри наших ЦОД.
Вот интересно как там с отладкой обработчиков логов, в vector я тесты пишу и их гоняю, как там в Loki не знаю. Возможно там другой подход
Нам холодное хранилище как бы не нужно, т.к. всё и так в s3. Можно отправлять совсем старые логи в glacier, но там есть нюансы и пока не воспользовались.
Логи в Loki умеет и Vector писать, у них есть sink ссылка , но у нас как-то сходу все форматы и всё остальное практически вообще без настроек взлетели из дефолтного helm subchart promtail и по производительности он устраивает, поэтому им пользуемся.
Promtail можно гонять локально со всеми тестами, как и любой другой парсер логов. Сам loki не умничает и отказоустойчиво гонит данные без парсинга в хранилище а затем работает по принципу распределённого grep. За счёт параллелизации можно получить чумовые скорости и всё это при одной копии сохранённых данных. Ну и связка grafana loki + grafana tempo + grafana чертовски удобна как единая точка доступа ко всем артефактам наблюдаемости и перехода между логами и трейсами.
Я вот сейчас не могу объективно сравнить Vector и Loki. Решение по вектору мы принимали тогда в 2018 и в тех условиях.
Поискал сегодня, делал ли кто-то подобный переход с ELK на Loki. Попалась схожая с моей статья 2022 года - "Как мы перешли с Elastic на Grafana stack и сократили расходы в несколько раз" https://habr.com/ru/companies/m2tech/articles/693504/
и вторая What I like using Grafana Loki for (and where I avoid it) https://utcc.utoronto.ca/~cks/space/blog/sysadmin/GrafanaLokiWhatILikeItFor
Будет интересно почитать и сравнить. Будет база для выбора решения коллегам.
Еще такая штука как https://github.com/metrico/qryn (ранее cLoki) позиционируют как Loki + Clickhouse. Вот оно мне кажется более похожим на наш сетап. И возможно если бы оно существовало в 2018 в готовом к прод виде, то могло бы подойти, но qryn начал развиваться только с декабря 2018.
Перекликается с https://www.uber.com/blog/logging/
Спасибо за ссылку - не видел этой статьи. Действительно проблема схожая.
Там они еще описывают, как изменили свою схему хранения в ClickHouse. Мы тоже отошли от начальной схемы и сейчас переходим на новую - об этом я тоже расскажу, но позже.
Очень прошу поделиться данной информацией. У нас объём данных ещё маленький, и будет полезен другой опыт для развития!
Опишем в отдельной статье. Пока вот можете посмотреть в видео доклада https://devopsconf.io/moscow/2024/abstracts/11564 (если доступ есть), или хотя бы в презентации (она там доступна для скачивания) с слайда 115 про Unified Log Pipeline.
Отличный стек. У нас сейчас всё что можно/нужно на нём - ЖР, ТЖ, RAS 1С, логи кролика, логи web, даже логи windows напрямую и т.д. А ошибки сразу экспортируем в Sentry, с моей точки зрения отличнейший баг-трекер. На инфостарте несколько статей публиковал, но народ в комментариях молчит https://infostart.ru/1c/tools/1973657/
Посмотрел в вашей статье картинки, очень заинтерисовало как выделали схему по этапам трансформации сообщений. Это только картинка для статьи или у вас есть интерфейс визуализации топологии Vector? Я такой видел в демо DataDog (они купили vector и развивают), у них там видно как трансформы соединены и как идет переток событий https://youtu.be/GjcLWupY0jk?t=2990
За статью спасибо! Но как теперь разработчикам работается без кибаны? Удобно ли им юзать кликхаус?
Конечно не так удобно. Особенно если ты давно с ней работал и руки привыкли. Человеку всегда тяжело переходить на новое, надо же изучить. Но тут плюс в том, что не пришлось учить новый язык запросов, так как SQL знает большинство.
Мы вообще пошли немного дальше уже, о чем расскажем отдельно. Мы в этом году поменяли структуру хранения в базе, требования к самим логам, и сделали GUI для поиска по логам, которое упрощает поиск. Об этом расскажем несколько позже.
Как приложения взаимодействуют с Vector. Пишут логи в stdout или напрямую в вектор?
Прекрасная схема - перешли на похожую с opensearch. (70GB в день поступающих логов)
Имеем:
- vector в точках сбора логов
- кластер RabbitMQ (кафку решили не задействовать)
- vector-агрегатор (он же отбрасывает в старую систему логов пакеты - для тех кто еще не перешел и по старинке там живет)
- clickhouse
- metabase с LDAP авторизацией в домене для просмотра - позволяет строить данные перетаскиванием мышки, при необходимости переходить на sql.
Объемы хранения при сжатии LZ4 упали на порядки.
Как ELK довел нас… до Vector.dev и Clickhouse