Комментарии 47
На сколько я вижу, кафка у вас является такой жииирной точкой отказа - что делать, если она свалится?
Нужно сильно постараться, чтоб уронить многонодовый кластер кафки.
У нас 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.
Ознакомился с презентацией. Вы пишите про унификацию именований. А я подумал, что речь про использование каких-то фич ClickHouse
Да фичами уже не разрулишь такое, надо договариваться с разработкой - это сильно упрощает жизнь и нам и им.
Мы вот разделяем на уровне CH логи на debug/trace (которые храним совсем недолго) и info (которые храним годами). Ну и трейсинг поверх СH сделать удобно, так как выборки быстрые.
Правда, мы написали свой клиент для наших логов, так как у нас много своей специфики (бинарные данные, которые хочется красиво показывать и т.п.)
Интересная идея - разные сроки хранения для разных уровней лога. Возьму на заметку. У нас на проде для, большинства вообще жёсткий фильтр на игонор debug логов.
А какой смысл в логах, если нельзя посмотреть debug/trace? Они для этого и нужны )
Там вообще много разной магии возможно - от автоматического включения debug при ошибке и до возможности разметки отдельных запросов на другие уровни логирования.
Но, в среднем, для небольших проектов (сотни операций в секунду) можно и жить на debug level.
обычно в больших проектах только выше уровня error сохраняют, ведь с debug/trace затраты будут мама не горюй.
Да на маленьких можно вообще все тело запроса/ответа сохранять )
Но на больший проектах постоянно такое делать - дорого.
Я вот завидую OpenTelemetry, если код передает трейсы и доги через него, тот при семплировпнии библиотека знает, что и лог надо сохранить с ним вместе. Обычно если спмплировпние 0.001% на нагруженном сервисе на трейсы и на логи, то трейс с логом редко найдешь.
А что такое "большой проект"? По опыту, система observability занимает от 30% (если не ELK стеке) до 5% от продакшена и такие затраты вполне осмысленны, так как сильно уменьшают TCO для системы.
Хранить error достаточно странно, так как обычно этот уровень используется для "неожиданных" ошибок, требующих реакции человека и число error составляет единицы в день максимум (если больше - то нужно исправлять систему и добавлять обработку соответствующей операции).
Хранение trace/debug для отдельных особо чувствительных операций и info для всего вообще - совершенно нормальный подход для достаточно крупных систем.
Ну и подход OpenTelemetry ужасен, так как в случае падения сервиса нет никакой информации о причинах этого (библиотека отправляет логи вместе с response и в случае критических ошибок не получаешь ничего). Подход с поточным логером типа log4j гораздо лучше. А семплирование вообще нужно где-то на масштабах главной страницы Яндекса, для огромного количества проектов оно бесполезно (если, конечно, не пытаться использовать jaeger, который просто плохо хранит трейсы).
Все упирается в налисияе мощностей и прогнозов роста. Есть пределы.
5-30% - это от чего замер?
Если ресурсы не проблема, то можно вообще трафик сохранять )) Но обычно это не так и есть реальные ограничения в которые надо уложиться.
Про OpenTelemetry - что за критические такие сбои? Это мол когда у тебя приложение внезапно крашнулось? Но оно тогда ничего и не успеет написать никуда. И ничто не мешает логи библиотекой otel плевать в stdout и оттуда собирать в коллектор.
Отличный стек. У нас сейчас всё что можно/нужно на нём - ЖР, ТЖ, 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 упали на порядки.
Также оцените опыт c Vector колег из VK, они пошли немного другим путем, но схема развертывания Vector схожая
Публикации
Как ELK довел нас… до Vector.dev и Clickhouse