Comments 32
Подождите, уважаемые! А как же поддержка Opentelemetry? Зачем людям писать инструментирование кода, если уже есть куча наработок на базе OTLP?
Есть же индустриальный стандарт, зачем вы решили делать велосипед?
![](https://habrastorage.org/getpro/habr/upload_files/30f/320/b4c/30f320b4c484e8a2173ead1d5ebfe3e4.png)
Вот такая красота из коробки на базе Jaeger. Не нравится Jaeger, пишите свою систему сверху или юзайте готовые типа Aspecto, etc.
У нас есть сама поддержка OTLP (умеем принимать), но пока нет дашбордов для просмотра метрик и трейсов. Логи на первом месте.
так там же фишка как раз в прикреплении логов к трейсу. У вас события не висят в общем потоке, а ассоциированы с бизнес-транзакциями. И в этом весь цимес.
Не везде есть именно трейсы. Это производная от логов. Мы начали с "просто логов", любых вообще. Мы помним про OT, двигаемся в этом направлении. У нас есть поддержка именно трейсов, но пока что нет средств отображения, потому пока молчим. Но всё будет :)
Ладно, у меня другой заход. Почему не пошли по пути filebeat/logstash, зачем мне корячить ваш код в мой код, чтобы "что" - вендор-лок появился?
Причин несколько:
- файлы, особенно в распределённой среде, это очень неудобный компромисс. Их объёмы, актуальность, сохранность и т.д. - это всё должно быть предусмотрено и почти всегда предусматриваться это должно другими людьми (админы/эксплуатация), не разработчиками.
- и filebeat и logstash имеют определённые трудности с форматами файлов (многострочность, кодировки, LTR/RTL)
- динамическая структура лога фактически недоступна
Всё это мы постарались победить.
И, к тому же, мы тоже делаем свой аналог filebeat :) Хоть это и не приоритет для нас.
И вот еще бы про это я хотел спросить:
![](https://habrastorage.org/getpro/habr/upload_files/f92/398/fc0/f92398fc0ea6086b1e380f82cdfc95f0.png)
Это что значит? Как минимум, для эффективной загрузки записей в ClickHouse требуется задержка, очевидно, она не может быть нулевой. Или это вы про то, что я логи могу смотреть сегодня, а не послезавтра?
Это значит, что мы умеем доставлять логи от источника до потребителя "не из хранилища", минуя его. Сохранение лога и его доставка куда-то ещё - параллельные процессы, не связанные в нашем случае. И задержки кликхауса в этом случае нет.
А куда, например, его параллельно доставлять?
Например - для показа в реальном времени. Или в другую ИС через интеграцию.
Мне всегда казалось, что коммерческие системы работы с логами - это про умную аналитику, которая обычным смертным системам управления логами не доступна, типа Tableau vs Kibana… в этом смысле сбор логов должен быть максимально типовым и на типовых системах - это вторичная функция, как бы.
Если у вас нет крутой аналитики, не понимаю зачем пользоваться (мнение).
Мы к вам вернёмся, когда сделаем хорошую аналитику! :)
В реальном же времени корректируйте свой запрос, получите обновлённый результат. Без необходимости изучать новый диалект SQL.
А на каком языке, который не надо изучать, делаются ваши запросы?
мире нет и не предвидится нормального, человеческого продукта для работы
в распределённой среде с логами, трейсами, сигналами и прочим подобным
Суровые разработчики настолько суровые что не слышали про datadog / loki / кучу других аналогов
А что скажете про частично схожую систему SigNoz? И логи и трейсы и метрики, также в кликхаусе, опенсорс, полная поддержка OpenTelemetry
А с VictoriaLogs знакомы?
Знакомы конечно. У них почти у всех примерно всё одинаково - без заморочек со структурой, все работают с json. Хранят его, строят над ним индексы, ищут и т.д. Не наш путь.
Так если в логах есть структура, то кидать их через vector в CH и потом смотреть кем угодно - вообще не проблема, зачем там сверху еще какое-то решение?
А что дает LogDoc - сложный в интеграции, с низкой производительностью, да еще и платный?
спасибо за дружелюбный тон
логдок начался именно с идеи обработки любых неструктурированных логов, в этом его главное предназначение, именно в этом направлении мы движемся и достигли определенного успеха
можно придумать очень много комбинаций и обстоятельств, где логдок будет неприменим - не имею никакого желания это оспаривать, мы не стремимся стать единственным решением
Если речь идет о неструктурированных логах, то и смысла в CH гораздо меньше и нужно управлять трансформацией рядом с сервисом, так что и тут лучше какой-нибудь, прости господи, logstash + elastic.
Я просто пытаюсь найти те сценарии, когда LogDoc дает что-то сверх существующих решений - и пока не вижу. Во всех реальных сценариях, которые я знаю - лучше другое решение.
Если можете описать те сценарии, когда LogDoc действительно лучше - то опишите их.
LogDoc: логи здорового человека