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