Comments 17
Ставим Openobserve и имеем полнотекстовый поиск по логам, otel трейсы, метрики, alert'ы если нужно, все в одном месте с Kibana-подобным, но (субьективно) более удобным интерфейсом. Мы с ним в проде уже два года и очень довольны.
upd: еще доступен real user monitoring (запись взаимодействия пользователя с интерфейсом), кому-то может быть полезно
Да, OpenObserve выглядит любопытно, особенно как универсальный инструмент, который закрывает сразу логи, трейсы и метрики. Плюс RUM — это жирный бонус, далеко не у всех он есть из коробки. Если два года в проде и все устраивает, значит, с перформансом и удобством все действительно ок.
Интересно, как он себя показывает на больших объемах логов и трейсов — стабильно работает без лишней возни?
У меня два кейса его работы в проде, в первом кейсе я храню помимо обычных логов, которые в коде писал сам, еще и сырые XML/JSON/HTML куски, каждый из которых иногда может быть по несколько мегабайт. Мне нужен полнотекстовый поиск именно внутри этих файлов. Retention стоит 30 дней, нагрузка небольшая, около 500K логов в день. Мой объем текущий укладывается в 3гб (это с учетом, что OpenObserve очень круто сжимает). Железо на fly.io машинка shared-cpu-1x@1024MB и к ней 10GB volume, занятый на треть. По нагрузке показывает среднюю 632 MB/1 GB, CPU почти всегда на нуле.
Второй кейс похожий по объему, около 300К логов в день, но retention 3 месяца и внутри тела лога очень часто большие (1-2мб) куску XML, по которым также нужен полнотекстовый поиск. Сжатый объем порядка 5гб. Полнотекстовый поиск на интервале в неделю работает < 1сек.
upd: по работе бэка openobserve без нареканий, на UI стороне иногда замечаю мелочи, но совсем небольшие
RBAC и SSO покупаете подписку или не используете?
Ставить можно, все, что душе угодно ;)
Спойлер, с выбором инструмента бекенда у людей, как правило, и нет проблем, тут выбор не особо большой вообще.
Проблемы возникают на более ранних этапах, на этапе выбора стандартов, форматов логов, формате метрик, что там модно у трейсов и прочие вопросы. А ещё не всегда все команды вообще готовы подпиливать приложения, чтобы отдавать в наиболее удобном и модном формате, виде, структуре. Сейчас благо есть Otel, если с нуля все собирать решение наблюдаемости или наводить порядок в текущем, то направление очевидно. А если вы просто льёте зоопарк в озеро разрозненных данных - тут вообще без разницы, какой у вас инструмент будет, ибо везде будет не очень обсервабилити :)
Но я это к чему вообще... ни openobserve, ни splunk, ни datadog, ни elk - не являются волшебной пилюлей, все делающей за вас, к сожалению.
А к самому openobserve вопросов нет ;)
Анализ текстовых логов вовсе не является настолько нереально сложной задачей, как автор пытается представить. Grep-ы прекрасно справляются со своей работой. И с текстовыми файлами всё-таки проще работать.
Важно не забывать, что трассировки не являются полноценной заменой performance enginering-у. Для полноценной работой над оптимизацией требуются более подходящие инструменты
Я не против грепа, конечно, но грепать вы предлагаете вручную на сотне хостов, без использования центральных хранилок? Или что вы тут подразумеваете?
Ну во первых, центральные хранилки точно также позволяют скачать логи которые можно грепать.
Во-вторых, скачать всю необходимую информацию с сотни хостов - вообще не проблема. Для этого существуют скрипты.
скачивать всю информацию даже не надо - достаточно ansible и получение результата. центральные хранилки так то тоже хранят данные не на одном хосте, их польза скорее в стандартизации процессов\инструментов когда вы большая компания
центральные хранилки точно также позволяют скачать логи которые можно грепать.
Если у вас есть центральная хранилка, то зачем вам их скачивать тогда тогда? Чтобы что?
скачать всю необходимую информацию с сотни хостов - вообще не проблема
Ну вообще это проблема. Если мы говорим про сколько-нибудь большое решение, а не hello world ( а если у нас сотня другая хостов, то это и подразумевается ), то логи могут ротироваться так быстро, что запись, сделанная сейчас, уже будет отсутствовать через пару часов, а то и раньше. Собственно, это одна из проблем, которую закрывает центральная хранилка.
Нет, ну вы, конечно, можете подкинуть на каждый из хостов бесконечный диск чисто для логов ( бесконечной скоростью чтения и записи ), а еще бесконечный сетевой канал, чтобы вытягивать эти гигабайты лог-файлов за вменяемое количество времени в моменте, а не к концу SLA в 4 часа для решения инцидента.... Я бы посмотрел.
Возвращаясь к "во-первых" - на таких объемах пользоваться грепом будет уже довольно больновато, знаете ли.
Нет, я не спорю, для 1-3 серваков проще юзать греп, и не ставить ради них отдельную центральную логохранилку, ибо это оверхед, особенно, если ELK. Но если честно, я таких уже довольно давно не видел в промышленной эксплуатации. И в посте, знаете ли, тоже не мелкая компания.
А скрипты для вытягивания это все от луковаого, кстати. Хуже вариантов я еще не слышал)
зачем вам их скачивать тогда тогда? Чтобы что
Для анализа и учёта. Как вы можете догадаться, никакой один и уникальный сервис не может обеспечить всей функциональности для полноценного анализа сложных инцидентов. Вы же не сидите в браузере часами вбивая запросы, пытаясь поймать ошибку за хвост?
Нет, ну вы, конечно, можете подкинуть на каждый из хостов бесконечный диск чисто для логов
Бесконечный диск чисто для логов не нужен. Вообще-то уровень логирования можно менять в динамике и в норме приложения не пишут гигабайты в день.
А скрипты для вытягивания это все от луковаого, кстати. Хуже вариантов я еще не слышал)
Для диагностики вытягиваются не только логи, но и другая необходимая информация: тред-дампы, конфигурация кубернетиса и прочее. И всё это делается, одной кнопкой. Это называется автоматизация. Уж не знаю, что там от лукавого....
Но если честно, я таких уже довольно давно не видел в промышленной эксплуатации
Если вы этого не видели, зачем вы про это упоминаете? Я про это тоже не писал
Статья хорошая, но вот заголовок вводит в заблуждение.
Grafana — это среда визуализации различных данных из области observability: метрик, логов, трейсов и, с относительно недавних пор, профилей нагрузки (спасибо Pyroscope'у).
Prometheus — инструмент сбора метрик (и timeseries db). То есть лишь один из компонентов observability.
Исходя их этого, можно сказать: Prometheus — это НЕ observability, а вот Grafana — вполне себе, если через неё вы смотрите на все составляющие в сборе.
Приведённые компании недружелюбно заблокировали российских пользователей в своё время. Могли бы и про российские альтернативы рассказать, например https://www.proto-observability.ru/
Вообще стоит описывать, что конкретно вы считаете за Observability, т.к. люди могут наткнуться на разные толкования и будет разлад.
В моем словаре наблюдаемость (Observability) - это возможность по конечным сигналам (телеметрия) понять состояние системы в нужный момент времени.
Если сигналов недостаточно, то приходиться догадываться/домысливать, а не по фактам выстраивать картину.
Почему observability — это не только Grafana и Prometheus