Привет, Хабр
Однажды команда LogDoc (компания друзей - суровых разработчиков), после бурного обсуждения очередного напряжённого рабочего дня вынесла однозначный вердикт – в мире нет и не предвидится нормального, человеческого продукта для работы в распределённой среде с логами, трейсами, сигналами и прочим подобным. Нас это опечалило (по очевидным причинам) и воодушевило – мы увидели возможность создать полезный продукт. Подумали, собрались с духом и выложились полностью в попытке реализовать задуманное. Именно результат наших усилий мы представляем вам в этой вводной статье.
Что такое LogDoc
LogDoc – это система сбора и хранения логов в локализованных и распределённых окружениях любого объёма. И ещё много чего около. Простыми словами: LogDoc умеет открывать множество портов, принимать входящие соединения и раскладывать потоки данных в упорядоченные структуры. Из коробки есть поддержка Syslog/Journald, Python native логгер, Java slf4j (наш appender), Javascript (наша библиотека) и открытый logdoc-протокол для tcp/ip, udp и http.
NB: у нас есть SDK для написания собственных плагинов, чтобы вы могли встроить поддержку собственных уникальных форматов и протоколов.
Полученные структуры параллельно складываются в ClickHouse и проходят систему фильтрации для отдачи потребителям в реальном времени. Потребителями могут быть и живые пользователи (просмотр логов) и другие информационные системы и встроенные плагины – из коробки мы предоставляем возможность уведомлений в телеграм, отправки писем через smtp и выполнения различных http-коллбеков.
NB: у нас есть SDK для написания собственных плагинов, чтобы вы могли встроить собственных потребителей. Да, у нас две системы плагинов – на вход и на выход данных.
Стоит отметить, что мы не забыли про ИБ и SIEM системы – LogDoc предоставляет возможность создавать фильтры по «цепочкам событий», выставлять пороговые количественные и временные ограничения. И конечно же – выстраивать реакции на срабатывание этих фильтров. Возможности сценарного движка реакций могут быть расширены под индивидуальные требования пользователей.
Вполне естественно, что когда мы рассказываем про LogDoc, то слушателям в первую очередь на ум приходят ELK/Greylog/Splunk и подобные, но сравнение не совсем корректно. Подчеркнём важные моменты:
LogDoc не для поиска. Мы приложили максимум усилий, чтобы изменить тренд «искать в логах». Мы считаем, что относиться к логам как к документам – ошибка. Вместо этого мы крайне старательно превращаем все входящие записи в структуры – чтобы до искомых данных можно было добраться системно, путём предсказуемых и логичных действий, вместо полнотекстового поиска. Всё сказанное, впрочем, не отменяет наличия поиска по подстроке.
LogDoc предоставляет потребителям данные с нулевой задержкой. Мы считаем, что схема «получить данные, сохранить всё в бд, отдать логи через запрос к бд» – неверная. Более удобный концепт – сформируйте запрос и получайте в реальном времени то, что удовлетворяет этому запросу. В уже структурированном виде. В реальном же времени корректируйте свой запрос, получите обновлённый результат. Без необходимости изучать новый диалект SQL.
LogDoc изначально поддерживает многострочные записи (из любых источников, любым транспортом)
LogDoc не требует предварительной настройки хранилища для уникальных структур записей. Все поля сразу же, с первой записи, будут именно полями. Доступными для фильтрации, аналитики и т.д.
Благодаря ClickHouse и его алгоритмам сжатия, LogDoc не требует огромного дискового пространства для хранения всех ваших данных.
LogDoc изначально спроектирован для работы в распределённых средах – прекрасно масштабируется сам и отлично работает с тысячами источников данных.
LogDoc обладает интерфейсом, спроектированным с внимательным учётом всех пожеланий от тех, кто правда очень часто вынужден смотреть в логи – разработчиков, администраторов и QA. Мы вас слышим!
LogDoc не модифицирует ваши данные. Не дробит, не объединяет, не форматирует, не подменяет, не размечает и не оптимизирует. Обрабатывается и пересылается всё в том виде, как пришло из источника.
NB: для показа в человекочитаемом виде в браузере мы всё-таки вынуждены некоторые непечатные последовательности скрывать.
Кому мы хотим быть полезны
Разработчикам и QA
LogDoc проектировался с учётом типового сценария разработки распределённых ИС – когда разработчики часто раскатывают различные ветки микросервисов в разные контуры в Kubernetes (например), и логи отовсюду транслируются в общее хранилище. Для удобного и быстрого доступа к этим логам предусмотрен мощный каталогизатор, удобная фильтрация на лету, доступ с нулевой задержкой, поддержка собственных структур без какой-либо подготовки и многое другое. Всё персонализировано и всё сохраняется для переиспользования.
Администраторам, релизным инженерам, службе эксплуатации
LogDoc «из коробки» поддерживает системные логи - syslog/journald и windows event log (с адаптером). Количество источников логов по большому счёту не имеет значения.
Уровни детализации настраиваются очень гибко, что позволяет структурировать выборки вплоть до конкретного процесса.
Уровни доступа также настраиваются вплоть до конкретной учётки, позволяя как массово разрешать «всё», так и выделять какому-то персональному аккаунту видеть только один поток, от единичного процесса, даже до единичного потока в процессе.
Службе информационной безопасности
Один из основных механизмов LogDoc - «сторож», предназначен для отслеживания аномалий в потоках данных. Для отслеживания с дальнейшей некой «реакцией» по совпадению. Гибкая система кастомизации реакций (через плагины) позволяет как передать событие дальше по цепочке, например – в SIEM, так и самостоятельно предпринять какие-то действия.
LogDoc делает особый акцент на realtime задержке анализа структур с той целью, чтобы SIEM как можно быстрее получала уведомления о возможных инцидентах. Мы стремимся снизить количество false positive инцидентов, именно для этого мы разработали функционал сценарности в pipe-плагинах – в результате LogDoc умеет отслеживать частотность, повторяемость событий, умеет выстраивать события в цепочки (упорядоченные последовательности) или в группы (неупорядоченные последовательности) и, самое главное, может общаться с любой внешней ИС – достаточно лишь реализовать требуемый pipe-плагин или использовать наш http-callback плагин, если у вашей системы есть HTTP API.
Всем сотрудникам служб IT
Мы построили гибкую платформу, с крайне высокой степенью кастомизации.
В LogDoc столь гибкaя система плагинов, насколько это вообще возможно, это позволяет закрыть любые потребности в сфере анализа и обработки потоков данных.
Команда LogDoc открыта для диалога, мы всегда готовы либо реализовать отсутствующий функционал, либо подсказать как вам достичь необходимого собственными силами.
Как это выглядит
Типовой сценарий
Расширенный сценарий
Пользователю необходимо отследить комбинацию данных и предпринять какие-то действия
Версии
LogDoc выпускается в трёх версиях. Все версии одинаковы по пользовательской функциональности, различия показаны в таблице:
Portable |
Community |
Pro |
|
Переносимая |
x |
||
Хранилище ClickHouse |
x |
x |
|
0 задержка |
x |
x |
x |
Масштабирование |
x |
||
Порты без ограничений |
x |
||
Договор поддержки |
x |
||
Кастомизация приёмников |
x |
x |
x |
Кастомизация интеграций |
x |
x |
x |
Пропускная способность
Пропускная способность одного узла - 54 мбит/сек.*
Это около 63.000 сообщений в секунду.
Portable и community версии не масштабируются – первая предназначена для быстрой диагностики и бездисковых изолированных систем, вторая – для разработчиков и маленьких проектов в локализованном окружении. Обе версии представляют из себя единичный узел.
Pro версия горизонтально масштабируется в двух аспектах – на уровне приёмников (в нашей терминологии - «ульев») и на уровне управляющих приложений («ядер»). И в том и в другом случае это stateless приложения, которые можно безболезненно множить любыми средствами, в случае ядер – даже динамически, например через kubernetes pod auto scaling. Масштабирование ульев даёт увеличение пропускной способности кластера LogDoc на вход данных, масштабирование ядер позволяет увеличить пропускную способность на обслуживание пользовательских запросов, сценариев и интеграции с другими ИС. Совокупно оперируя этими двумя аспектами распределения, можно достичь покрытия любого объёма запросов.
*Для тестов использовались мутации пакета размером около 6kb, транспорт tcp, Yandex Tank.
Как попробовать
На сайте https://logdoc.org вы можете скачать понравившуюся версию.
А до конца 2023 года мы планируем вывести Portable и Community в open source, когда поднакопим опыта эксплуатации и сделаем рефакторинг :)
На этом первое знакомство с LogDoc закончено, надеемся, что мы смогли вас заинтересовать! В следующей статье мы подробно расскажем про архитектуру LogDoc, системы плагинов и прочие технические подробности. Пока же вы можете продолжить знакомство самостоятельно: https://logdoc.org Mы всегда на связи: info@logdoc.org
Комментарии (26)
ivankudryavtsev
25.08.2023 09:24И вот еще бы про это я хотел спросить:
Это что значит? Как минимум, для эффективной загрузки записей в ClickHouse требуется задержка, очевидно, она не может быть нулевой. Или это вы про то, что я логи могу смотреть сегодня, а не послезавтра?
systemarch Автор
25.08.2023 09:24+1Это значит, что мы умеем доставлять логи от источника до потребителя "не из хранилища", минуя его. Сохранение лога и его доставка куда-то ещё - параллельные процессы, не связанные в нашем случае. И задержки кликхауса в этом случае нет.
ivankudryavtsev
25.08.2023 09:24А куда, например, его параллельно доставлять?
systemarch Автор
25.08.2023 09:24Например - для показа в реальном времени. Или в другую ИС через интеграцию.
atshaman
25.08.2023 09:24Так вроде все, кому это "прям надо" (А надо это не то, чтобы "всем") для этого например kafka'у используют.
systemarch Автор
25.08.2023 09:24Мы не претендуем на дистрибуцию, мы про структурирование, фильтрацию и отображение. Хотя и в кафку мы тоже умеем транслировать - это кому как удобнее.
ivankudryavtsev
25.08.2023 09:24Мне всегда казалось, что коммерческие системы работы с логами - это про умную аналитику, которая обычным смертным системам управления логами не доступна, типа Tableau vs Kibana… в этом смысле сбор логов должен быть максимально типовым и на типовых системах - это вторичная функция, как бы.
Если у вас нет крутой аналитики, не понимаю зачем пользоваться (мнение).
systemarch Автор
25.08.2023 09:24+1Мы к вам вернёмся, когда сделаем хорошую аналитику! :)
ivankudryavtsev
25.08.2023 09:24Так а в чем основная текущая ценность для клиента? Выглядит, что у вас типа движок фильтрации и трансформации на потоке. Чем лучше, скажем Apache Flink или Kafka Streams?
systemarch Автор
25.08.2023 09:24Тезисно: адаптивное структурирование, колоночная БД, малый объём хранения.
dyadyaSerezha
25.08.2023 09:24В реальном же времени корректируйте свой запрос, получите обновлённый результат. Без необходимости изучать новый диалект SQL.
А на каком языке, который не надо изучать, делаются ваши запросы?
systemarch Автор
25.08.2023 09:24-2Делаются мышкой. Нужно кликать.
dyadyaSerezha
25.08.2023 09:24+1То есть, всю мощь запросов SQL-подобных зыков вы заменили мышкой? Хм...
systemarch Автор
25.08.2023 09:24никто, совсем никто не может у вас отнять мощь SQL!
никто не может вам запретить делать выборки из клика на сыром sql :)
bak
25.08.2023 09:24+2мире нет и не предвидится нормального, человеческого продукта для работы
в распределённой среде с логами, трейсами, сигналами и прочим подобнымСуровые разработчики настолько суровые что не слышали про datadog / loki / кучу других аналогов
aleks_raiden
25.08.2023 09:24А что скажете про частично схожую систему SigNoz? И логи и трейсы и метрики, также в кликхаусе, опенсорс, полная поддержка OpenTelemetry
systemarch Автор
25.08.2023 09:24А что сказать? Они молодцы. Мы плотно наблюдаем за ними. У них есть много фич, которые у нас пока только в планах.
ivankudryavtsev
Подождите, уважаемые! А как же поддержка Opentelemetry? Зачем людям писать инструментирование кода, если уже есть куча наработок на базе OTLP?
Есть же индустриальный стандарт, зачем вы решили делать велосипед?
Вот такая красота из коробки на базе Jaeger. Не нравится Jaeger, пишите свою систему сверху или юзайте готовые типа Aspecto, etc.
systemarch Автор
У нас есть сама поддержка OTLP (умеем принимать), но пока нет дашбордов для просмотра метрик и трейсов. Логи на первом месте.
ivankudryavtsev
так там же фишка как раз в прикреплении логов к трейсу. У вас события не висят в общем потоке, а ассоциированы с бизнес-транзакциями. И в этом весь цимес.
systemarch Автор
Не везде есть именно трейсы. Это производная от логов. Мы начали с "просто логов", любых вообще. Мы помним про OT, двигаемся в этом направлении. У нас есть поддержка именно трейсов, но пока что нет средств отображения, потому пока молчим. Но всё будет :)
ivankudryavtsev
Ладно, у меня другой заход. Почему не пошли по пути filebeat/logstash, зачем мне корячить ваш код в мой код, чтобы "что" - вендор-лок появился?
systemarch Автор
Причин несколько:
- файлы, особенно в распределённой среде, это очень неудобный компромисс. Их объёмы, актуальность, сохранность и т.д. - это всё должно быть предусмотрено и почти всегда предусматриваться это должно другими людьми (админы/эксплуатация), не разработчиками.
- и filebeat и logstash имеют определённые трудности с форматами файлов (многострочность, кодировки, LTR/RTL)
- динамическая структура лога фактически недоступна
Всё это мы постарались победить.
И, к тому же, мы тоже делаем свой аналог filebeat :) Хоть это и не приоритет для нас.