"Посему можно было видеть как лейтенант руководит тушением, а полковники тягают рукава. Не потому что лейтенант самый умный, просто он приехал первый и видел ситуацию в развитии, знает кто, где и что делает." - полезное замечание.
Кстати в IT тоже такая практика, по крайней мере у нас это происходит естественным путем. Важно, только в данных по инциденту отразить кто руководит, чтобы все приходящие на инцидент знали от кого ждать инструкций.
А можешь пояснить, что занит "любой пожарный изменивший распоряжение Руководителя тушения"? Читается, что будто любой пожарный может изменять распоряжения Руководителя тушения, что странно.
Вот кстати даже есть вспомогательне тулы для подобного же подхода https://github.com/github/spec-kit - набор инструментов для разработки Spec Driven Development: требования сначала формализуются, после чего AI помогает превратить их в план, задачи и затем уже реализовывать
Свои менее крупные, но более частые заметки я веду в тг-канале https://t.me/letitkit, если вам интересна тема SRE, Observability и инженерные заметки, то приглашаю.
Как хорошо, что еще один человек понял, то что доносит 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 поле и в случае, когда распарсить не удалось.
"Посему можно было видеть как лейтенант руководит тушением, а полковники тягают рукава. Не потому что лейтенант самый умный, просто он приехал первый и видел ситуацию в развитии, знает кто, где и что делает." - полезное замечание.
Кстати в IT тоже такая практика, по крайней мере у нас это происходит естественным путем. Важно, только в данных по инциденту отразить кто руководит, чтобы все приходящие на инцидент знали от кого ждать инструкций.
А можешь пояснить, что занит "любой пожарный изменивший распоряжение Руководителя тушения"? Читается, что будто любой пожарный может изменять распоряжения Руководителя тушения, что странно.
Вот кстати даже есть вспомогательне тулы для подобного же подхода https://github.com/github/spec-kit - набор инструментов для разработки Spec Driven Development: требования сначала формализуются, после чего AI помогает превратить их в план, задачи и затем уже реализовывать
Свои менее крупные, но более частые заметки я веду в тг-канале https://t.me/letitkit, если вам интересна тема SRE, Observability и инженерные заметки, то приглашаю.
А оно в ide типа vscode подключается или все в онлайне ?
" Ов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 поле и в случае, когда распарсить не удалось.