Pull to refresh

Comments 26

Есть ли шанс у Loghouse против (читать «в среде») cloud провайдера? GCP/AWS/Azure/AliCloud/yandex.cloud против StackDriver logs/Azure monitoring и прочее? Могут ли быть причины строит систему на нем (loghouse) и почему?
За всех (потенциальных пользователей loghouse) не скажу, т.к. продукт изначально появился как ответ на нашу внутреннюю потребность и отсутствие подходящих решений. Если кого-то устраивает завязка на конкретного провайдера — это нормальная ситуация, пусть отчасти и убивающая красоту K8s (cloud agnostic); специфика и выбор есть у каждого.
В нашей компании мы стараемся создать для себя базовую универсальную инфраструктуру и использовать у всех клиентов унифицированные решения. Это облегчает поддержку. Соответственно, мы хотели иметь относительно легковесную систему сбора логов для себя, которая бы покрывала наши потребности и требовала минимальных навыков от наших инженеров. Поэтому и появился loghouse.
Теперь к вопросу. Если коротко, то всё зависит от сложившейся ситуации в проекте. Проще пояснить на примерах:
  1. Клиент пришел к нас с legacy-инфраструктурой, которая умещалась в 1-2 сервера, и ему требуется развитие, чтобы его приложение соответствовало запросам бизнеса — в этом случае мы попробуем поставить loghouse и использовать его.
  2. Клиент собирает только ошибки и имеет обширный мониторинг. Такому клиенту логи особо и не нужны. Тут мы точно согласуем и поставим loghouse с минимальным размером диска, чтобы иметь возможность вести расследования проблем.
  3. Например, у клиента есть желание использовать EFK стэк или Graylog — мы не будем мешать клиенту и будем вместе с ним использовать этот стек, loghouse в кластере не будет.
  4. Клиент пользуется стеком от datadog, соответственно проще и логичнее подключить datadog к логам кластера при переезде в k8s, а не городить loghouse.
почему пункт 1 не мы поможем понять как перенести бизнес клиента в облачного провайдера <тут любимый провайдер>, чтобы рост/цена/что-то еще… удовлетворяли требования клиент. Права не понимаю какой смысл заниматься придумыванием велосипедов, когда уже везде есть десяток производителей «со всеми свистелками»? Не беру во внимание когда ваш клиент это NASA или госдеп или вы и ваш клиент живете на необитаемом острове?
PS. я не критикую, сам люблю изобрести что-то изученное, но сугубо в некоммерческих целях.
С нашей стороны: удобно иметь единое централизованное решение, потому что у разных клиентов разный выбор/возможности по провайдерам, а нам с ними всеми работать. Существующие решения нам не подходят (есть ответ ниже конкретно про Loki, который появился позже loghouse'а, но так не заставил нас забросить свою разработку, хотя мы в чем-то даже «надеялись» на это). Поэтому по умолчанию* предлагаем так.

Со стороны клиента (небольшого и/или тому, кому не нужен cloud agnostic): все базовые потребности по логам закрываются, с уверенным запасом. Больше гибкости по выбору (и ценам) провайдеров, т.к. можно его делать без учета таких деталей — потребность уже закрыта «на стороне», вне зависимости от фич облака (а некоторым и облако не нужно, на своем железе развернуть тоже можно… в отличие от). Плюс, если речь про обслуживание у нас — поддержка осуществляется, а на случай чего — это Open Source.

* Именно по умолчанию. Когда нужно нечто большее/специфичное, мы готовы браться и за другие варианты для логов, об этом писал выше.

TL;DR: мы не за велосипеды. Нам самим было бы лучше иметь классное Open Source-решение, поддерживаемое большим сообществом (вне Фланта) и попросту интегрированное в наши инсталляции. Но это не то, что предлагают облачные сервисы, у них всё само-в-себе.

P.S. И, конечно, всегда остается вкусовщина :-)

Расскажите зачем там вообще backend, если clickhouse имеет http интерфейс и можно засылать SQL прямо с фронта?

В loghouse есть свой язык запросов, кроме того можно делать быстрые шаблоны запросов и сохранять их в базу. Но вам никто не мешает делать SQL запросы напрямую. Вы можете использовать tabix.io, он есть в поставке loghouse.

Это не камень в чей-то огород, просто я собирался (но скорее всего никогда не сделаю) делать такую морду для своих логов. Я понимаю, что у loghouse язык запросов по типу papertrail, но такие запросы можно и на фронте трансформировать в SQL. Остается только "сохранять запросы".

Так может стоит попробовать tabix?

papertrail синтаксис аналогично хочется + drilldown в выводe

Берите loghouse-acceptor гошный вместо флюента. Правда, он новый 0.3 не поддерживает, получается.
Мы смотрим немного на другую схему, но пока не пришли к консенсусу.

Кроме того, loghouse-acceptor не очень подходит для k8s
Daemon accepts log only in syslog RFC5424 format from rsyslog. Later may be will be added some additinal protocols support.
я попробовал, есть проблема с динамическими полями, вектор своеобразно парсит json
github.com/timberio/vector/issues/2277
придется лепить какой-нибудь workaround, если не починят
Кстати, loghouse-acceptor сделан так, что работать он будет и с новой версией. Всё в этом плане замечательно.

Спасибо за новую версию! Где можно найти документацию по запуску логхауса с внешним кластером кликхауса? Как-то не очень получается запустить helm chart с clickhouse.external true.


Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [ValidationError(Endpoints.subsets[0].ports[0]): unknown field "targetPort" in io.k8s.api.core.v1.EndpointPort, ValidationError(Endpoints.subsets[0].ports[1]): unknown field "targetPort" in io.k8s.api.core.v1.EndpointPort]
helm.go:75: [debug] error validating "": error validating data: [ValidationError(Endpoints.subsets[0].ports[0]): unknown field "targetPort" in io.k8s.api.core.v1.EndpointPort, ValidationError(Endpoints.subsets[0].ports[1]): unknown field "targetPort" in io.k8s.api.core.v1.EndpointPort]

Или лучше на гитхаб?

Да, есть ошибка в объекте endpoint. Завтра сделаю hotfix chart
PR уже готов. В ближайшее время выкатим в резил.

Привет! Так и не получается запустить чарт со стенделон кликхаусом. Отправлял вам ишью https://github.com/flant/loghouse/issues/146, но уже неделю ответа нет. Куда лучше писать?

Все просто классно, но уже появился стабильные loki с promtail и все свалили на них…
Никто не спорит, что loki хорошее решение, однако нам видится у него ряд минусов:
  • он не разворачивает json, поэтому часто он не удобен для аналитики
  • наши клиенты и инженеры знают SQL и им удобно пользоваться такими инструментами как balerter
  • С появившемся внешним clickhouse можно обеспечить любую скорость работы с логами. Да, loki умеет использовать внешнее хранилище, но оно не добавит скорости.


Дело в том, что на рынке cейчас много разных решений и все они имеют право на жизнь. При этом промышленный стандарт, типо helm, еще не появился
CREATE TABLE logs
(
....
)
  ENGINE = MergeTree()
  PARTITION BY (date, toHour(timestamp))
  ORDER BY (timestamp, nsec,namespace, container_name)
  TTL date + toIntervalDay(14)
  SETTINGS index_granularity = 32768;

Почасовые партиции?
Сложно угадать сколько у вас в среднем падает логов ежедневно, но можно допустить что несколько сотен лямов в день, а с таким кол-вом можно спокойной жить и с партициями по месяцу.
Но учитывая ваш TTL подневные может вам и сойдут, но даже они далеко не всем нужны.
ORDER BY (timestamp, nsec, namespace, container_name)
Сомнительный ORDER BY, вообще по всем канонам в начало ORDER BY идут те поля, которые учавствуют в подавляющем большинстве запросов, что бы отбрасывать ненужные нам гранулы. С вашим ORDER BY так не выйдет.
timestamp и date вполне можно объединить в 1 столбец, тогда для партицирования использовать toYYYYMMDD(timestamp).
А для особенно смелых, можно использовать DateTime64, тогда и nsec можно там хранить.
Еще не видно никаких Codecs, они могут очень значительно повлиять на объем хранимых данных.
count(*)
Звездочка в count() ненужна, возможно может даже негативно влиять на скорость сканирования.

Вообще я бы в вашем случае попробовал, что то вроде
ORDER BY (namespace, container_name,timestamp, nsec)
И возможно, задал бы PRIMARY KEY покороче, допустим (namespace, container_name,timestamp)
PARTITION BY (date, toHour(timestamp))

У нас используются дневные партиции. Почасовые партиции мы тестировали, но в итоге отказались. Они есть в одном из коммитов. Спасибо, что заметили ошибку в статье.
Сложно угадать сколько у вас в среднем падает логов ежедневно, но можно допустить что несколько сотен лямов в день, а с таким кол-вом можно спокойной жить и с партициями по месяцу.

Дело в том, что мы искали вариант, который позволит бить данные на относительно не большие куски, которые, в случае чего, можно было бы легко удалить. Да и логи мы не храним месяцами. Так что разбиение по дням нас устраивает. Однако никто не мешает использовать свою кастомную схему.
ORDER BY (timestamp, nsec, namespace, container_name)

Очень часто мы ищем логи во временном промежутке в каком-то namespace. Переход на другую сортировку значительно замедлял просмотрщик логов.
Еще не видно никаких Codecs

Да, мы знаем про кодеки, однако сильная переработка схемы данных не была целью этого релиза.

Если у вас есть еще какие-то предложения — вы можете всегда их оформить issue на github.
есть несколько записей за вчера

делаю запрос по неймспейсу за последние 30 дней
GET /query?seek_to=24+hours+ago&time_from=now-30d&time_to=now&query=namespace+%3D+%22fsdf%22&per_page=&time_format=range

в кх почему-то приходит такой запрос, которые ничего не находит
SELECT *
FROM logs
WHERE (((namespace = 'fsdf')) AND (date in ('2020-08-28')) AND ((timestamp = toDateTime('2020-08-28 09:07:20') AND nsec < 893284709) OR (timestamp < toDateTime('2020-08-28 09:07:20')))) AND ((match(namespace, '.*')))
ORDER BY timestamp DESC, nsec DESC
LIMIT 250 FORMAT JSONCompact


что я делаю не так?
У нас ошибка в orm. мы готовим правки
Sign up to leave a comment.