Pull to refresh
15
Karma
0
Rating
Yaroslav @YaGolub

Пользователь

  • Followers
  • Following

Собираем логи с Loki

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

Собираем логи с Loki

Я же правильно понимаю, что речь идет не о доставке логов, а именно о пересылке данных между двумя инстансами loki? Если да, то я не встречал готового решения. Технически, я думаю это возможно, у локи есть простой API c помощью которого можно вытащить данные и запихнуть их обратно. Еще, я думаю, есть вариант настроить специфическую репликацию на уровне хранилища. А зачем такое надо? Если для того чтобы иметь быстрый и легкий инстанс с коротким ретеншеном и медленный архив с неограниченным ретеншененом, то Promtail может слать логи сразу в несколько инстансов локи, плюс для Promtail можно указать размеры батча для посылки в loki

Собираем логи с Loki

К моему сожалению, мы решили не тащить это в продакшен, соответственно и выбор хранилища не стоял. Я в основном тестировал локально, используя локальный boltdb для индексов (который хранился на локальной файловой системе) и filesystem для чанков (тоже все локально). Я знаю примеры, когда данной конфигурации хватало на небольшой кластер (~10 серверов с ~140 сервисами). В этом случае переход от эластика к локи освободил целиком один сервер этого миникластера.

Собираем логи с Loki

Да, все верно, используемое хранилище от режима не зависит.

Собираем логи с Loki

Собираем логи с Loki

Да вы правы эластик можно настроить, чтобы уменьшить размеры индекса. Я в своих экспериментах уменьшал его до размера в 7.8 мегобайт на том же датасете, что и в статье, выкидывая все, что не попадает в локи в качестве лейблс. И я думаю, что это не предел. Эластик умопомрачительно гибок в этом плане. В статье же я решил привести в пример который получается «by default», без сложной настройки (просто настроив logstash), чтобы проюллюстрировать разницу подходов и не стараясь из эластика сделать локи.

Что же до сопоставимо с logstash, то у локи есть плагин для fluentd, который может выступать заменой logstash. Promtail — он да, не так гибок, никаких тебе фильтров на любимом языке.

Мы на Highload++ в этом ноябре: задай вопрос инженерам Badoo

Спасибо за вопрос!

Если я правильно понял — то суть проблемы в том, что у вас есть два несовместимых протокола, старый и новый, причем последний ломает старые клиенты? Если это так, то мы в Badoo с этим справляемся так: избегаем такого.
Либо изменения протокола должны быть такими, чтобы старые клиенты продолжали работать как ни в чем не бывало, либо старые клиенты о новом протоколе ничего знать не должны. Решается это в основном тем, что сервер новым клиентам отвечает по новому, более лучшему протоколу, а старым — по старому.

Но если у вас формат файлов общий еще с кем-то, а вы там, суровые парни, пишущие фичи комментариями в бинарных файликах, стесняетесь, то ладно вы, у нас в баду тоже в комментариях бывает чего-то только непонаписано, да такого, что детей в код не запустишь. Строго 21+.

Мы на Highload++ в этом ноябре: задай вопрос инженерам Badoo

Спасибо за вопрос!

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

Information

Rating
Does not participate
Works in
Registered
Activity