Pull to refresh

Comments 15

Сравнение эффективности сжатия, которое вы приводите, не имеет веса без демонстрации шаблона индекса, в который эластик складывает данные. Если у вас каждый ключ индексируется в два поля (text и keyword), тогда не удивительно, что данные занимают больше места.

От эластика можно легко добиться того же (или очень близкого) результата, если выносить смысловую часть записи в ключ с типом text, а остальное индексировать только как keyword.

А Локи предлагает что-то сопоставимое с функционалом Logstash? Если да, было бы интересно опробовать.
Увы, порой встречается такое, что можно провалиться в regex hell, и спасает только фильтр на ruby…
Да вы правы эластик можно настроить, чтобы уменьшить размеры индекса. Я в своих экспериментах уменьшал его до размера в 7.8 мегобайт на том же датасете, что и в статье, выкидывая все, что не попадает в локи в качестве лейблс. И я думаю, что это не предел. Эластик умопомрачительно гибок в этом плане. В статье же я решил привести в пример который получается «by default», без сложной настройки (просто настроив logstash), чтобы проюллюстрировать разницу подходов и не стараясь из эластика сделать локи.

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

интересная статья, спасибо


Loki может быть как в одиночном режиме (single binary mode), так и в шардируемом (horizontally-scalable mode). Во втором случае он может сохранять данные в облако

В первом случае тоже. Я деплою Loki из их helm чарта и там single binary mode — единственный способ деплоя на данный момент. При этом чанки хранятся в GCS.

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

А что вы выбрали в итоге для хранения индексов и чанков? Если для чанков s3 — то свое?

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

Ясно. У нас логов раз в 10 меньше, но с ELK переодически какие-то проблемы, видимо не умеем мы его. По-этому решили пробовать связку ELK для оперативного окна в несколько дней + Loki уже для архива.

Может ли Loki работать как прокси локально, выполняя роль лог коллектора, аггрегируя логи приложения на машине и пересылая пачками потом на сервер с логами?
Я же правильно понимаю, что речь идет не о доставке логов, а именно о пересылке данных между двумя инстансами loki? Если да, то я не встречал готового решения. Технически, я думаю это возможно, у локи есть простой API c помощью которого можно вытащить данные и запихнуть их обратно. Еще, я думаю, есть вариант настроить специфическую репликацию на уровне хранилища. А зачем такое надо? Если для того чтобы иметь быстрый и легкий инстанс с коротким ретеншеном и медленный архив с неограниченным ретеншененом, то Promtail может слать логи сразу в несколько инстансов локи, плюс для Promtail можно указать размеры батча для посылки в loki
Аналог fluentd/logstash/telegraf, чтобы локально на каждый сервер поставить его и быстро писать в него логи минуя сеть, а он уже пачками отсылает в loki сервер удаленный
Да мы его широко используем. В том числе и для логов, например, когда нам нужно фиксировать историю изменения состояний каких нибудь сущностей. Данные в этом случае жестко структуированы, мы точно знаем, что мы будем хранить, как будем искать, поэтому clickhouse хорошо подходит. В отличие от локи, чей подход гласит, что структура логов вам не важна, если вам нужно просто погрепать данные.
Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
2006
Location
Россия
Website
badoo.com
Employees
501–1,000 employees
Registered
Representative
Alina Romanova

Habr blog