Никто не спорит, что loki хорошее решение, однако нам видится у него ряд минусов:
он не разворачивает json, поэтому часто он не удобен для аналитики
наши клиенты и инженеры знают SQL и им удобно пользоваться такими инструментами как balerter
С появившемся внешним clickhouse можно обеспечить любую скорость работы с логами. Да, loki умеет использовать внешнее хранилище, но оно не добавит скорости.
Дело в том, что на рынке cейчас много разных решений и все они имеют право на жизнь. При этом промышленный стандарт, типо helm, еще не появился
У нас используются дневные партиции. Почасовые партиции мы тестировали, но в итоге отказались. Они есть в одном из коммитов. Спасибо, что заметили ошибку в статье.
Сложно угадать сколько у вас в среднем падает логов ежедневно, но можно допустить что несколько сотен лямов в день, а с таким кол-вом можно спокойной жить и с партициями по месяцу.
Дело в том, что мы искали вариант, который позволит бить данные на относительно не большие куски, которые, в случае чего, можно было бы легко удалить. Да и логи мы не храним месяцами. Так что разбиение по дням нас устраивает. Однако никто не мешает использовать свою кастомную схему.
ORDER BY (timestamp, nsec, namespace, container_name)
Очень часто мы ищем логи во временном промежутке в каком-то namespace. Переход на другую сортировку значительно замедлял просмотрщик логов.
Еще не видно никаких Codecs
Да, мы знаем про кодеки, однако сильная переработка схемы данных не была целью этого релиза.
Если у вас есть еще какие-то предложения — вы можете всегда их оформить issue на github.
За всех (потенциальных пользователей loghouse) не скажу, т.к. продукт изначально появился как ответ на нашу внутреннюю потребность и отсутствие подходящих решений. Если кого-то устраивает завязка на конкретного провайдера — это нормальная ситуация, пусть отчасти и убивающая красоту K8s (cloud agnostic); специфика и выбор есть у каждого.
В нашей компании мы стараемся создать для себя базовую универсальную инфраструктуру и использовать у всех клиентов унифицированные решения. Это облегчает поддержку. Соответственно, мы хотели иметь относительно легковесную систему сбора логов для себя, которая бы покрывала наши потребности и требовала минимальных навыков от наших инженеров. Поэтому и появился loghouse.
Теперь к вопросу. Если коротко, то всё зависит от сложившейся ситуации в проекте. Проще пояснить на примерах:
Клиент пришел к нас с legacy-инфраструктурой, которая умещалась в 1-2 сервера, и ему требуется развитие, чтобы его приложение соответствовало запросам бизнеса — в этом случае мы попробуем поставить loghouse и использовать его.
Клиент собирает только ошибки и имеет обширный мониторинг. Такому клиенту логи особо и не нужны. Тут мы точно согласуем и поставим loghouse с минимальным размером диска, чтобы иметь возможность вести расследования проблем.
Например, у клиента есть желание использовать EFK стэк или Graylog — мы не будем мешать клиенту и будем вместе с ним использовать этот стек, loghouse в кластере не будет.
Клиент пользуется стеком от datadog, соответственно проще и логичнее подключить datadog к логам кластера при переезде в k8s, а не городить loghouse.
В loghouse есть свой язык запросов, кроме того можно делать быстрые шаблоны запросов и сохранять их в базу. Но вам никто не мешает делать SQL запросы напрямую. Вы можете использовать tabix.io, он есть в поставке loghouse.
Почему не сделать не всякие высокоинтеллектуальные патрони, а простой аля хапрокси, который на запись шлет двум одновременно, а читает к примеру поочереди от нагрузки?
В используемых нами системах нет централизованного коллектора, который выступал бы фильтром или аккумулятором логов. Все преобразования происходят на fluentd, за исключением EFK-стека — там вложенный json разбирает сам Elasticsearch.
На самом деле особых проблем с тем, что именно разбирает система логгировнаия, нет. Говоря об удобстве логов в json-формате, когда одно событие явялется одним json, мы подразумеваем, что такие логи будут автоматически разобраны loghouse или EFK и, в дальнейшем, можно будет удобно составлять аналитические запросы по полям этих логов, строить диаграммы и не использовать регулярные выражения, так как все критичные данные будут определены соответствующими полями json-лога.
Тут очень много вариантов. Например, можно ошибки выводить в stderr, не ломая stdout. Можно даже больше — настроить, например, sentry, так как почти любой язык программирования умеет навешивать глобальную функцию для исключений и проблемы с тем, что в потоках ввода-вывода будет каша опять таки отпадёт.
Сравнивали. Clickhouse выигрывал в этом плане. Он очень быстрый и легко расширяется горизонтально. Но с другой стороны, вокруг Elasticsearch выросла очень классная инфраструктура с кучей плагинов.
Дело в том, что на рынке cейчас много разных решений и все они имеют право на жизнь. При этом промышленный стандарт, типо helm, еще не появился
У нас используются дневные партиции. Почасовые партиции мы тестировали, но в итоге отказались. Они есть в одном из коммитов. Спасибо, что заметили ошибку в статье.
Дело в том, что мы искали вариант, который позволит бить данные на относительно не большие куски, которые, в случае чего, можно было бы легко удалить. Да и логи мы не храним месяцами. Так что разбиение по дням нас устраивает. Однако никто не мешает использовать свою кастомную схему.
Очень часто мы ищем логи во временном промежутке в каком-то namespace. Переход на другую сортировку значительно замедлял просмотрщик логов.
Да, мы знаем про кодеки, однако сильная переработка схемы данных не была целью этого релиза.
Если у вас есть еще какие-то предложения — вы можете всегда их оформить issue на github.
Кроме того, loghouse-acceptor не очень подходит для k8s
В нашей компании мы стараемся создать для себя базовую универсальную инфраструктуру и использовать у всех клиентов унифицированные решения. Это облегчает поддержку. Соответственно, мы хотели иметь относительно легковесную систему сбора логов для себя, которая бы покрывала наши потребности и требовала минимальных навыков от наших инженеров. Поэтому и появился loghouse.
Теперь к вопросу. Если коротко, то всё зависит от сложившейся ситуации в проекте. Проще пояснить на примерах:
Это прямо pgpool — у него есть такой режим
В нашем сетапе Clickhouse использовал 2 ядра и 2Gb, после замены на Elasticsearch начала использоваться машинка с 8 ядрами и 32Гб памяти.