Комментарии 16
Сравнение эффективности сжатия, которое вы приводите, не имеет веса без демонстрации шаблона индекса, в который эластик складывает данные. Если у вас каждый ключ индексируется в два поля (text и keyword), тогда не удивительно, что данные занимают больше места.
От эластика можно легко добиться того же (или очень близкого) результата, если выносить смысловую часть записи в ключ с типом text, а остальное индексировать только как keyword.
А Локи предлагает что-то сопоставимое с функционалом Logstash? Если да, было бы интересно опробовать.
Увы, порой встречается такое, что можно провалиться в regex hell, и спасает только фильтр на ruby…
От эластика можно легко добиться того же (или очень близкого) результата, если выносить смысловую часть записи в ключ с типом text, а остальное индексировать только как keyword.
А Локи предлагает что-то сопоставимое с функционалом Logstash? Если да, было бы интересно опробовать.
Увы, порой встречается такое, что можно провалиться в regex hell, и спасает только фильтр на ruby…
Да вы правы эластик можно настроить, чтобы уменьшить размеры индекса. Я в своих экспериментах уменьшал его до размера в 7.8 мегобайт на том же датасете, что и в статье, выкидывая все, что не попадает в локи в качестве лейблс. И я думаю, что это не предел. Эластик умопомрачительно гибок в этом плане. В статье же я решил привести в пример который получается «by default», без сложной настройки (просто настроив logstash), чтобы проюллюстрировать разницу подходов и не стараясь из эластика сделать локи.
Что же до сопоставимо с logstash, то у локи есть плагин для fluentd, который может выступать заменой logstash. Promtail — он да, не так гибок, никаких тебе фильтров на любимом языке.
Что же до сопоставимо с logstash, то у локи есть плагин для fluentd, который может выступать заменой logstash. Promtail — он да, не так гибок, никаких тебе фильтров на любимом языке.
интересная статья, спасибо
Loki может быть как в одиночном режиме (single binary mode), так и в шардируемом (horizontally-scalable mode). Во втором случае он может сохранять данные в облако
В первом случае тоже. Я деплою Loki из их helm чарта и там single binary mode — единственный способ деплоя на данный момент. При этом чанки хранятся в GCS.
del
Loki весьма не плох, но сравнивать его с где моя память чувак ELK не совсем корректно, это же почти кровавый энтерпрайз. По стоимости владения и размеру индекса ближе к clickhouse, хотя в нем и нет таких плюшек как интеграция с grafana из коробки, зато почти настоящий SQL.
Есть clickhouse plugin для графаны, а также кликхаус поддерживает mysql протокол.
Пользуюсь и тем и другим.
Пользуюсь и тем и другим.
А что вы выбрали в итоге для хранения индексов и чанков? Если для чанков s3 — то свое?
К моему сожалению, мы решили не тащить это в продакшен, соответственно и выбор хранилища не стоял. Я в основном тестировал локально, используя локальный boltdb для индексов (который хранился на локальной файловой системе) и filesystem для чанков (тоже все локально). Я знаю примеры, когда данной конфигурации хватало на небольшой кластер (~10 серверов с ~140 сервисами). В этом случае переход от эластика к локи освободил целиком один сервер этого миникластера.
Может ли Loki работать как прокси локально, выполняя роль лог коллектора, аггрегируя логи приложения на машине и пересылая пачками потом на сервер с логами?
Я же правильно понимаю, что речь идет не о доставке логов, а именно о пересылке данных между двумя инстансами loki? Если да, то я не встречал готового решения. Технически, я думаю это возможно, у локи есть простой API c помощью которого можно вытащить данные и запихнуть их обратно. Еще, я думаю, есть вариант настроить специфическую репликацию на уровне хранилища. А зачем такое надо? Если для того чтобы иметь быстрый и легкий инстанс с коротким ретеншеном и медленный архив с неограниченным ретеншененом, то Promtail может слать логи сразу в несколько инстансов локи, плюс для Promtail можно указать размеры батча для посылки в loki
Спасибо за пост. Смотрел ли вы в сторону Clickhouse?
Да мы его широко используем. В том числе и для логов, например, когда нам нужно фиксировать историю изменения состояний каких нибудь сущностей. Данные в этом случае жестко структуированы, мы точно знаем, что мы будем хранить, как будем искать, поэтому clickhouse хорошо подходит. В отличие от локи, чей подход гласит, что структура логов вам не важна, если вам нужно просто погрепать данные.
Обновление журнала в лучшем случае 10с, уменьшение частоты в графане не дает эффекта, проблема в loki. Невозможно смотреть логи реал-тайм, ну или хотябы с 1с интервалом
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Собираем логи с Loki