Знакомство с Prometheus: почему сервис молчит, а падает

Три столпа наблюдаемости отвечают на три разных вопроса. Логи рассказывают, что именно произошло внутри: конкретная запись с идентификатором заказа и стеком ошибки — про это отдельный курс про структурные логи, если вы ещё не читали. Метрики отвечают на вопросы «сколько» и «как быстро»: запросов в секунду, доля ошибок, время ответа на девяносто девятом перцентиле. Трейсы показывают путь запроса через сервисы: где он застрял, какой из пяти внешних вызовов съел четыреста миллисекунд. Ключевая разница — в цене и скорости. Лог — событие, их миллионы, и запрос к ним стоит секунд и денег на хранение. Метрика — число, которое живёт в памяти как временной ряд, и график по ней строится за миллисекунды. Поэтому при разборе инцидента порядок всегда один: алерт по метрике говорит «доля ошибок выросла», метрика же сужает область — «только у платежей», и уже потом логи объясняют почему. Мониторинг go-сервиса начинается не с логов, а с трёх-четырёх метрик, которые показывают, жив ли сервис и насколько ему плохо.

Без целей мониторинг превращается в коллекцию графиков, на которые никто не смотрит. SLI, service level indicator, — само измерение: доля успешных запросов, девяносто девятый перцентиль латентности, доля ответов быстрее трёхсот миллисекунд. SLO, service level objective, — цель на это измерение: за месяц девяносто девять и девять десятых процента запросов должны получить ответ быстрее трёхсот миллисекунд. Разница между реальностью и целью — бюджет ошибок: пока он не исчерпан, релизиться можно, когда сгорел — команда чинит надёжность вместо фич. Записывается это «девятками»: два девятки — до семи часов недоступности в месяц, три — до сорока трёх минут, четыре — до четырёх с половиной. Каждая девятка стоит дорого, поэтому SLO ставят по данным, а не по амбициям. Для этого курса важна не бухгалтерия, а следствие: чтобы цель вообще можно было проверить, её показатели должны быть метриками — и вы заведёте их уже в первых уроках.

Если SLO в вашей практике пока не прижились, начните с минимального набора, закрывающего большую часть разговоров о здоровье: доступность — доля успешных ответов, латентность — доля ответов быстрее порога, свежесть — возраст последних обработанных событий у фоновых задач. Три измерения, три цели на месяц, одна страница. Остальное — гистограммы, бизнес-числа, перцентили — добавится, когда научитесь на эти три отвечать быстрее, чем падает сервис. Спорное мнение, за которым годы опыта: маленькому сервису SLO нужнее, чем большому. У большого есть дежурные, регламенты и привычка к числам; у маленького вместо них ощущение «вроде нормально», которое разваливается при первом ночном инциденте. Одна строчка цели дисциплинирует разговор о надёжности сильнее любого процесса — а в спорах «четыре девятки или пять» я голосую за четыре: вторая девятка стоит дороже всей остальной разработки.

Prometheus — система с pull-моделью: он не ждёт, пока сервис пришлёт метрики, а сам раз в интервал делает HTTP GET на адрес цели и читает ответ. Адрес, обычно /metrics, и интервал, по умолчанию одна минута, задаются в конфиге prometheus.yml. Привыкшие к push-моделям сначала путаются: «а если сервис умер, кто-то отправил последнее значение?» В pull-мире ответ элегантнее: если Prometheus не смог забрать метрики — цель помечается как недоступная, и это само по себе метрика, самая важная в вашей системе. Мёртвый сервис виден не по протухшим данным, а по честному значению ноль у метрики up. Второй плюс: сервис ничего не знает о месте хранения — он просто держит HTTP-эндпоинт; Prometheus можно останавливать, переносить, ставить второй — код сервиса не меняется. Цена: за сервисом, который спрятан за NAT, надо строить мосты — pushgateway или сервис-дискавери, это темы второй половины курса. В Go-мире вся подготовка к pull-модели умещается в один хендлер, и увидим мы его через урок.

Prometheus вырос в SoundCloud в 2012 году: инженеры смотрели на внутреннюю систему Google Borgmon и собрали её открытый аналог для своих нужд. С 2016 года проект — второй по счёту выпуск CNCF после Kubernetes, и сегодня это де-факто стандарт мониторинга облачных систем: под ним живут и сам Kubernetes, и большая часть экосистемных компонентов. Для нас важнее другое: у проекта есть официальный клиент для Go — client_golang, библиотека, вокруг которой построен весь курс. Запросы вроде prometheus golang в поисковиках — это обычно поиск именно её: типы метрик, реестр и готовый HTTP-хендлер в одном пакете. Формат экспозиции определён как стандарт, поэтому его понимает любой инструмент — от Grafana до систем алертинга, — и знания переносятся между стеками. Про масштаб тоже честно: собственная TSDB Prometheus заточена под временные ряды и держит сотни тысяч метрик на скромном железе, но не под бесконечную бухгалтерию — долгое хранение отдают внешним системам.

История, которая объясняет, зачем вся эта дисциплина. У сервиса маркетплейса был образцовый мониторинг: трафик, латентность, очереди, большой экран в переговорке. В ночь распродажи платёжный провайдер начал отбивать часть запросов таймаутами, и метрика доли ошибок честно поползла вверх — с полпроцента до восемнадцати за сорок минут. Звонка не было: алерт стоял на двадцати пяти процентах, до порога значение не дотянуло, а экран в переговорке никто не смотрел — дежурил человек, у которого этот дашборд не был открыт. Сервис лежал два часа, при этом каждая метрика «работала»: данные собирались, графики рисовались, ничего не кричало. Мораль не в том, что метрики не работают, а в том, что работают условия: у метрики должно быть условие срабатывания, канал доставки и человек, который получит уведомление. Как это устроено — отдельный урок про алерты, пока же запомните: зелёный дашборд не отвечает на вопрос, жив ли бизнес.