За всех (потенциальных пользователей 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 выросла очень классная инфраструктура с кучей плагинов.
Да, именно про это и статья — в дивном новом мире всё простое стало одновременно и простым и сложным. Это еще хорошо отражено у коллег из ЦИАН в статье про логи
В статье есть про это, правда вскользь — мы упоминаем, что наша схема работы с CH несколько устарела. Так же надо понимать, что Engine Buffer это не надёжное хранилище.
Не пробовали, но очень хотелось бы. Сейчас мы смотрим в сторону Jaeger + prometheus exporter к нему. Это частично закроет наши потребности к APM без установки дополнительного софта в наших кластерах. Вдохновение брали вот отсюда.
К сожалению стек ES+Kibana бывает очень требователен к ресурсам, которые у клиентов есть не всегда. Иногда дешевле платить за облако, нежели иметь self-hosted решение.
Кроме того, loghouse-acceptor не очень подходит для k8s
В нашей компании мы стараемся создать для себя базовую универсальную инфраструктуру и использовать у всех клиентов унифицированные решения. Это облегчает поддержку. Соответственно, мы хотели иметь относительно легковесную систему сбора логов для себя, которая бы покрывала наши потребности и требовала минимальных навыков от наших инженеров. Поэтому и появился loghouse.
Теперь к вопросу. Если коротко, то всё зависит от сложившейся ситуации в проекте. Проще пояснить на примерах:
Это прямо pgpool — у него есть такой режим
В нашем сетапе Clickhouse использовал 2 ядра и 2Gb, после замены на Elasticsearch начала использоваться машинка с 8 ядрами и 32Гб памяти.
И то и другое клиенты вынуждены хранить до 5 лет по своим внутренним ТЗ.
Коротенько напишу обо всех:
К сожалению стек ES+Kibana бывает очень требователен к ресурсам, которые у клиентов есть не всегда. Иногда дешевле платить за облако, нежели иметь self-hosted решение.