100% аптайм - это 100% надежность. А что это значит на бытовом уровне? То что вы ожидаете , что ваш сервис успешно будет работать после взрыва солнца и схлопывания его в чёрную дыру.

Есть отличный проект https://map.r9y.dev/beck/map.html - карата, которая показывает сколько всего вам нужно, чтобы держать выбранное количество девяток. А как мы знаем переход на следующую девятку, это затраты на порядок больше на поддержание такого сервиса в работе. Нужно ловить баланс. Ручей можно и на дырявой лодке переплыть, если даже после выхода на берег она утонула - для такой цели ее надежности хватило.

Если у вас появились еще вопросы про SLO и вам интересно узнать, как это работает у других - приглашаем в сообщество ALLSLO https://t.me/allslo_ru

Если одна перегородка скомпрометирована, вода попадает только в эту перегородку, спасая корабль от затопления

Если в отсеке пробоина, то вода попадает только в этот отсек, а переборки спасают от проникновения воды в соседние отсеки.
В кораблях корпус разделяется переборками на отсеки.

Как просвящение для коллег - хорошо.

Мы это обходим или не используя order by, или с подзапросом.

FlyQL напомнил DataDog язык запросов.

FlyQL - это вы сами придумали DSL?

Сортировка логов жестко зашита?

В моем словаре наблюдаемость (Observability) - это возможность по конечным сигналам (телеметрия) понять состояние системы в нужный момент времени.

Если сигналов недостаточно, то приходиться догадываться/домысливать, а не по фактам выстраивать картину.

5-30% - это от чего замер?

Если ресурсы не проблема, то можно вообще трафик сохранять )) Но обычно это не так и есть реальные ограничения в которые надо уложиться.

Про OpenTelemetry - что за критические такие сбои? Это мол когда у тебя приложение внезапно крашнулось? Но оно тогда ничего и не успеет написать никуда. И ничто не мешает логи библиотекой otel плевать в stdout и оттуда собирать в коллектор.

Да на маленьких можно вообще все тело запроса/ответа сохранять )

Но на больший проектах постоянно такое делать - дорого.

Я вот завидую OpenTelemetry, если код передает трейсы и доги через него, тот при семплировпнии библиотека знает, что и лог надо сохранить с ним вместе. Обычно если спмплировпние 0.001% на нагруженном сервисе на трейсы и на логи, то трейс с логом редко найдешь.

Но можно решить кастрмным адаптером на агенте или на агрегаторе vector.

В схеме с моделью Opentelemetry log model можно вообще по началу без разбора всю строку сообщения как есть класть в поле Body. Мы так делали например, когда срочно надо было собрать логи с LinkerD, а они были еще в plaintext и на json быстро нельзя было перевести.

В нашем алгоритме мы сохраняем сообщение целиком в Body поле и в случае, когда распарсить не удалось.