Да. У нас один сервис как-то начал логи криво писать и весь json падал в одно поле, каково было мое удивление, когда я увидел запрос с кучей JSONExtract. И оно даже работало.
Интересная идея - разные сроки хранения для разных уровней лога. Возьму на заметку. У нас на проде для, большинства вообще жёсткий фильтр на игонор debug логов.
а у меня было. Как то папке подарили пуэр из Китая мелкий такой диск. Мы с вечерка выпили и разошлись. На следующий день встречаемсяи никто из нас так и не спал. Ощущение было будто спички в глаза в ставили и ходишь такой фарами в ночи светишь )
Правильно я понимаю, что вы предлагаете не обрабатывать логи на лету, а просто сложить в 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.
Да. У нас один сервис как-то начал логи криво писать и весь 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 схожая
Некропост, но все же. Я частично описывал тут 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.