Pull to refresh
77
28
Дмитрий Синявский @r3code

SRE

Send message

да. Все пишут в stdout, а вектор собирает. У нас Kubernetes, потому он сам автоматом создают файлы для stdout, а vector сам при помощи source kubernetes_logs сам забирает из них

Это замечательно. Это исповедь разработчика/программиста. Или наставление - с удовольствием давал бы это в виде клятвы джунам.

Да фичами уже не разрулишь такое, надо договариваться с разработкой - это сильно упрощает жизнь и нам и им.

Я вот сейчас не могу объективно сравнить 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.

Конечно не так удобно. Особенно если ты давно с ней работал и руки привыкли. Человеку всегда тяжело переходить на новое, надо же изучить. Но тут плюс в том, что не пришлось учить новый язык запросов, так как SQL знает большинство.
Мы вообще пошли немного дальше уже, о чем расскажем отдельно. Мы в этом году поменяли структуру хранения в базе, требования к самим логам, и сделали GUI для поиска по логам, которое упрощает поиск. Об этом расскажем несколько позже.

Опишем в отдельной статье. Пока вот можете посмотреть в видео доклада https://devopsconf.io/moscow/2024/abstracts/11564 (если доступ есть), или хотя бы в презентации (она там доступна для скачивания) с слайда 115 про Unified Log Pipeline.

У нас есть Minio, а в S3 в принципе можно прямо из Clickhouse настроить выгрузку для холодного хранилища. Пока у нас все на своих ресурсах внутри наших ЦОД.

Вот интересно как там с отладкой обработчиков логов, в vector я тесты пишу и их гоняю, как там в Loki не знаю. Возможно там другой подход

Посмотрел в вашей статье картинки, очень заинтерисовало как выделали схему по этапам трансформации сообщений. Это только картинка для статьи или у вас есть интерфейс визуализации топологии Vector? Я такой видел в демо DataDog (они купили vector и развивают), у них там видно как трансформы соединены и как идет переток событий https://youtu.be/GjcLWupY0jk?t=2990

Спасибо за ссылку - не видел этой статьи. Действительно проблема схожая.
Там они еще описывают, как изменили свою схему хранения в ClickHouse. Мы тоже отошли от начальной схемы и сейчас переходим на новую - об этом я тоже расскажу, но позже.

200 Гб в день - это верно для нашей инфраструктуры. Мы можем и 1Тб генерить, только разреши писать все от DEBUG уровня и все запросы с телом запроса )) Но нам и 200 хватает )

Уже давал коммент по поводу Loki выше. В 2018 году он был совсем зелен и не рассматривался как готовое в прод решение.

Я бы с удовольствием прочитал о вашем решении, чтобы посмотреть и сравнить. У нас используются bloom фильтры в Clickhouse, вероятно в вас тоже он?

Говоря о нашем решении мы сразу оговариваемся, что мы были ограничены в ресурсах, потому мы выбирали компромиссное решение, а не лучшее.

Команды следят за своими логами - это их сервисы и их логи, которые они знают хорошо и могут оценить их актуальность достоверно. Мы же предоставляем сервис по их сбору и хранению.

Grafana Loki + Promtail  сам появился только в апреле 2018 года и был достаточно сырой, потому был исключен из рассмотрения в нашем случае.

Что сказать, в момент выбора мы полагались на официальную документацию Vector в которой уже было описано решение с Kafka, как готовое для прод применений. Так как время дорого, а все для ее воплощения было под рукой, то мы ее и применили.

Можете поподробнее рассказать про вашу схему с балансировщиками (что за балансировщики применяли)? И что за вектор-прокси? Как в этой схеме обеспечивается защита от потери логов в моменты перезагрузки vector (например в нашем случае буфер на агенте точно не спасет, так как логов очень много)


OpenSearch не рассматривали, logstash - отказались еще до перехода на ELK, причины поросли мхом уже.  А Filebit да смотрели, но vector победил - вот тут https://medium.com/ibm-cloud/log-collectors-performance-benchmarking-8c5218a08fea можно посмотреть сравнение

У нас 3 ЦОЦ и между ними есть избыточная связанность. Надежность для нас достаточная.

Я выступил первый раз на DevOpsConf 2024 и мне понравилось, мне этого реально не хватало - обратной связи от коллег по цеху. Лично я себя чувствовал замечательно, ещё весь день после доклада был на стенде и отвечал на вопросы по докладу. Из некоторых вопросов даже по своей теме узнаешь новое, потому что не во все уголки еще слазил, как оказывается - это круто. Меня народ зарядил и взбодрил, хочу еще.

То что есть еще одна альтернатива - это отлично. Есть такие нишевые штуки, где не нужно таких огромных объемов.

банально даже в логах договориться поля назвать и то проблема бывает.

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

Также был прикол, что один программист у нас учил немецкий, он переменные по немецки и называл ) мы сначала не могли понять причем тут нач.бар, оказалось nachbar - сосед, а он так в графе соседний узел называл.

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

Оборачивать библиотеки в свои интерфейсы хорошо: 1) это лишает вас женской привязки 2) добавляет читабельности 3) позволяет спрятать ненужные нам методы.

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

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

Это про как делать не надо пример.

Нормальный проект начинает с MVP для проверки идеи, а по ее подтвержении развивают итеративно.

Сделай хорошо, а не круто.

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

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

DataDog развивает vector.dev потому что он сам его использует как фичу https://www.datadoghq.com/product/observability-pipelines/. Только она у них обмазана в красивый интерфейс.

1
23 ...

Information

Rating
211-th
Location
Россия
Date of birth
Registered
Activity

Specialization

Backend Developer, Site Reliability Engineer
Senior
SRE
Monitoring
GitLab
Golang
PostgreSQL
Redis