The Last of 9s

#jvm #profiling #news

привет всем, пока готовлю новый контент не могу пройти мимо подобных новостей!

в корут завезли async-profiler и теперь для всех jvm приложений есть возможность получить по дефолту онлайн профилирование или по кнопке. и все это без рестарта, без плясок с бубном. (пока не пробовал сам, но ребятам можно верить).

https://coroot.com/blog/java-profiling-with-async-profiler/

#firstnine #linux #nodeexporter #sre #applicationfootprint #dashboard #grafanamaniac

и сразу добиваем! сегодня ещё одно ключевое событие для блога: вышла пятая статья серии the first nine. ради нее затевалась вся серия.

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

отсюда я давно в своей практике использую подход который дополняет или полностью заменяет метрики, генерируемые из апликейшна на предсказуемый и понятный набор. поэтому я так люблю coroot, cadvisor и node_exporter.

и на самом деле, конечно, чаще всего я вижу в каждой инфраструктуре установленный урезанный, и поэтому не очень классный, но полезный cadvisor (в составе kubernetes) и прекрасный, восхитительный и реально богатый данными node_exporter.

давайте разбираться что можно понять о приложении, только по метрикам ОС. и отсюда серия the first nine начнет углубляться в уровень ОС и то как приложение работает с системой под собой.

русская версия статьи, минут 20 на прочтение, прям лонгрид: https://kirillyu.github.io/The-Last-of-9s/ru/application-footprint.html

ну и бонус - я сделал дашборд который поможет вам понять круг подозреваемых во время деградации латенси, со стороны операционной системы linux. только на метриках node export - ставим, балуется, улучшаем за счёт ишью сюда: https://github.com/kirillyu/The-Last-of-9s/issues

#blog #news

привет, хорошие новости! я повел полный рефакторинг своих статей и осознал что все текущие платформы имеют ужасные недостатки! я попробовал:
- LinkedIn посты
- telegraph публикации
- даже нашел приятный сервис AFFiNE
и пришел к выводу что проще сделать самому. поэтому навайбкодил себе блог, и теперь он хостится на гитхаб пейджес. прошу любить и жаловать: https://kirillyu.github.io/The-Last-of-9s

все лонгринды, выступления и туловины сделанные мной будут жить там. и теперь если видите косяки можно сразу заводить ишью, тем же путем предлагать любые правки.
чтобы добавить полезности этому посту:
1. теперь все статьи серии the first nine есть на английском и вообще блог мультиязычный.
2. зацените прикольный фон у блога, водим курсором увеличиваем девяточки! считаю что увеличение девяток ещё никогда не было таким простым :)

пока русскоязычный контент мне даётся проще всего, потому телеграм не бросаю. все анонсы будут тоже тут.

ps. все ссылки в телеге выше со временем обновлю на новые рельсы.

Perf Weekly | №1
(инструменты, системы и производительность)

Troubleshooting Slow TCP Transfers: A Stack-Level Approach
Большинство проблем в production решаются без сложных инструментов. Обычно достаточно стандартных утилит, доступных из любого дистрибутива. Главное понимать, как и где их использовать. Например ss и nstat.

Why strong engineers are rarely blocked
Заблокированными могут быть не только треды, но и инженеры. По ссылке о важности менеджмента своих активностей, чтобы двигаться быстрее.

Can We Know Whether a Profiler is Accurate?
Профайлеры, как и любой инструмент, имеют погрешность измерений. В статье разбирается любопытный способ оценивать их точность через контролируемое замедление программы.

#performance #news

увидел презентацию перформанс инженера - Alex Podelko (AWS), про тренды и конфликты в перформанс инженерии. и презентация настолько одновременно попала и не попала в меня, что не смог пройти мимо и решил поделиться.

коротко тезисами мысли из презентации и мнение:
1. в презентации "перформанс снова в моде", а я честно пропустил спад интереса к области как к таковой. интересно, что автор упоминает архитектуру, будто только теперь перформанс стал неотъемлемой частью system design. с этим мне сложно согласиться. скорее перформанс поменял упаковку и стал частью других дисциплин/ролей.
2. интересная мысль что теперь перформанс не только стремится (shift left) к ранним этапам разработки, но и (shift right) в operations, где нас встречают SRE, модный FinOps. не могу сказать что это прям очень свежий тренд, но я согласен с тем что это набирает обороты. я советую в это инвестировать время.
3. упоминается что performance engineering не является самостоятельной дисциплиной, нет ядра базы знаний, нет сертификации (вендорно нейтральной). я не до конца понял, почему автор так считает. тут, к примеру, "архитектура" - это дисциплина тогда?
4. снижается внимание к теории систем массово обслуживания/ теории очередей, снижается внимание к самим инструментам подачи нагрузки. да согласен, сейчас можно читать Брендана Грегга вместо очередей и часто вижу (да и я не исключение) внедрение нагрузочного тестирования в платформу разработки, нативно.
5. все что находится в секции shift left: CI/CD, continuous performance testing и early testing очень давние тренды, я постоянно вижу контент направленный в эту сторону лет 8 точно. это меня как раз удивило, что это подаётся как тренд. на мой взгляд это уже правила хорошего тона на этапе внедрения нагрузки.
6. отдельно в блоке shift right отмечу observability, не зря Grafana затащила k6 к себе. в целом весь блок горячо поддерживаю. гигантский импакт на любой перформанс анализ создаёт именно наличие достаточного покрытия телеметрией.
7. конечно AI, тут я думаю всем интересно внедрить AI к себе в пайплайн тестирования. это заслуживает отдельного топика: про воспроизводимость и вариативность.

но тема трендов очень интересная, помимо описанного в презентации есть у кого-то свежие мысли? у меня была идея интеграции хаос тестов с перформансом и SLO, что выглядит как очень сильная связка особенно в продакшн контуре, но трендом это назвать очень сложно :)

сегодня премьера! моя первая публикация на английском и моя первая публикация в составе victoriametrics team.

о чем пойдет речь?
вспоминая недавний инцидент с aws us-east-1 многие задумались о том как повышать свою устойчивость архитектурно.

я постарался описать самые популярные подходы повышения своей устойчивости от стартапов до гипермасштабных ентерпрайзов в контексте victoriametrics инсталляции. чтоб было не слишком сухо в статью добавил трейдофы и ловушки которые могут поджидать на каждом уровне масштабирования. приглашаю всех оценить:
https://docs.victoriametrics.com/guides/vm-architectures

на каком вы уровне сейчас и подходит вам описанный для вашего уровня вариант?

всем девяточек, не падайте🔥

наткнулся на занятое наблюдение, хочу с вами поделиться:
https://techtrenches.substack.com/p/the-great-software-quality-collapse
суть очень простая - качество софта стало глобально ниже.
я не очень согласен с категоричностью и кликбейтностью, но с рядом вещей я реально сталкивался. например:
- "утечка памяти в кубе не страшна, все равно ж под ребутнется после ООМ"
- "а давайте кэшировать ваще все, память же дешёвая" доходило до 200 Гб кэша на инстанс

конкретно про память это довольно опасная наивная позиция особенно если есть риск угодить в своп и он будет ещё и на перформанс аффектить.

но в целом есть очень навязчивые намеки, что скоро спрос на SRE будет прям очень порядочный. что думаете?

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

https://www.linkedin.com/posts/qa-breakfast_hi-everyone-next-qa-breakfast-will-be-on-activity-7384548975028219904-naVi?utm_source=share&utm_medium=member_desktop&rcm=ACoAABWZLgcBc6KoQA5zL-6tirLS3OqRI7x4xZ0

ребята, всем привет! знайте - канал не заброшен, контент делается. ниже поделюсь подробностями.

но для начала - анонс! пару недель назад случилось для меня эпохальное событие:
я сменил работу, и теперь я часть команды VictoriaMetrics! я этому несказанно рад. буду помогать ребятам стать ещё наблюдаемее и устойчивее.
что это значит для канала:
1. будет больше постов на английском, сюда буду публиковать свои опенсорсные труды
2. будет больше контента по обсервабилити (готовые дашборды, подходы и архитектуры)
3. (я надеюсь) появится больше оффлайн митапов и онлайн евентов, где я буду присутствовать

чтобы пост не был совсем "бесполезным", расскажу что сейчас в работе:
- следующая часть the first nine guide написана на 80%. даст миру гайд о том как подходить к траблшутингу высокого латенси
- в работе большое исследование по мотивам инцидентов с хейзелкаст от моих бывших коллег, там покажем разницу между тем как сеть видит апликейшн и как сеть видит системный инженер который её дебажит
- графовый подход к обсервабилити, caretta, service dependency graph и все вокруг этого
- (ещё бэклог из 34 тем)
- ваш вариант в комментах, чтоб хотелось обсудить? любые вопросы и предложения :)

#кулстори #connectionpool

вводные:
представим, что есть у нас классный бэкенд, он готов обрабатывать много запросов, он стейтлесс, поэтому мы с вами ожидаем, что мы его легко можем замасштабировать горизонтально. для верности мы даже проведем нагрузочные тесты и по-прежнему все отлично, при пиковой нагрузке добавляем +1 инстанс и выдерживаем её.

проблема:
запускаем нашего красавчика в проде и дальше видим, что происходит ужасное, у нас в 100% cpu утилизирован 1 под. изучив логи, трейсы и другую телеметрию становится ясно - только этот под обрабатывает запросы, а остальные из ReplicaSet стоят, курят. скажите "виноват балансировщик"? смотрим дальше и выясняем, что запросы летят от соседнего сервиса (сервиса А) и ходит он по svc name, запросов довольно мало, то есть между вами никакого балансировщика нет.

что же происходит?
чтобы не тратить драгоценные миллисекунды и ресурсы на tcp-хендшейки, клиенты используют пулы соединений (connection pools). благодаря http keep-alive, однажды открытое соединение не закрывается, а кладётся в пул, чтобы его можно было быстро переиспользовать.
и вот что получается на практике:
1. наш сервис А (клиент) хочет сделать первый запрос. он обращается к dns: "дай айпишник для svc name".
2. dns честно отдаёт ему ip одного из подов сервиса Б.
3. клиент устанавливает с этим конкретным подом соединение (открывает сокет) и отправляет запрос.
4. получив ответ, он не рвёт коннект, а аккуратно возвращает его в свой пул.
когда прилетает второй, третий, сотый запрос. зачем клиенту снова идти в dns и создавать новый коннект, если есть готовенький коннек? он просто берёт его из пула. в итоге все запросы летят в один и тот же под сервиса Б, и вся наша красивая схема с горизонтальным масштабированием не работает.

как решить проблему?
например, можно пустить трафик через ингресс - через него идет, скорее всего, много трафика и поэтому пулы коннектов будут шире. в таком случае нжинкс или любой другой балансировщик будет держать свой набор сокетов и коннектов к сервису Б, за счёт чего размажется трафик. это добавляет латенси, но вот прям элегантные решения пока не нашел :)

знайте! ваши запросы не балансируются через service ip сущность кубрнетеса, через нее происходит только резолвинг, а сами коннекты в итоге устанавливаются pod2pod, и запросы летят тоже pod2pod

#performance #talks #podcast #teammanagment

каюсь, это не хардкор и кровавое SRE, но, в качестве исключения, представляю вам среднетехнический митап о том как строить команды нагрузочного тестирования.

доклад посвящен предстоящему perf conf 11, это моя домашняя площадка, там меня можно найти в программном комитете. много хорошего контента про перформанс и вокруг, но пост не про пиар (хотя за промокодом со скидкой на тикеты заходите в личку), пост про пользу, которая ждёт вас по ссылке ниже:

https://rutube.ru/video/9f233288afdb50c1bc33f783aabffef8/

в нем обсуждали:
- подходы к формированию команд
- тесты на проде
- перформанс окружения и их сходимость
- и конечно же AI

#firstnine #architecture #systemdesign #sre #containerawareness #deploy

привет всем! почти месяц писал эту статью (а до этого пол года активно собирал знания для нее). практически все покрыл опытами и, уверен, это будет полезно. в будущем постараюсь переключаться на посты попроще, чтобы в канале была жизнь :)

итак, я много до этого писал про container awareness. это та штука за счет которой рантайм может использовать параметры контейнера. за много лет практики мы наверное сотню раз решали инцидент просто тем, что ставили GOMAXPROCS/ActiveProcessorCount и подобное. вместе с этим частая беда это абсолютно необъяснимый и беспощадный троттлинг. совместив полезное с полезным и попутно не забывая про эффективный параллелизм и перформанс представляю вам новую часть эпопеи и битвы за первую девятку.

буду рад посмотреть на ваш опыт, чтобы отразить его в статье и она стала еще более полезной, так что залезайте в комментарии.

https://telegra.ph/Ideal-application-deployment-07-15

#slo #techtalk #podcast

собрались мы тут значит и решили пообщаться на тему SLO под запись и с камерами - ну вдруг это кому-то будет интересно! :)

идея пришла после ряда классных дискуссий в нашем уютном SLO-комьюнити. в итоге так увлеклись, что это все превратилось в подкаст.
на самом деле пообщались лампово, без крамольных мыслей или шокирующих фактов.
на подкасте:
- обсудили, как подходим к оценке критичности пользовательского пути
- где можно избежать переусложнения в реализации SLO
- может ли быть SLO на постгрес или кубернетес

посмотреть можно вот тут:
- YouTube
- ВК Видео
- RuTube

записывались на площадке @avitotech - за монтаж отдельный лайк ребятам. моими соподкастерами были Паша и Дима - с ними было очень интересно и теперь надеюсь на продолжение!

#firstnine #architecture #systemdesign #sre

привет всем! мы продолжаем строить первую девяточку. и это будет последняя абстрактная часть в рамках цикла статей The First Nine!

сегодня написал на тему, на которую вообще не смог найти контента. это тема внутренного устройства микросервиса/бэкенда/веб-сервера. каждый раз при траблшутинге внутренних проблем встречаю изобилие мифов и фантазий на тему того из чего состоит бэкенд. какие-то блоки у многих похожи, какие-то уникальны.

это навело меня на мысль, что нужен какой-то более менее оформленный подход или фреймворк для общения в ситуациях, когда "нет времени объяснять таймаут в горутинах, которые копятся ожидая пул к БД". плюс ко всему в дальнейшем буду часто делать отсылки к этим объектам, поэтому будем считать, что это в том числе и некий глоссарий.

https://telegra.ph/Typical-web-application-inner-architecture-07-13

#slo #errorbudget #sre #загадкивселенной #туловина

ранее я коротко упоминал о том как мы считаем SLO и бюджеты ошибок, на примере дашборда. совсем недавно классное коммьюнити ALL SLO создало гитхаб репо с форком эпически популярного sloth, который планируем развивать силами коммьюнити.

прямо сейчас, я со своей командой как раз занимаюсь селекшном какого-то чудодейственного тулинга, который:
1. позволит держать децентрализовано ямлы, в которых как-то не слишком сложно описаны sli, slo, метрики и все необходимое для расчета
2. отрендерит это в Recording Rule с унификацией и возможностью докинуть лейблов
3. постоит прозрачно error budget за заданный период (с привязкой к календарю или скользящим окном), даст отдельно метрику берн рейта и будет считать текущий показатель доступности

мы посмотрели много раз на sloth, у него явно есть проблемы с error budget, но главное - методика расчета доступности в моменте очень непрозрачная, объяснить разработке почему показатель не 99.9, а 99.7 довольно нетривиальная задачка.
еще мы протестировали Pyrra, который как будто по описанию нам идеально подходил, но обнаружили интересную ситуацию, где при скользящем окне еррор баджета в 2 недели бюджет восполнялся внутри этого периода!
сейчас мы смотрим на Google SLO Generator и пытаемся обложить его костылями, чтобы закрыть наши потребности.

в общем, все кому интересно работать с SLO, приглашаю в гитхаб и в чатик коммьюнити
а все, кто хочет поделиться секретными знаниями, как сделать жизнь с SLO на больших масштабах простой и прозрачной для всех - жду ваши рекомендации в комментах!

#sre #ratelimits #кулстори

представьте, сидите вы как всегда никого не трогаете, и тут инцидент - все горит, пришла слишком большая нагрузка на систему. каким-то образом удается потушить и сразу переносимся на стадию разбора инцидента. идет брейшторм по тому как выстраивать защиту от таких бед и тут какой чрезвычайно опытный и достопочтенный инженер говорит: "да давайте просто рейтлимиты бахнем и сё!?".

ну а мы с вами давайте разбираться, есть ли у нас причины не бахнуть рейтлимитов то?
а они есть:
1. если рейтлимитить запросы в лоб - например 1000 рпс, то вы рискуете разрушить пользовательскую сессию в абсолютно неудачном месте. представим что 1001 запрос всегда будет авторизацией, все работает а она нет, во чудеса.
2. хорошо, а может как-то per IP сделаем? плохая идея - большие кампусные сети, где тысячи сотрудников за одним айпи вас удивят и ботов в ботнете делают так много, чтоб рейтлимит их не видел.
3. тогда по умному прокинем сессию юзера во все сервисы, и не будем пускать новых пользователей если системы перегружены? ну вот это уже не дурно, но это уже целый admission control и все равно есть еще ряд проблем.
4. текущие рейты надо где-то хранить, а еще проверять на каждый запрос иначе вы при каждом горизонтальном масштабировании ваших реплик апигейтвея или балансировщика будете повышать суммарные лимиты.
5. ну и если вы их храните и проверяете на каждый запрос, будьте готовы что ваши стейтлес сервисы станут очень зависимы от базы данных/кэша в которых рейты будут жить и этот поход добавит латенси вашим пользователям и станет потенциальным узким местом.
6. финальная проблема - за рейт лимитами надо следить, адаптировать и менять с течением времени и внезапно приходящая легитимная нагрузка, которая упоролась в забытый рейтлимит это крайне распространенный кейс.

как готовить рейтлимиты? (спойлер: не просто)
1. адаптивный троттлинг (лимиты на основе p99 latency/CPU usage) - забываем статические лимиты, не забываем вкручивать еще burst лимиты и скользящее окно
2. контекстные рейтлимиты по юзер сценарию (авторизованные и неавторизованные, на странице платежки или только проходят онбординг)
3. все обмазываем метриками и алертами
4. а лучше использовать такие практики как:
tarpit/backpressure с повышением латенси вместо дропов, circuit breaker, deadline propagation, fail fast на гейтвеях, graceful degradation и retry budget. про них будет в следующих сериях!

давайте ответим достопочтенному инженеру, что мы серьезно подумаем над его предложением и с ходу не будем пока ничего бахать :)
а на досуге почитать:
https://developers.google.com/speed/protocols/trickle_tech_report.pdf
https://aws.amazon.com/ru/blogs/architecture/rate-limiting-strategies-for-serverless-applications/

#firstnine #runtimes #sre

да, сегодня снова душная теория - обещаю, что буду разбавлять чем-то приземленным :)

предыдущих сериях разбирались с функцией, теперь пришло время понять как запускать эти все функции. запускать много и желательно сразу!

https://telegra.ph/Runtime-models---kak-zapuskat-tysyachi-funkcij-odnovremenno-06-22

#firstnine #bigO #sre

формат телеграма слишком тесный для большинства тем, которые я хочу осветить, поэтому я буду пробовать разные варианты - сегодня это instant view через посты в telegra.ph

поговорим мы про один из самых фундаментальных блоков наших любимых сервисов - функцию. очень часто во время траблшутинга до них руки не доходят, это оправдано потому как понимание узких мест кода - это трудоемкая задачка. но бывают вынужденные ситуации, когда проблема 100% в логике кода и сейчас век ллмок - они вам помогут сказать, чтож там происходит если стало тяжело (но я в нас верю!). в свою очередь я хочу дать более менее универсальный подход оценки функции

https://telegra.ph/Function-the-atomic-unit-of-code-06-12

The Last of 9s pinned a photo

#firstnine #perfguide #sre #observability


анонс, который в будущем можно юзать как пост для навигации по контенту.
длительное время я собирал "The First Nine Guide" - огромный excalidraw документ, с 9 (символично!?) блоками про базовые вещи, которые необходимы для достижения многодевяток, другими словами вот первая девятка. он начинается от software инженерии плавно переходя в системные слои. я его долго собирал на основе своих граблей, чужих граблей и просто исследований. цикл статей по нему, будет одной из главных веток в канале. далее хочу перейти к систем дизайну среднего масштаба и гиганского :)

1. function: the atomic unit of code (сложность функции, типы функции и что такое call stack)
[классификация функций и О-нотации]
2. runtime models (как эти функции запускаются, когда их много, кто ими управляет и как выбрать рантайм)
[виды рантаймов и особенности]
3. typical application inner-architecture (из чего состоит любой бэкенд, базовые блоки, которые могут создавать ботлнек)
[архитектурная повесть о царстве веб-сервисном]
4. ideal app to container (когда вы написали совершенный код, как его положить в контейнер, чтоб в проде не рвануло)
[тут готовили JVM и тут сводная табличка по рантаймам и их контейнерности а вот сразу общий гайд про много рантаймов]
5. os threads and binding (любой рантайм общается с OS, через универсальный мостик - os thread и как понять куда утекает время)
6. parallelism and concurrency (как конкурентность и параллелизм приземляются на процессор)
[ был пост про JVM память с оверкоммитом - утащил его сюда]
7. network processing parallelism (сетевые ботлнеки, irq, softirq, epoll, где смотреть и как не упереться в один vcpu)
8. container 2 container (наш контейнер и код идеальны, где может быть ловушка в общении с соседом)
9. memory & storage (общаемся с памятью без боли и разбираемся что ж там происходит)