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, вероятно в вас тоже он?
Говоря о нашем решении мы сразу оговариваемся, что мы были ограничены в ресурсах, потому мы выбирали компромиссное решение, а не лучшее.
Команды следят за своими логами - это их сервисы и их логи, которые они знают хорошо и могут оценить их актуальность достоверно. Мы же предоставляем сервис по их сбору и хранению.
Что сказать, в момент выбора мы полагались на официальную документацию Vector в которой уже было описано решение с Kafka, как готовое для прод применений. Так как время дорого, а все для ее воплощения было под рукой, то мы ее и применили.
Можете поподробнее рассказать про вашу схему с балансировщиками (что за балансировщики применяли)? И что за вектор-прокси? Как в этой схеме обеспечивается защита от потери логов в моменты перезагрузки 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, вероятно в вас тоже он?
Говоря о нашем решении мы сразу оговариваемся, что мы были ограничены в ресурсах, потому мы выбирали компромиссное решение, а не лучшее.
Команды следят за своими логами - это их сервисы и их логи, которые они знают хорошо и могут оценить их актуальность достоверно. Мы же предоставляем сервис по их сбору и хранению.
Grafana Loki + Promtail сам появился только в апреле 2018 года и был достаточно сырой, потому был исключен из рассмотрения в нашем случае.
Что сказать, в момент выбора мы полагались на официальную документацию Vector в которой уже было описано решение с Kafka, как готовое для прод применений. Так как время дорого, а все для ее воплощения было под рукой, то мы ее и применили.
Можете поподробнее рассказать про вашу схему с балансировщиками (что за балансировщики применяли)? И что за вектор-прокси? Как в этой схеме обеспечивается защита от потери логов в моменты перезагрузки vector (например в нашем случае буфер на агенте точно не спасет, так как логов очень много)