Comments 32
Кровавой редактурой Хабра из статьи были изъяты смайлики, ссылаясь на эту статью, поэтому привожу их тут:
:)
:)
Лично я бы без готового readme и тестов проект пока не показывал бы) но это я)
Нет главного — как быстро установить себе и проверить. Ну там brew для MacOS и тому подобное
Я этот интерфейс набросал как прототип, или как идею, если кто-то действительно захочет его реализовать :). Если бы я к этому проекту подходил так серьезно, как Вы предлагаете, то, боюсь, статья никогда не была бы опубликована.
Я написал небольшой README :). Установка очень простая, если у Вас установлен go — go get github.com/YuriyNasretdinov/logscli и дальше используете бинарник logscli, указав нужные параметры для ClickHouse (правда, имена колонок для time и millis не настраиваются).
А если скрестить это дело с моим мониторингом вообще будет красота наверное
https://m.habr.com/ru/post/454674/
Совет владельцам бизнеса — сразу гнать надо таких советчиков, как ZhelezoDev, которые используют слова "бездельники" и "гнать таких сразу".
Я согласен, что пока логи спокойно помещаются на одну машину и можно использовать обычный tail/grep/less для их просмотра, ничего больше и не требуется, и это справедливо примерно для 90-95% компаний.
Оставшиеся же компании достаточно большие, чтобы вложение некоторого количества усилий в систему сбора и просмотра логов было бы экономически оправдано, поскольку хорошая система логирования позволяет быстрее устранять и предотвращать инциденты, а простои для большого сервиса обычно очень дороги.
Я видимо как-то «выпал» из мэйнстрима.
А сейчас уже не модно во всякие там Elasticsearch или Loki?
Да почему не модно? Модно. Хороший ли выбор Elastic — не уверен (ибо он требует на порядок больше ресурсов по сравнению с ClickHouse при записи одинакового потока логов, но чтение у него быстрее, конечно же). Loki, кажется, больше похож на ClickHouse в плане того, как он хранит логи, поэтому, вероятно, характеристики в плане чтения/записи у него будут похожи. Но я лично Loki не использовал, в отличие от ClickHouse и ElasticSearch, поэтому рекомендовать ничего не могу.
Я согласен, что пока логи спокойно помещаются на одну машину и можно использовать обычный tail/grep/less для их просмотра, ничего больше и не требуется, и это справедливо примерно для 90-95% компаний.
Ты невнимательно прочитал комментарий, в нем речь не о хранилище логов, а о просмотрщике.
Если логи лежат в Кликхаусе, то чем твое решение лучше чем стандартный cli-клиент Кликхауса? У последнего как минимум следующие преимущества:
1. нулевая цена разработки и поддержки,
2. поддержка любых схем, а не только той, что захардкожена в твоем приложении,
3. поддержка любых типов запросов, а не только тех, что предусмотрены твоим прложением.
Хочешь сгруппировать логи веб-сервера по коду ответа? Пожалуйста. Хочешь сгруппировать ошибки по типу и посмотреть какие новые ошибки появились с момента последнего релиза? Не вопрос. Хочешь еще каким-то хитрым способом повертеть данными? Все это доступно через стандартный клиент Кликхауса и этого нет logscli.
Если рассматривать это приложение как хеллоу ворлд, написанный, чтобы поизучать го и Кликхаус, то это ок, но это точно не решение для продакшена.
Ты невнимательно прочитал комментарий, в нем речь не о хранилище логов, а о просмотрщике.
Я ответил и про хранение и про просмотр. Если логов не очень много, то и необходимости их складывать в ClickHouse/Elastic и прочие особой не должно быть, ибо мне кажется, что стандартные утилиты awk/grep/tail и прочие тоже хорошо справляются с задачей просмотра текстовых логов.
Если логи лежат в Кликхаусе, то чем твое решение лучше чем стандартный cli-клиент Кликхауса? У последнего как минимум следующие преимущества:
Мой клиент не является заменой для cli-интерфейса самого ClickHouse. Также как grep не заменяет python: искать подстроку, соответствующую регулярному выражению, удобнее с помощью grep, хотя на Python это тоже делается в 3 строчки.
- поддержка любых схем, а не только той, что захардкожена в твоем приложении,
Моё приложение требует только того, чтобы в таблице присутствовали колонки со временем и (крайне желательно) использовался первичный ключ с сортировкой по времени. Все остальные вещи можно задать параметрами.
- поддержка любых типов запросов, а не только тех, что предусмотрены твоим прложением.
Опять же, такой задачи не ставилось. Мой просмотрщик не является заменой SQL-интерфейсу ClickHouse, и, как Вы упомянули, он уже существует и замена ему не требуется.
Он заточен под ровно одну задачу — быстро и удобно показать текстовые логи и позволяет их легко и быстро фильтровать.
Он также умеет то, что достаточно сложно сделать одним запросом в ClickHouse, например он умеет показывать контекст вокруг совпадений.
Эти два кейса, по моему опыту, покрывают ~90% потребностей при анализе логов и при отладке.
Хочешь сгруппировать логи веб-сервера по коду ответа? Пожалуйста. Хочешь сгруппировать ошибки по типу и посмотреть какие новые ошибки появились с момента последнего релиза? Не вопрос. Хочешь еще каким-то хитрым способом повертеть данными? Все это доступно через стандартный клиент Кликхауса и этого нет logscli.
Вы смешиваете два разных сценария:
- Просмотреть слабо структурированный текст ошибок (или отладочных сообщений), и контекст вокруг них
- Посчитать аналитику по этим данным.
ClickHouse хорошо справляется с обеими задачами, и для второго сценария лучше, чем SQL, придумать сложно. При этом, для той задачи, которую я описываю в статье (например, как я уже говорил, показ контекста вокруг сообщения, или просто фильтрация по фиксированной строке или по регулярному выражению), использовать clickhouse-client напрямую не слишком удобно, хотя и, безусловно, возможно, и в некоторых ситуациях даже необходимо.
Если рассматривать это приложение как хеллоу ворлд, написанный, чтобы поизучать го и Кликхаус, то это ок, но это точно не решение для продакшена.
Я готов выслушать Ваши аргументы (не основанных на личных оскорблениях), чем моё решение плохо подходит для продакшена. Также, поскольку она целиком помещается в 350 строк, её можно легко адаптировать под собственные нужды (и, более того, именно такой сценарий использования я и предполагаю, поскольку, как Вы отметили, у всех немного разные требования и структура данных, так что полностью универсальное решение будет, вероятно, не удобнее в использовании, чем сырой clickhouse-client за счёт того, что Вам нужно будет указывать слишком много параметров).
Вы сами себе противоречите. Трудно представить, что логи не помещаются на одну машину, но их так мало, что не целесообразно использовать ClickHouse/Elastic.
Как сказали выше как pet-проект хорошая статья, но для продакшна есть другие инструменты
Также как grep не заменяет python
Некорректно сравнивать консольную утилиту с языком программирования. А вот сравнить две консольных утилиты (clickhouse-client и logscli) можно.
Моё приложение требует только того, чтобы в таблице присутствовали колонки со временем и
Все равно это ограничение, которого нет в clickhouse-client и поэтому мне непонятно зачем нужно использовать программу с такой урезанной функциональностью.
Он заточен под ровно одну задачу — быстро и удобно показать текстовые логи и позволяет их легко и быстро фильтровать.
Можно вот так:
clickhouse-client -q "SELECT * FROM table WHERE column LIKE '%some-search-string%'"Вроде тоже быстро и удобно. И гораздо гибче.
Он также умеет то, что достаточно сложно сделать одним запросом в ClickHouse, например он умеет показывать контекст вокруг совпадений.
Судя по описанию программа ведь просто достает несколько строк вокруг текущей. Это решение приносит мало пользы. Если в лог пишет много потоков, то вокруг строки с ошибкой могут оказаться записи совершенно несвязанные с текущей строкой. В таком случае лучше писать во все логи параметр типа trace_id, затем найти сначала строку с ошибкой, а потом все записи с тем же trace_id.
Вы смешиваете два разных сценария
Нет.
При этом, для той задачи, которую я описываю в статье (например, как я уже говорил, показ контекста вокруг сообщения, или просто фильтрация по фиксированной строке или по регулярному выражению), использовать clickhouse-client напрямую не слишком удобно
Тоже нет. Я уже написал выше, что контекст в таком виде не добавит полезной информации.
Отвечу только на хоть какого-то рода конструктивную критику, а именно:
Судя по описанию программа ведь просто достает несколько строк вокруг текущей. Это решение приносит мало пользы. Если в лог пишет много потоков, то вокруг строки с ошибкой могут оказаться записи совершенно несвязанные с текущей строкой. В таком случае лучше писать во все логи параметр типа trace_id, затем найти сначала строку с ошибкой, а потом все записи с тем же trace_id.
Согласен, контекст вокруг конкретного потока может быть полезнее контекста, в котором все строки идут вперемежку.
Глобальный контекст (то есть в котором логи со всех потоков идут в кучу) тоже может быть полезен, если Вы отлаживаете проблему не с конкретным запросом, а, к примеру, хотите посмотреть, не случалось ли похожей проблемы в то же время на других серверах, к примеру.
В целом, ничего не мешает добавить возможность печати контекста для какого-то конкретного поля (тот же trace_id, что Вы упомянули, или, например, контекст только с того же сервера или чего-либо ещё), спасибо за идею.
О чем Вы говорите? Платформенные и продуктовые задачи не «лучше» одна другой, они совершенно о разном и начиная с определенного масштаба полезно заниматься и тем и другим, иначе Ваша инфраструктура превратится в болото, где, когда что-то идет не так, требуется очень много времени на то, чтобы разобраться, что вообще происходит. Конечно, лучше поначалу использовать как можно более стандартные инструменты, но начиная с некоторого масштаба многие из них перестают эффективно работать, и тогда экономически целесообразно (а Вы ведь за это топите, аргументируя, что этим заниматься вообще не нужно?) становится потратить некоторые количество усилий разработки на то, чтобы улучшать инфраструктуру.
clickhouse.tech/docs/en/engines/table-engines/mergetree-family/mergetree/#available-types-of-indices
Честно говоря, позабыл, что в ClickHouse завезли такие индексы, поэтому не пробовал так делать :). Спасибо за то, что обратили на это внимание. Если Вы их использовали и у Вас есть пример настроек, которые хорошо работают для логов, приведите их пожалуйста.
Вы заинтриговали, безусловно, но, сказать честно, результаты меня лично пока не особо впечатлили :). Я попробовал добавить следующие индексы (размер данных для review_body в ClickHouse составляет 14 Гб, средняя длина одного ревью составляет порядка 300 символов):
> ALTER TABLE amazon ADD INDEX body_idx review_body TYPE ngrambf_v1(3, 512, 2, 0) GRANULARITY 1 -- занимает на диске 23 Kб, вообще ничего не фильтрует
> ALTER TABLE amazon ADD INDEX body_idx2 review_body TYPE ngrambf_v1(3, 4096, 2, 0) GRANULARITY 1 -- занимает на диске 32 Мб, если повезет, то фильтрует от силы 50% записей, но в целом как повезет
> ALTER TABLE amazon ADD INDEX body_idx3 review_body TYPE ngrambf_v1(3, 16384, 2, 0) GRANULARITY 1 -- занимает 134 Мб, иногда фильтрует почти 100% записей, но в среднем на различных запросах у меня получалось фильтрация около 50%Я поиграюсь ещё с размером блум-фильтра, но, кажется, с ним не всё так легко и хорошо, как может показаться на первый взгляд :).
Попробовал также совсем большой индекс:
ngrambf_v1(3, 524288, 2, 0)Он занимает примерно ~10% от общего объема данных (т.е. около 1.4 Гб), и при чтении упирается в CPU ClickHouse, который читает этот файл примерно за ~5 секунд, вне зависимости от запроса. При этом даже такой большой bloom-фильтр далеко не всегда дает хоть какой-то выигрыш.
ИМХО, наиболее полезным мне пока что кажется вариант с 16384 — на отзывах амазона он достаточно часто позволяет пропускать около 50% блоков, сравнимо с 524288 (не знаю, почему, если честно, не копался слишком глубоко), но при этом имеет минимальный оверхед.
Это же антипаттерн. Хранить надо не сообщения, а парсить их в поля. Тогда группировка будет делать своё дело, нагрузка на диски будет минимальна, и вообще большинство может в память поместиться.
Разрабатываем самый удобный в мире* интерфейс для просмотра логов