Возможно для людей из разработки DWH, тут открыли новый мир. Но это лишь инструмент автоматизации. И подбирать надо под задачу. Тут описаны лишь задачи развертывания и конфигурирования, а инструменту в принципе пофиг, что разворачивать.
Я подумал, что сортировка не сделана из-за issue ClickHose с order by и limit - он выбирает вообще все столбцы даже, те что в сортировке не нужны. Потому, если указать в запросе Attributes и Resources, то запрос очень долго будет отрабатывать или помрет, т.к. будет грузить гигабайты данных.
Мы это обходим или не используя order by, или с подзапросом.
Я ваш проект видел пару недель назад. Только тогда не задалось с демкой, не пускало. Выглядит приятно. Напоминает DataDog. Интересно сделано решение с добавлением фильтров по полям по выбранному сообщению.
Я правильно понимаю, что вы предлагаете хранить в YDB вообще все виды данных: логи, трейсы и метрки?
Вот эта фраза " И это явно работает быстрее и надежнее чем Kafka + VM" - на основе чего вы сделали данный ввод? Видимо располагаете бенчмарком? Можете показать?
Все упирается в налисияе мощностей и прогнозов роста. Есть пределы.
5-30% - это от чего замер?
Если ресурсы не проблема, то можно вообще трафик сохранять )) Но обычно это не так и есть реальные ограничения в которые надо уложиться.
Про OpenTelemetry - что за критические такие сбои? Это мол когда у тебя приложение внезапно крашнулось? Но оно тогда ничего и не успеет написать никуда. И ничто не мешает логи библиотекой otel плевать в stdout и оттуда собирать в коллектор.
обычно в больших проектах только выше уровня error сохраняют, ведь с debug/trace затраты будут мама не горюй.
Да на маленьких можно вообще все тело запроса/ответа сохранять )
Но на больший проектах постоянно такое делать - дорого.
Я вот завидую OpenTelemetry, если код передает трейсы и доги через него, тот при семплировпнии библиотека знает, что и лог надо сохранить с ним вместе. Обычно если спмплировпние 0.001% на нагруженном сервисе на трейсы и на логи, то трейс с логом редко найдешь.
Но можно решить кастрмным адаптером на агенте или на агрегаторе vector.
В схеме с моделью Opentelemetry log model можно вообще по началу без разбора всю строку сообщения как есть класть в поле Body. Мы так делали например, когда срочно надо было собрать логи с LinkerD, а они были еще в plaintext и на json быстро нельзя было перевести.
В нашем алгоритме мы сохраняем сообщение целиком в Body поле и в случае, когда распарсить не удалось.
Да. У нас один сервис как-то начал логи криво писать и весь json падал в одно поле, каково было мое удивление, когда я увидел запрос с кучей JSONExtract. И оно даже работало.
Интересная идея - разные сроки хранения для разных уровней лога. Возьму на заметку. У нас на проде для, большинства вообще жёсткий фильтр на игонор debug логов.
а у меня было. Как то папке подарили пуэр из Китая мелкий такой диск. Мы с вечерка выпили и разошлись. На следующий день встречаемсяи никто из нас так и не спал. Ощущение было будто спички в глаза в ставили и ходишь такой фарами в ночи светишь )
Правильно я понимаю, что вы предлагаете не обрабатывать логи на лету, а просто сложить в Clickhhouse, а дальше нужную статистику получить уже оперируя запросами SQL?
Нет такое решение мы не считали и на рассматривал, так как задача была улучшить, то решение что уже есть. Переход на Clickhouse привел бы к более масштабным работам, что мне в рамках тогда еще испытательного срока могли бы и не доверить.
Еще нам нужны метрики "на лету", а с Clickhouse, думается, была бы дополнительная задержка, т.к. данные надо в него сначала записать, да и постоянно запускать раз в 5 секунд запросы для расчётов на нем может быть затратно.
А у Вас есть/был такой опыт? Это довольно интересный подход, я подобное слышал, но сам не применял, так как для меня Clickhouse лишь хранилище, как аналитический инструмент для извлечения данных я его пока не использовал. В нем же тоже есть какие-то свои плюсы и минусы, зная их уже можно понять подходит оно или нет.
Возможно для людей из разработки DWH, тут открыли новый мир. Но это лишь инструмент автоматизации. И подбирать надо под задачу. Тут описаны лишь задачи развертывания и конфигурирования, а инструменту в принципе пофиг, что разворачивать.
Как просвящение для коллег - хорошо.
Я подумал, что сортировка не сделана из-за issue ClickHose с order by и limit - он выбирает вообще все столбцы даже, те что в сортировке не нужны. Потому, если указать в запросе Attributes и Resources, то запрос очень долго будет отрабатывать или помрет, т.к. будет грузить гигабайты данных.
Мы это обходим или не используя order by, или с подзапросом.
Вопрос: можно ли настроить кастомно поля для логов Otel? Они у себя имеют ResourceAttributes и LogAttributes, а у меня они Attributes и Resource.
Честно говоря уже не помню.
FlyQL напомнил DataDog язык запросов.
Я ваш проект видел пару недель назад. Только тогда не задалось с демкой, не пускало.
Выглядит приятно. Напоминает DataDog. Интересно сделано решение с добавлением фильтров по полям по выбранному сообщению.
FlyQL - это вы сами придумали DSL?
Сортировка логов жестко зашита?
Вообще стоит описывать, что конкретно вы считаете за Observability, т.к. люди могут наткнуться на разные толкования и будет разлад.
В моем словаре наблюдаемость (Observability) - это возможность по конечным сигналам (телеметрия) понять состояние системы в нужный момент времени.
Если сигналов недостаточно, то приходиться догадываться/домысливать, а не по фактам выстраивать картину.
@polRk можете дать ответ на вопросы выше?
Я правильно понимаю, что вы предлагаете хранить в YDB вообще все виды данных: логи, трейсы и метрки?
Вот эта фраза " И это явно работает быстрее и надежнее чем Kafka + VM" - на основе чего вы сделали данный ввод? Видимо располагаете бенчмарком? Можете показать?
Все упирается в налисияе мощностей и прогнозов роста. Есть пределы.
5-30% - это от чего замер?
Если ресурсы не проблема, то можно вообще трафик сохранять )) Но обычно это не так и есть реальные ограничения в которые надо уложиться.
Про OpenTelemetry - что за критические такие сбои? Это мол когда у тебя приложение внезапно крашнулось? Но оно тогда ничего и не успеет написать никуда. И ничто не мешает логи библиотекой otel плевать в stdout и оттуда собирать в коллектор.
обычно в больших проектах только выше уровня error сохраняют, ведь с debug/trace затраты будут мама не горюй.
Да на маленьких можно вообще все тело запроса/ответа сохранять )
Но на больший проектах постоянно такое делать - дорого.
Я вот завидую OpenTelemetry, если код передает трейсы и доги через него, тот при семплировпнии библиотека знает, что и лог надо сохранить с ним вместе. Обычно если спмплировпние 0.001% на нагруженном сервисе на трейсы и на логи, то трейс с логом редко найдешь.
Да, мы развлекались с 1С ) )
Но можно решить кастрмным адаптером на агенте или на агрегаторе vector.
В схеме с моделью Opentelemetry log model можно вообще по началу без разбора всю строку сообщения как есть класть в поле Body. Мы так делали например, когда срочно надо было собрать логи с LinkerD, а они были еще в plaintext и на json быстро нельзя было перевести.
В нашем алгоритме мы сохраняем сообщение целиком в Body поле и в случае, когда распарсить не удалось.
Да. У нас один сервис как-то начал логи криво писать и весь json падал в одно поле, каково было мое удивление, когда я увидел запрос с кучей JSONExtract. И оно даже работало.
Интересная идея - разные сроки хранения для разных уровней лога. Возьму на заметку. У нас на проде для, большинства вообще жёсткий фильтр на игонор debug логов.
Хороша ложка к обеду. Сейчас бы уже на victorialogs смотрел бы сначала.
А как у вас в случае отказа конечного приемника работает? Полагаетесь на кеши vector-proxy?
а у меня было. Как то папке подарили пуэр из Китая мелкий такой диск. Мы с вечерка выпили и разошлись. На следующий день встречаемсяи никто из нас так и не спал. Ощущение было будто спички в глаза в ставили и ходишь такой фарами в ночи светишь )
Отпустило через сутки
Когда сделал, чтобы сделать.
Правильно я понимаю, что вы предлагаете не обрабатывать логи на лету, а просто сложить в Clickhhouse, а дальше нужную статистику получить уже оперируя запросами SQL?
Нет такое решение мы не считали и на рассматривал, так как задача была улучшить, то решение что уже есть. Переход на Clickhouse привел бы к более масштабным работам, что мне в рамках тогда еще испытательного срока могли бы и не доверить.
Еще нам нужны метрики "на лету", а с Clickhouse, думается, была бы дополнительная задержка, т.к. данные надо в него сначала записать, да и постоянно запускать раз в 5 секунд запросы для расчётов на нем может быть затратно.
А у Вас есть/был такой опыт? Это довольно интересный подход, я подобное слышал, но сам не применял, так как для меня Clickhouse лишь хранилище, как аналитический инструмент для извлечения данных я его пока не использовал. В нем же тоже есть какие-то свои плюсы и минусы, зная их уже можно понять подходит оно или нет.
Именно эта реализация заточена на сбор событий с http-логов, потому ей мы собирали именно число запросов и время ответа.
Да в статье примера гистограмм нет, но есть тут в исходнике https://github.com/vseinstrumentiru/vector.dev-metrics-to-logs-helper/blob/main/ansible-playbook/vars/metrics-catalog.yml#L64
Чтобы строить гистограммы по времени ответа, нужно это время ответа в логе иметь записанным, а nginx умеет это писать
Также оцените опыт c Vector колег из VK, они пошли немного другим путем, но схема развертывания Vector схожая