Comments 11
Спасибо за статью. Можно ли как то управлять временем хранения логов?
Здравствуйте! Для управления временем хранения логов отвечает компактор. Вот тут подробная документация на эту тему - https://grafana.com/docs/loki/latest/operations/storage/retention
Наверное надо уточнить что для SSD нужно /loki/api/v1/push проксировать на write ноды. Всё остальное на read.
По поводу retention. Я настроил lifecycle policy на AWS S3 так как я могу его там настроить в зависимости от tenant. Это мне чем то грозит? Кроме запросов в никуда?
Loki поддерживает 2 вида ретеншена - через table manager и через компактор. Ретеншн через table manager полагается на lifecycle policy в S3. Поэтому это обязательно (но при условии что включен непосресдтвенно ретеншн через table_manager). Это нужно для того, чтобы правильно очищались индексы. Иначе Loki может считать что чанки есть (потому что индекс на них ссылается), а по факту их нет - и может выливаться в ошибки при запросах.
Более гибким является настройка ретеншена через компактор - она так же позволяет настраивать его для отдельных тенантов. При этом выставлять в таком случае какие-либо полиси в бакете лучше не стоит - точно так же - чревато потерей данных. Поэтому, если честно, я не вижу причин не использовать ретеншн через компактор.
Резюмируя, настраивать ретеншн нужно через один из двух механизмов - table manager или compactor. При этом для первого нужны lifecycle policy в S3 бакете. Полиси без настройки ретеншена могут привести к ошибкам в запросах.
Задача сбора логов
Каждая система, будь то syslog, Elasticsearch, или системы, которые построены на ClickHouse — даже сама Grafana Loki — отвечают на эти вопросы по-разному.
А вы точно настоящий строитель? syslog - стандарт для передачи, обработки и хранения логов, Elasticsearch - поисковый движок(слово search в названии не смущает?) ClickHouse -DBMS, Loki - агрегатор.
Дальше статью не читал.
Чем лучше принимать с "железок" сообщения syslog (UDP/514) с целью положить их в Loki ?
Да, это больше, чем нужно. Проблему можно решить через дедупликацию данных. Для этого есть компонент-компактор. Работает так:
Вот эта часть вызывает вопросы, в документации не нашел примеров
Так же наткнулся на коммент в issue
The compactor (as of the time of this message) does not touch chunks at all and does no de-duplication.
Правда в несколько другом контексте дедупликации
Вопрос
Дистрибьютор отправляет чанки сразу в несколько инджесторов. Теперь в storage будет храниться в три раза больше данных
Это действительно так?
Есть ли пример конфига с которым эта проблема решается через compactor?
Спасибо большое за ваш комментарий!
Действительно, после глубокого изучения признаю, что тут была отражена не совсем корректная информация. В самом деле, компактор не занимается дедупликацией данных в S3. Этим занимаются сами инджестеры с использованием кешей (https://grafana.com/docs/loki/latest/operations/storage/boltdb-shipper/#write-deduplication-disabled).
Судя по всему данные действительно пишутся в нескольких копиях в S3 и дедуплицириуются уже только на квериерах - ссылка1 и ссылка2, сравнивая таймстемпы и тексты логов.
В статью также внес изменения. Еще раз спсаибо за замечание!
P.S. Прошу прощения, что только сейчас отвечаю — пропустил изначально.
Тонкости настройки Grafana Loki