Comments 26
В нашей компании мы стараемся создать для себя базовую универсальную инфраструктуру и использовать у всех клиентов унифицированные решения. Это облегчает поддержку. Соответственно, мы хотели иметь относительно легковесную систему сбора логов для себя, которая бы покрывала наши потребности и требовала минимальных навыков от наших инженеров. Поэтому и появился loghouse.
Теперь к вопросу. Если коротко, то всё зависит от сложившейся ситуации в проекте. Проще пояснить на примерах:
- Клиент пришел к нас с legacy-инфраструктурой, которая умещалась в 1-2 сервера, и ему требуется развитие, чтобы его приложение соответствовало запросам бизнеса — в этом случае мы попробуем поставить loghouse и использовать его.
- Клиент собирает только ошибки и имеет обширный мониторинг. Такому клиенту логи особо и не нужны. Тут мы точно согласуем и поставим loghouse с минимальным размером диска, чтобы иметь возможность вести расследования проблем.
- Например, у клиента есть желание использовать EFK стэк или Graylog — мы не будем мешать клиенту и будем вместе с ним использовать этот стек, loghouse в кластере не будет.
- Клиент пользуется стеком от datadog, соответственно проще и логичнее подключить datadog к логам кластера при переезде в k8s, а не городить loghouse.
PS. я не критикую, сам люблю изобрести что-то изученное, но сугубо в некоммерческих целях.
Со стороны клиента (небольшого и/или тому, кому не нужен cloud agnostic): все базовые потребности по логам закрываются, с уверенным запасом. Больше гибкости по выбору (и ценам) провайдеров, т.к. можно его делать без учета таких деталей — потребность уже закрыта «на стороне», вне зависимости от фич облака (а некоторым и облако не нужно, на своем железе развернуть тоже можно… в отличие от). Плюс, если речь про обслуживание у нас — поддержка осуществляется, а на случай чего — это Open Source.
* Именно по умолчанию. Когда нужно нечто большее/специфичное, мы готовы браться и за другие варианты для логов, об этом писал выше.
TL;DR: мы не за велосипеды. Нам самим было бы лучше иметь классное Open Source-решение, поддерживаемое большим сообществом (вне Фланта) и попросту интегрированное в наши инсталляции. Но это не то, что предлагают облачные сервисы, у них всё само-в-себе.
P.S. И, конечно, всегда остается вкусовщина :-)
Расскажите зачем там вообще backend, если clickhouse имеет http интерфейс и можно засылать SQL прямо с фронта?
Это не камень в чей-то огород, просто я собирался (но скорее всего никогда не сделаю) делать такую морду для своих логов. Я понимаю, что у loghouse язык запросов по типу papertrail, но такие запросы можно и на фронте трансформировать в SQL. Остается только "сохранять запросы".
Кроме того, loghouse-acceptor не очень подходит для k8s
Daemon accepts log only in syslog RFC5424 format from rsyslog. Later may be will be added some additinal protocols support.
vectore.dev не пробовали? Хотелось бы его видеть вместо fluentd.
github.com/timberio/vector/issues/2277
придется лепить какой-нибудь workaround, если не починят
Спасибо за новую версию! Где можно найти документацию по запуску логхауса с внешним кластером кликхауса? Как-то не очень получается запустить 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]
Или лучше на гитхаб?
Привет! Так и не получается запустить чарт со стенделон кликхаусом. Отправлял вам ишью https://github.com/flant/loghouse/issues/146, но уже неделю ответа нет. Куда лучше писать?
- он не разворачивает 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
что я делаю не так?
Loghouse 0.3 — долгожданное обновление нашей системы работы с логами в Kubernetes