Comments 22
Kafka устраивает полностью, никуда от нее не хотите мигрировать?
Так ли был нужен xpack?
Спасибо за статью, часть тех же проблем пришлось пройти недавно. Vector в целом хорош, но всё равно сырой в плане долгосрочной стабильности.
Да возможно, но за последние пол года как минимум, в нашей схеме работает хорошо. В планах есть написать оператор для него на подобии https://banzaicloud.com/docs/one-eye/logging-operator/.
Добрый день! Полнотекстовый поиск вы не используете? все чаще замечаю, что те кто отказывается от ElasticSearch его не используют.
Не могли бы рассказать как тюнинговали Elastic stack?
Приветствую, используем. Здесь нужно понимать, что в отличии от эластика, где индексируется весь документ, тут происходит поиск по всему тексту сообщений и это медленнее (если данные не в кэше). Поэтому при таком поиске стараемся максимально помочь локи выполнить запрос быстрее: четче ставим временные ограничения, добавляем индексированные поля в запрос, где это возможно.
Тема тюнинга Elastic stack потянет на отдельную статью) Если есть, какие то более конкретные вопросы могу что-то подсказать.
Есть ощущение, что если вам нужен count_over_time по логам, то пора отобразить эту величину в метриках. Мы же с вами помним, что метрики это сжатые логи?
Немного смотрели, но на тот момент, vector был более знаком и закрывал потребности. Спасибо за совет, подумаем в эту сторону
плюсую на тему promtail
а еще в трассировке вместо кусков Jaeger и Vector как-то прям просится OpenTelemetry и их OTel Collector
ну и конечно же рассмотрите https://grafana.com/docs/grafana-cloud/data-configuration/agent/
они сделали из него комбайн, который может нет только логи грести, но еще и трейсы с метриками
Было бы интересно посмотреть на ваш конфиг локи, по части параметров особенно, которые тюнили :)
Как мы перешли с Elastic на Grafana stack и сократили расходы в несколько раз