Правильно я понимаю, что вы предлагаете не обрабатывать логи на лету, а просто сложить в Clickhhouse, а дальше нужную статистику получить уже оперируя запросами SQL?
Нет такое решение мы не считали и на рассматривал, так как задача была улучшить, то решение что уже есть. Переход на Clickhouse привел бы к более масштабным работам, что мне в рамках тогда еще испытательного срока могли бы и не доверить.
Еще нам нужны метрики "на лету", а с Clickhouse, думается, была бы дополнительная задержка, т.к. данные надо в него сначала записать, да и постоянно запускать раз в 5 секунд запросы для расчётов на нем может быть затратно.
А у Вас есть/был такой опыт? Это довольно интересный подход, я подобное слышал, но сам не применял, так как для меня Clickhouse лишь хранилище, как аналитический инструмент для извлечения данных я его пока не использовал. В нем же тоже есть какие-то свои плюсы и минусы, зная их уже можно понять подходит оно или нет.
LPS - логов в секунду. LPS per CPU говорит о том, что Vector способен использовать доступные процессоры для масштабирования LPS, в то время как другие сборщики не могут этого сделать
Да даже на малой модели граф переходов замучаешься описывать. И не стоит забывать, что любое изменение зависимостей влечет его перестройку.
На самом деле во многих ит системах не нужна прям точная оценка, так как собственно и не вся система по факту для нас критически важна. Важно уловить тренд - становится ли хуже, а способы этого могут быть разные, хоть количество жалоб от бабушек у подъезда (наблюдал такой SLI на почтальонов кто пенсию разносит :) )
У меня на практике так и выходит, часть удается покрывать по сценарию, а часть по сервису. Прикол в том, что иногда тебе от сервиса важна работа одной из 3 ручек, а остальные могут криво работать из-за багованого релиза, но клиентам и бизнесу это будет мало важно.
Но в части сервисов это не всегда возможно технически. Типа Single Page App, в котором есть graceful degradation и потому у тебя на одну страницу приходит 3-5 запросов и даже если 4 из них умрут, основной контент доедет. Тут тяжело даже просто вот это самое ядро отделить.
Про "функциональности" что ты называешь хорошо перекликается с Operation-based SLO от Zalando - они так смотрят https://engineering.zalando.com/posts/2022/04/operation-based-slos.html. Но кажется в их подходе все равно недосказано про сценарии, где-то же должно быть записано, что если сломался поиск - это знчать покупать в магазине не смогут. Хотя это все можно и в голове подержать в головах команды отвечающей за этот этап сценария.
...пока мы уменьшаем MTTR/MTTRC, продуктовые команды занимаются надёжностью сервисов.
Есть мнение и исследование, что Mean метрики в том числе MTTR для сложных систем не подходят и пытаются упростить, то что является сложным по природе https://www.verica.io/blog/mttr-is-a-misleading-metric-now-what/
Также есть исследование, показывающее, что даже не внося изменений для улучшения MTT* метрик вы можете увидеть их улучшение https://static.googleusercontent.com/media/sre.google/en//static/pdf/IncidentMeticsInSre.pdf
Так считаются SLI/SLO, и именно на основе этих цифр нужно принимать решения. Если сервис не соблюдает SLO из‑за ненадёжных зависимостей, то это хороший индикатор того, что стоит сходить к коллегам и поработать над решением вместе.
Что в этом контексте "сервис"? Равно микросервис?
В концепции SLO "service" имеет более широкое определение и перевод на русский будет "услуга". Услуга – это то как ее видит пользователь, например, услуга "подбор товара" для пользователя интернет-магазина будет комбинацией из: на сайте работает поиск + открываются страницы товара + можно добавить в корзину. Поиск, страница товара, корзина - под капотом это могут быть 3 или больше микросервисов.
да. Все пишут в stdout, а вектор собирает. У нас Kubernetes, потому он сам автоматом создают файлы для stdout, а vector сам при помощи source kubernetes_logs сам забирает из них
Еще такая штука как https://github.com/metrico/qryn (ранее cLoki) позиционируют как Loki + Clickhouse. Вот оно мне кажется более похожим на наш сетап. И возможно если бы оно существовало в 2018 в готовом к прод виде, то могло бы подойти, но qryn начал развиваться только с декабря 2018.
Конечно не так удобно. Особенно если ты давно с ней работал и руки привыкли. Человеку всегда тяжело переходить на новое, надо же изучить. Но тут плюс в том, что не пришлось учить новый язык запросов, так как SQL знает большинство. Мы вообще пошли немного дальше уже, о чем расскажем отдельно. Мы в этом году поменяли структуру хранения в базе, требования к самим логам, и сделали GUI для поиска по логам, которое упрощает поиск. Об этом расскажем несколько позже.
Опишем в отдельной статье. Пока вот можете посмотреть в видео доклада https://devopsconf.io/moscow/2024/abstracts/11564 (если доступ есть), или хотя бы в презентации (она там доступна для скачивания) с слайда 115 про Unified Log Pipeline.
У нас есть Minio, а в S3 в принципе можно прямо из Clickhouse настроить выгрузку для холодного хранилища. Пока у нас все на своих ресурсах внутри наших ЦОД.
Вот интересно как там с отладкой обработчиков логов, в vector я тесты пишу и их гоняю, как там в Loki не знаю. Возможно там другой подход
Посмотрел в вашей статье картинки, очень заинтерисовало как выделали схему по этапам трансформации сообщений. Это только картинка для статьи или у вас есть интерфейс визуализации топологии Vector? Я такой видел в демо DataDog (они купили vector и развивают), у них там видно как трансформы соединены и как идет переток событий https://youtu.be/GjcLWupY0jk?t=2990
Спасибо за ссылку - не видел этой статьи. Действительно проблема схожая. Там они еще описывают, как изменили свою схему хранения в ClickHouse. Мы тоже отошли от начальной схемы и сейчас переходим на новую - об этом я тоже расскажу, но позже.
200 Гб в день - это верно для нашей инфраструктуры. Мы можем и 1Тб генерить, только разреши писать все от DEBUG уровня и все запросы с телом запроса )) Но нам и 200 хватает )
Уже давал коммент по поводу Loki выше. В 2018 году он был совсем зелен и не рассматривался как готовое в прод решение.
Я бы с удовольствием прочитал о вашем решении, чтобы посмотреть и сравнить. У нас используются bloom фильтры в Clickhouse, вероятно в вас тоже он?
Говоря о нашем решении мы сразу оговариваемся, что мы были ограничены в ресурсах, потому мы выбирали компромиссное решение, а не лучшее.
Правильно я понимаю, что вы предлагаете не обрабатывать логи на лету, а просто сложить в 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 схожая
Некропост, но все же. Я частично описывал тут https://habr.com/ru/articles/808313/
"Сравнили Vector.dev и FluentD ⭢ победил Vector"
смотрите сравнение с графиками тут https://medium.com/ibm-cloud/log-collectors-performance-benchmarking-8c5218a08fea (зеркало) там FluentD, Fluentbit. Vector
LPS - логов в секунду. LPS per CPU говорит о том, что Vector способен использовать доступные процессоры для масштабирования LPS, в то время как другие сборщики не могут этого сделать
Да даже на малой модели граф переходов замучаешься описывать. И не стоит забывать, что любое изменение зависимостей влечет его перестройку.
На самом деле во многих ит системах не нужна прям точная оценка, так как собственно и не вся система по факту для нас критически важна. Важно уловить тренд - становится ли хуже, а способы этого могут быть разные, хоть количество жалоб от бабушек у подъезда (наблюдал такой SLI на почтальонов кто пенсию разносит :) )
Оттуда в твою статью и пришел )
Но не стал там писать, чтобы ответы остались доступны в поисковой выдаче, а не только в нашем уютном сообществе обнадеживающих людей )
Это немного оффтоп. Это скорее про не стреляйте по воробьям из пушек. Все полагаются на "разумный смысл", забывая, что для каждого он свой
У меня на практике так и выходит, часть удается покрывать по сценарию, а часть по сервису. Прикол в том, что иногда тебе от сервиса важна работа одной из 3 ручек, а остальные могут криво работать из-за багованого релиза, но клиентам и бизнесу это будет мало важно.
Но в части сервисов это не всегда возможно технически. Типа Single Page App, в котором есть graceful degradation и потому у тебя на одну страницу приходит 3-5 запросов и даже если 4 из них умрут, основной контент доедет. Тут тяжело даже просто вот это самое ядро отделить.
Про "функциональности" что ты называешь хорошо перекликается с Operation-based SLO от Zalando - они так смотрят https://engineering.zalando.com/posts/2022/04/operation-based-slos.html. Но кажется в их подходе все равно недосказано про сценарии, где-то же должно быть записано, что если сломался поиск - это знчать покупать в магазине не смогут. Хотя это все можно и в голове подержать в головах команды отвечающей за этот этап сценария.
Про DOMA надо посмотреть.
Есть мнение и исследование, что Mean метрики в том числе MTTR для сложных систем не подходят и пытаются упростить, то что является сложным по природе https://www.verica.io/blog/mttr-is-a-misleading-metric-now-what/
Также есть исследование, показывающее, что даже не внося изменений для улучшения MTT* метрик вы можете увидеть их улучшение https://static.googleusercontent.com/media/sre.google/en//static/pdf/IncidentMeticsInSre.pdf
есть вопрос. Вот вы тут пишете
Что в этом контексте "сервис"? Равно микросервис?
В концепции SLO "service" имеет более широкое определение и перевод на русский будет "услуга". Услуга – это то как ее видит пользователь, например, услуга "подбор товара" для пользователя интернет-магазина будет комбинацией из: на сайте работает поиск + открываются страницы товара + можно добавить в корзину. Поиск, страница товара, корзина - под капотом это могут быть 3 или больше микросервисов.
да. Все пишут в stdout, а вектор собирает. У нас Kubernetes, потому он сам автоматом создают файлы для stdout, а vector сам при помощи source kubernetes_logs сам забирает из них
Это замечательно. Это исповедь разработчика/программиста. Или наставление - с удовольствием давал бы это в виде клятвы джунам.
Да фичами уже не разрулишь такое, надо договариваться с разработкой - это сильно упрощает жизнь и нам и им.
Я вот сейчас не могу объективно сравнить Vector и Loki. Решение по вектору мы принимали тогда в 2018 и в тех условиях.
Поискал сегодня, делал ли кто-то подобный переход с ELK на Loki. Попалась схожая с моей статья 2022 года - "Как мы перешли с Elastic на Grafana stack и сократили расходы в несколько раз" https://habr.com/ru/companies/m2tech/articles/693504/
и вторая What I like using Grafana Loki for (and where I avoid it) https://utcc.utoronto.ca/~cks/space/blog/sysadmin/GrafanaLokiWhatILikeItFor
Будет интересно почитать и сравнить. Будет база для выбора решения коллегам.
Еще такая штука как https://github.com/metrico/qryn (ранее cLoki) позиционируют как Loki + Clickhouse. Вот оно мне кажется более похожим на наш сетап. И возможно если бы оно существовало в 2018 в готовом к прод виде, то могло бы подойти, но qryn начал развиваться только с декабря 2018.
Конечно не так удобно. Особенно если ты давно с ней работал и руки привыкли. Человеку всегда тяжело переходить на новое, надо же изучить. Но тут плюс в том, что не пришлось учить новый язык запросов, так как SQL знает большинство.
Мы вообще пошли немного дальше уже, о чем расскажем отдельно. Мы в этом году поменяли структуру хранения в базе, требования к самим логам, и сделали GUI для поиска по логам, которое упрощает поиск. Об этом расскажем несколько позже.
Опишем в отдельной статье. Пока вот можете посмотреть в видео доклада https://devopsconf.io/moscow/2024/abstracts/11564 (если доступ есть), или хотя бы в презентации (она там доступна для скачивания) с слайда 115 про Unified Log Pipeline.
У нас есть Minio, а в S3 в принципе можно прямо из Clickhouse настроить выгрузку для холодного хранилища. Пока у нас все на своих ресурсах внутри наших ЦОД.
Вот интересно как там с отладкой обработчиков логов, в vector я тесты пишу и их гоняю, как там в Loki не знаю. Возможно там другой подход
Посмотрел в вашей статье картинки, очень заинтерисовало как выделали схему по этапам трансформации сообщений. Это только картинка для статьи или у вас есть интерфейс визуализации топологии Vector? Я такой видел в демо DataDog (они купили vector и развивают), у них там видно как трансформы соединены и как идет переток событий https://youtu.be/GjcLWupY0jk?t=2990
Спасибо за ссылку - не видел этой статьи. Действительно проблема схожая.
Там они еще описывают, как изменили свою схему хранения в ClickHouse. Мы тоже отошли от начальной схемы и сейчас переходим на новую - об этом я тоже расскажу, но позже.
200 Гб в день - это верно для нашей инфраструктуры. Мы можем и 1Тб генерить, только разреши писать все от DEBUG уровня и все запросы с телом запроса )) Но нам и 200 хватает )
Уже давал коммент по поводу Loki выше. В 2018 году он был совсем зелен и не рассматривался как готовое в прод решение.
Я бы с удовольствием прочитал о вашем решении, чтобы посмотреть и сравнить. У нас используются bloom фильтры в Clickhouse, вероятно в вас тоже он?
Говоря о нашем решении мы сразу оговариваемся, что мы были ограничены в ресурсах, потому мы выбирали компромиссное решение, а не лучшее.