LogDoc: логи здорового человека

[ivankudryavtsev]

Подождите, уважаемые! А как же поддержка Opentelemetry? Зачем людям писать инструментирование кода, если уже есть куча наработок на базе OTLP?

Есть же индустриальный стандарт, зачем вы решили делать велосипед?

Вот такая красота из коробки на базе Jaeger. Не нравится Jaeger, пишите свою систему сверху или юзайте готовые типа Aspecto, etc.

[systemarch]

У нас есть сама поддержка OTLP (умеем принимать), но пока нет дашбордов для просмотра метрик и трейсов. Логи на первом месте.

[ivankudryavtsev]

так там же фишка как раз в прикреплении логов к трейсу. У вас события не висят в общем потоке, а ассоциированы с бизнес-транзакциями. И в этом весь цимес.

[systemarch]

Не везде есть именно трейсы. Это производная от логов. Мы начали с "просто логов", любых вообще. Мы помним про OT, двигаемся в этом направлении. У нас есть поддержка именно трейсов, но пока что нет средств отображения, потому пока молчим. Но всё будет :)

[ivankudryavtsev]

Ладно, у меня другой заход. Почему не пошли по пути filebeat/logstash, зачем мне корячить ваш код в мой код, чтобы "что" - вендор-лок появился?

[systemarch]

Причин несколько:
- файлы, особенно в распределённой среде, это очень неудобный компромисс. Их объёмы, актуальность, сохранность и т.д. - это всё должно быть предусмотрено и почти всегда предусматриваться это должно другими людьми (админы/эксплуатация), не разработчиками.
- и filebeat и logstash имеют определённые трудности с форматами файлов (многострочность, кодировки, LTR/RTL)
- динамическая структура лога фактически недоступна

Всё это мы постарались победить.
И, к тому же, мы тоже делаем свой аналог filebeat :) Хоть это и не приоритет для нас.

[ivankudryavtsev]

И вот еще бы про это я хотел спросить:

Это что значит? Как минимум, для эффективной загрузки записей в ClickHouse требуется задержка, очевидно, она не может быть нулевой. Или это вы про то, что я логи могу смотреть сегодня, а не послезавтра?

[systemarch]

Это значит, что мы умеем доставлять логи от источника до потребителя "не из хранилища", минуя его. Сохранение лога и его доставка куда-то ещё - параллельные процессы, не связанные в нашем случае. И задержки кликхауса в этом случае нет.

[ivankudryavtsev]

А куда, например, его параллельно доставлять?

[systemarch]

Например - для показа в реальном времени. Или в другую ИС через интеграцию.

[atshaman]

Так вроде все, кому это "прям надо" (А надо это не то, чтобы "всем") для этого например kafka'у используют.

[systemarch]

Мы не претендуем на дистрибуцию, мы про структурирование, фильтрацию и отображение. Хотя и в кафку мы тоже умеем транслировать - это кому как удобнее.

[ivankudryavtsev]

Мне всегда казалось, что коммерческие системы работы с логами - это про умную аналитику, которая обычным смертным системам управления логами не доступна, типа Tableau vs Kibana… в этом смысле сбор логов должен быть максимально типовым и на типовых системах - это вторичная функция, как бы.

Если у вас нет крутой аналитики, не понимаю зачем пользоваться (мнение).

[systemarch]

Мы к вам вернёмся, когда сделаем хорошую аналитику! :)

[ivankudryavtsev]

Так а в чем основная текущая ценность для клиента? Выглядит, что у вас типа движок фильтрации и трансформации на потоке. Чем лучше, скажем Apache Flink или Kafka Streams?

[systemarch]

Тезисно: адаптивное структурирование, колоночная БД, малый объём хранения.

[dyadyaSerezha]

• В реальном же времени корректируйте свой запрос, получите обновлённый результат. Без необходимости изучать новый диалект SQL.

А на каком языке, который не надо изучать, делаются ваши запросы?

[systemarch]

Делаются мышкой. Нужно кликать.

[dyadyaSerezha]

То есть, всю мощь запросов SQL-подобных зыков вы заменили мышкой? Хм...

[systemarch]

никто, совсем никто не может у вас отнять мощь SQL!

никто не может вам запретить делать выборки из клика на сыром sql :)

[bak]

мире нет и не предвидится нормального, человеческого продукта для работы
в распределённой среде с логами, трейсами, сигналами и прочим подобным

Суровые разработчики настолько суровые что не слышали про datadog / loki / кучу других аналогов

[inerc]

Так datadog это вообще мониторинг система. Вы точно не путаете?

[bak]

Точно не путаю, там отличные логи с трейсами, тэгами и прочим.

[inerc]

И datadog это on-cloud система. Не все могут и хотят свои логи сливать в сторонний сервис. Насколько я понял ребята сделали On-premise

[aleks_raiden]

А что скажете про частично схожую систему SigNoz? И логи и трейсы и метрики, также в кликхаусе, опенсорс, полная поддержка OpenTelemetry

[systemarch]

А что сказать? Они молодцы. Мы плотно наблюдаем за ними. У них есть много фич, которые у нас пока только в планах.

[BigD]

А с VictoriaLogs знакомы?

[systemarch]

Знакомы конечно. У них почти у всех примерно всё одинаково - без заморочек со структурой, все работают с json. Хранят его, строят над ним индексы, ищут и т.д. Не наш путь.

[dph]

Так если в логах есть структура, то кидать их через vector в CH и потом смотреть кем угодно - вообще не проблема, зачем там сверху еще какое-то решение?
А что дает LogDoc - сложный в интеграции, с низкой производительностью, да еще и платный?

[systemarch]

спасибо за дружелюбный тон

логдок начался именно с идеи обработки любых неструктурированных логов, в этом его главное предназначение, именно в этом направлении мы движемся и достигли определенного успеха

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

[dph]

Если речь идет о неструктурированных логах, то и смысла в CH гораздо меньше и нужно управлять трансформацией рядом с сервисом, так что и тут лучше какой-нибудь, прости господи, logstash + elastic.
Я просто пытаюсь найти те сценарии, когда LogDoc дает что-то сверх существующих решений - и пока не вижу. Во всех реальных сценариях, которые я знаю - лучше другое решение.
Если можете описать те сценарии, когда LogDoc действительно лучше - то опишите их.

[systemarch]

Уважаемый, вы напрыгиваете с готовыми тезисами из своих измышлений, абсолютно безапелляционно заявлете про принципиальные "хуже/лучше" и требуете чтобы вас в чем-то переубедили. Риторический вопрос - с какой стати мне идти на поводу? Вы себе уже все объяснили, не стоит сомневаться.