Как хорошо, что еще один человек понял, то что доносит SRE Workbook.
100% аптайм - это 100% надежность. А что это значит на бытовом уровне? То что вы ожидаете , что ваш сервис успешно будет работать после взрыва солнца и схлопывания его в чёрную дыру.
Есть отличный проект https://map.r9y.dev/beck/map.html - карата, которая показывает сколько всего вам нужно, чтобы держать выбранное количество девяток. А как мы знаем переход на следующую девятку, это затраты на порядок больше на поддержание такого сервиса в работе. Нужно ловить баланс. Ручей можно и на дырявой лодке переплыть, если даже после выхода на берег она утонула - для такой цели ее надежности хватило.
Если у вас появились еще вопросы про SLO и вам интересно узнать, как это работает у других - приглашаем в сообщество ALLSLO https://t.me/allslo_ru
Если одна перегородка скомпрометирована, вода попадает только в эту перегородку, спасая корабль от затопления
Если в отсеке пробоина, то вода попадает только в этот отсек, а переборки спасают от проникновения воды в соседние отсеки. В кораблях корпус разделяется переборками на отсеки.
Возможно для людей из разработки 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 логов.
а у меня было. Как то папке подарили пуэр из Китая мелкий такой диск. Мы с вечерка выпили и разошлись. На следующий день встречаемсяи никто из нас так и не спал. Ощущение было будто спички в глаза в ставили и ходишь такой фарами в ночи светишь )
" Овerage-расходы:" - это что за винегрет из кирилицы и латиницы? Будто GPT криво написал
Как хорошо, что еще один человек понял, то что доносит SRE Workbook.
100% аптайм - это 100% надежность. А что это значит на бытовом уровне? То что вы ожидаете , что ваш сервис успешно будет работать после взрыва солнца и схлопывания его в чёрную дыру.
Есть отличный проект https://map.r9y.dev/beck/map.html - карата, которая показывает сколько всего вам нужно, чтобы держать выбранное количество девяток. А как мы знаем переход на следующую девятку, это затраты на порядок больше на поддержание такого сервиса в работе. Нужно ловить баланс. Ручей можно и на дырявой лодке переплыть, если даже после выхода на берег она утонула - для такой цели ее надежности хватило.
Если у вас появились еще вопросы про SLO и вам интересно узнать, как это работает у других - приглашаем в сообщество ALLSLO https://t.me/allslo_ru
Если в отсеке пробоина, то вода попадает только в этот отсек, а переборки спасают от проникновения воды в соседние отсеки.
В кораблях корпус разделяется переборками на отсеки.
Возможно для людей из разработки 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?
а у меня было. Как то папке подарили пуэр из Китая мелкий такой диск. Мы с вечерка выпили и разошлись. На следующий день встречаемсяи никто из нас так и не спал. Ощущение было будто спички в глаза в ставили и ходишь такой фарами в ночи светишь )
Отпустило через сутки
Когда сделал, чтобы сделать.