---
title: "Знакомство с Prometheus: почему сервис молчит, а падает"
description: "Мониторинг go-сервиса с Prometheus: SLI, SLO и pull-модель. Разбираем, почему логи не заменяют метрики, как устроен скрейп и с чего начинается курс."
course: "Мониторинг Go с Prometheus: метрики, Grafana, алерты"
url: "https://golangmaster.ru/courses/prometheus/lessons/01-znakomstvo-prometheus/"
published: "2026-09-19"
updated: "2026-09-24"
minutes: 16
---

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

*Курс «Мониторинг Go с Prometheus: метрики, Grafana, алерты», урок 1 из 25. ~16 минут. Обновлено 24.09.2026. Источник: https://golangmaster.ru/courses/prometheus/lessons/01-znakomstvo-prometheus/*

Мониторинг go-сервиса начинается там, где кончаются логи: в три ночи важнее не то, какая строка упала, а насколько быстро деградирует система — и это территория Prometheus. Разберём, что такое SLI и SLO, почему Prometheus сам приходит за вашими метриками и как устроен курс.

Пятница, вечер релиза. Через двадцать минут после деплоя поддержка пишет: «оплата висит». Вы открываете логи — они есть, строки пишутся, ошибки тоже где-то там, между двумястами тысячами строк успеха. На вопрос «насколько всё плохо?» логи не отвечают: чтобы узнать, что доля неудач выросла за минуту с одного процента до сорока, надо прогнать агрегацию по логам, а это минуты. Пока вы считаете, пользователи уходят. Именно эту дыру закрывают метрики: заранее заведённые числа, которые сервис отдаёт наружу по запросу, а система мониторинга складывает их в базу временных рядов и рисует график за секунду. Prometheus — фактический стандарт таких систем в мире Go: под ним собран Kubernetes, а официальный клиент для Go называется client_golang, и к концу курса вы будете писать сервисы, которые сами рассказывают о себе числами. Начнём со словаря: SLI, SLO, pull-модель — язык, на котором говорят и разработчики, и дежурные.

### Мониторинг go-сервиса: логи, метрики, трейсы

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

### SLI и SLO: цели, в которых живут метрики

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

### С чего начать: три цели вместо двадцати графиков

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

> **Логи не заменяют метрики.** Проверка «а посчитаем по логам» работает один раз и падает на проде: агрегация по сотням миллионов записей стоит секунд и денег, а расчёт по метрике — миллисекунды и копейки. Обратное тоже верно: метрики не заменяют логи — число «сорок процентов ошибок» не говорит, что это за ошибка. Это разные инструменты, и спорить, какой из них главный, — время впустую.

### Pull-модель: Prometheus сам приходит за данными

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

### prometheus.yml: так Prometheus узнаёт про ваш сервис

```go
# prometheus.yml
global:
  scrape_interval: 15s

scrape_configs:
  - job_name: "shop"
    static_configs:
      - targets: ["localhost:8080"]
```

Конфиг уровня туториала: раз в пятнадцать секунд Prometheus обращается к localhost:8080 — тому самому /metrics из примеров курса — и складывает ответ в свою TSDB. static_configs — простейший способ перечислить цели руками; в реальном кластере их находят сервис-дискавери. Настройке скрейпинга посвящён отдельный урок второй половины курса.

### Так выглядит страница метрик

```go
# HELP shop_orders_total Всего созданных заказов с запуска сервиса.
# TYPE shop_orders_total counter
shop_orders_total 1042
# HELP shop_queue_size Текущая длина очереди заказов.
# TYPE shop_queue_size gauge
shop_queue_size 17
```

Формат экспозиции — простой текст, который читает и человек, и curl. Строка HELP — человекочитаемое описание, TYPE — тип метрики, дальше имя и значение. Ответ отдаётся с Content-Type text/plain, а более компактную форму сервер и клиент согласуют заголовком Accept. Такой файл покажет любой go-сервис с client_golang — соберём его в третьем уроке.

### Кто построил Prometheus и почему ему доверяют

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

### Три источника правды: чем они отличаются

| Инструмент | Отвечает на вопрос | Скорость ответа | Цена хранения |
| --- | --- | --- | --- |
| Логи | что именно произошло | секунды и минуты | высокая: каждый запрос — запись |
| Метрики | насколько плохо и растёт ли | миллисекунды | низкая: числа в TSDB |
| Трейсы | где по пути застрял запрос | секунды | средняя: часть запросов сэмплируется |

> **Графики без дежурства — фотобудка без плёнки.** Самый частый сценарий провала мониторинга: дашборды собраны, красивые, висят на экране, который выключен. Метрика без алерта — фотография прошлого: о проблеме вы узнали, когда позвонил клиент. Правило курса: у каждой метрики, которую вы заводите, должен быть ответ на вопрос «по какому условию кто-то должен отреагировать». Если ответа нет — метрика для красивой картинки, и место ей не на дежурном экране. Алертам посвящён отдельный урок второй половины курса.

### Инцидент: метрика была, алерта не было

История, которая объясняет, зачем вся эта дисциплина. У сервиса маркетплейса был образцовый мониторинг: трафик, латентность, очереди, большой экран в переговорке. В ночь распродажи платёжный провайдер начал отбивать часть запросов таймаутами, и метрика доли ошибок честно поползла вверх — с полпроцента до восемнадцати за сорок минут. Звонка не было: алерт стоял на двадцати пяти процентах, до порога значение не дотянуло, а экран в переговорке никто не смотрел — дежурил человек, у которого этот дашборд не был открыт. Сервис лежал два часа, при этом каждая метрика «работала»: данные собирались, графики рисовались, ничего не кричало. Мораль не в том, что метрики не работают, а в том, что работают условия: у метрики должно быть условие срабатывания, канал доставки и человек, который получит уведомление. Как это устроено — [отдельный урок про алерты](/courses/prometheus/lessons/14-alerts-obzor/), пока же запомните: зелёный дашборд не отвечает на вопрос, жив ли бизнес.

### Проверка: кто инициирует сбор метрик

**Вопрос:** Как в pull-модели метрики попадают из вашего сервиса в базу Prometheus?

- Сервис сам отправляет метрики на сервер после каждого запроса
- ✅ Prometheus периодически сам делает GET-запрос к /metrics сервиса
- Метрики приходят из логов, которые Prometheus парсит
- Сервис пишет метрики в файл, Prometheus читает файл

Prometheus с заданным интервалом сам опрашивает цели из prometheus.yml и парсит HTTP-ответ на /metrics. Если опрос не удался, цель помечается недоступной — метрика up получает значение ноль, и это тоже данные.

### Проверка: SLI против SLO

**Вопрос:** Утверждение «девяносто девять и девять десятых процента запросов за месяц должны ответить быстрее трёхсот миллисекунд» — это что именно?

- SLI — индикатор
- ✅ SLO — целевое значение
- SLA — договор с клиентом
- Скрейп-интервал

Целевое значение по индикатору — SLO. Само измерение — например, текущая доля быстрых ответов — SLI, а договор с последствиями — SLA. Разница между целью и реальностью — бюджет ошибок.

### Что означает значение счётчика

```go
# HELP shop_orders_total Всего созданных заказов.
# TYPE shop_orders_total counter
shop_orders_total 812
```

**Что выведет программа?**

- Ровно 812 — значение и есть число заказов за последний час
- ✅ Неизвестно: 812 — накопление с запуска процесса, скорость даст rate() по временному ряду
- 812 в секунду — Prometheus сам делит на интервал
- Ответ есть только в логах

Counter — накопленное с запуска процесса значение, времени внутри него нет. Скорость получает запрос rate() по окну. Поэтому в дашбордах почти никогда не рисуют сырое значение счётчика — рисуют его прирост.

### Соберите фрагмент экспозиции

Восстановите служебные строки формата экспозиции: описание, тип и строку значения.

```go
# ___ shop_orders_total Всего созданных заказов.
# TYPE shop_orders_total ___
___ 812
```

Подсказка: Описание метрики — HELP; счётчик объявляется типом counter; строка значения начинается с имени метрики.

Правильные ответы в пропусках: `HELP`, `counter`, `shop_orders_total`

### Соберите путь метрики по цепочке

Расставьте шесть шагов в порядке, как метрика доходит от кода до графика.

Правильный порядок строк:

1. `В коде сервиса значение метрики увеличивается`
2. `http.Handle("/metrics", promhttp.Handler())`
3. `Prometheus читает цель из prometheus.yml`
4. `Prometheus делает GET /metrics каждый scrape-интервал`
5. `Значение попадает в TSDB как временной ряд`
6. `Grafana рисует график по PromQL-запросу`

### Карточки: словарь Prometheus

- **Prometheus** — Система мониторинга и алертинга с pull-моделью: сама опрашивает /metrics целей и хранит значения как временные ряды. Родом из SoundCloud 2012, в CNCF с 2016.
- **SLI** — Service level indicator — само измерение: доля успешных запросов, перцентиль латентности. То, что вы считаете.
- **SLO** — Service level objective — цель по SLI на период: девяносто девять и девять десятых процентов быстрых ответов за месяц. Разница с реальностью — бюджет ошибок.
- **Pull-модель** — Prometheus сам ходит за метриками: GET /metrics раз в scrape-интервал. Недоступная цель — не протухшие данные, а честная метрика up со значением ноль.
- **client_golang** — Официальная Go-библиотека Prometheus: типы метрик, реестр и promhttp.Handler() для net/http. Герой всего курса.
- **TSDB** — База временных рядов внутри Prometheus: каждая точка — значение метрики с меткой времени. Заточена под графики и алерты, не под долгую бухгалтерию.

Курс — двадцать пять уроков: сначала четыре типа метрик и практика с client_golang, потом лейблы, гистограммы, HTTP-метрики и бизнес-числа, во второй половине — PromQL, Grafana, алерты и итоговый проект с полным мониторингом веб-сервиса. Карта всех тем — на [странице курса](/courses/prometheus/). Практика пойдёт сразу: в следующем уроке поставим client_golang и за пять минут поднимем [первый /metrics endpoint](/courses/prometheus/lessons/03-ustanovka-client-golang/), а перед этим разберём [четыре типа метрик](/courses/prometheus/lessons/02-tipa-metrik/) — решение, которое принимается до строчки кода. Одна честная оговорка: песочница сайта не умеет TCP-серверы, поэтому код курса запускается локальным Go — установка с go.dev стандартна для всех систем, и примеры дальше проверялись именно так. Логи в этой истории тоже участвуют: их лучше вести структурно, как учит [курс про zap](/courses/zap/), — на стыке метрик и логов позже будет отдельный урок про корреляцию инцидентов.

## Коротко: что запомнить

- Метрики отвечают на «насколько плохо», логи — на «что именно случилось»; мониторинг начинается с чисел, а не с grep.
- SLI — измерение, SLO — цель по нему; разница между ними — бюджет ошибок.
- Pull-модель: Prometheus сам делает GET /metrics каждый scrape-интервал; недоступность цели — метрика up со значением ноль.
- Формат экспозиции — текст: строки HELP, TYPE и имя-значение.
- Prometheus — SoundCloud 2012, второй проект CNCF после Kubernetes; официальный клиент для Go — client_golang.
- Метрика без ответа «кто и когда должен отреагировать» — картинка, а не мониторинг.

## Домашнее задание

Проверьте себя без кода: сформулируйте SLI и SLO для сервиса, который знаете, — два-три показателя и целевые значения. Потом перечитайте раздел про pull-модель и ответьте письменно: что увидит Prometheus, если цель недоступна, и почему это лучше протухших данных. В следующем уроке пойдёт установка client_golang — подготовьте локальный Go, понадобятся go mod init и go get.

## Вопросы и ответы по уроку

### Нужен ли сервер Prometheus, чтобы начать курс?

Нет. Первые уроки — про код метрик в Go: он пишется и проверяется локально, без сервера. Полный цикл со скрейпом и Grafana появится в середине курса, с пошаговой инструкцией Docker Compose.

### Чем метрики отличаются от логов?

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

### Почему Prometheus тянет метрики сам, а не получает их push-ом?

Pull даёт честное состояние: недоступный сервис виден по метрике up, а не по протухшим данным, а код сервиса не зависит от системы хранения. Для короткоживущих задач есть pushgateway — исключение, о котором расскажет урок про скрейпинг.