Каждый в отдельности

• Метрики хранят числовые ряды, агрегаты по времени. Дёшевы и, что важнее, предсказуемо дёшевы: стоимость не зависит от rps, потому что хранишь ты не события, а счётчики. Отсюда их роль: обнаружение и алертинг. Упираются они в жёсткую кардинальность: как только захочешь разложить метрику по пользователям, система умрёт.
• Логи состоят из дискретных событий с произвольным содержимым и произвольной кардинальностью. Дают точную причину: сообщение об ошибке, стек, значения полей. Ломаются на объёме (стоимость растёт линейно с трафиком) и на том, что общей картины не дают: по логам невозможно ответить «стало ли хуже, чем на прошлой неделе», а если логи сэмплируются, то счёт по ним ещё и неверен.
• Трейсы собирают дерево спанов одного запроса с таймингами. Единственный инструмент, который отвечает на «где потерялось время» в распределённой системе. Стоят дорого, поэтому почти всегда сэмплируются: конкретного запроса пользователя может просто не оказаться. Плюс слепые зоны: то, что не обёрнуто спаном, выглядит как дыра.

Чего не даёт каждый - то, ради чего задают вопрос

Зачем структура

log.Printf("user %s failed: %v", id, err) нельзя ни отфильтровать по пользователю, ни посчитать «сколько таких за час», ни связать с трейсом. Остаётся грепать регулярками по чужому форматированию. Для бэкенда логов структурированная запись ({"level":"error","msg":"payment failed","user_id":"u-42","trace_id":"4bf9…"}) уже документ, по которому работают индексы. Отдельный нюанс: msg должен быть постоянным, а всё переменное уходит в атрибуты, иначе одинаковые по смыслу события не сгруппируются.

Архитектура slog

• У Handler четыре метода (Enabled, Handle, WithAttrs, WithGroup). Именно он решает, какой будет формат (JSONHandler для прода, TextHandler для локальной разработки), какой минимальный уровень, добавлять ли source и как через ReplaceAttr централизованно вырезать секреты.
• With(attrs...) возвращает новый Logger с предвычисленными атрибутами. Записи от него дешёвые (Handler получает атрибуты через WithAttrs, и встроенные хендлеры форматируют их один раз, прямо при этом вызове), поэтому это правильный способ носить контекст: service, version, request_id, trace_id.
• Group заворачивает атрибуты во вложенный объект JSON: slog.Group("http", slog.String("method", …), slog.Int("status", …)) даёт "http": {"method": …, "status": …}. В бэкенде с маппингом полей получатся http.method и db.method: одна тема лежит под общим префиксом, и одноимённые ключи разных групп не сталкиваются, хотя полей в маппинге от этого не меньше.
• LogAttrs(ctx, level, msg, attrs...) обходится без промежуточных аллокаций и потому годится для горячего пути.
• LogValuer даёт типу самому решать, как он выглядит в логе. Тип Secret, чей LogValue() возвращает [REDACTED], прячет значение от логгера по построению, а не по дисциплине. Но структуру с таким полем JSON-хендлер отдаст в encoding/json, и без своего MarshalJSON секрет уйдёт в лог.
• Контекстный логгер. Middleware кладёт логгер с полями запроса в context.Context, а нижние слои достают его оттуда, и trace_id попадает в каждую запись без ручной передачи.

Уровни: правило выбора

• DEBUG нужен только разработчику и только на время. В проде выключен; slog.LevelVar позволяет включить его на лету через админ-эндпоинт, не перезапуская под. Приём выручает.
• INFO отмечает значимые события нормальной работы: старт с версией, смену конфигурации, важные бизнес-события. Не «зашли в функцию».
• WARN ставят на аномалию, с которой справились: ретрай удался, ушли на фолбэк, приблизились к лимиту. Никого не будим, но следим за частотой.
• ERROR значит, что операция не выполнена и кто-то пострадал. Алертить надо по частоте ERROR, а не по каждой записи.

Обязательный минимум записи

• timestamp в UTC (RFC3339 с миллисекундами), level, постоянный msg.
• service, version, env, pod, иначе в общем хранилище логов непонятно, чей это лог и какой версии.
• request_id и trace_id/span_id.
• Идентификаторы сущностей: order_id, внутренний user_id (внутренний UUID, не email и не телефон).
• Исход операции: status, duration_ms, route как шаблон, размер ответа.
• Для ошибок нужен классифицированный тип/код (timeout, conflict) плюс AddSource, чтобы знать файл и строку.
• События жизненного цикла: старт с версией и конфигурацией (без секретов), получен SIGTERM, завершён shutdown. Именно это спасает, когда разбираешь странные рестарты.

Чего быть не должно - и почему это не паранойя

• Секреты: пароли, токены, ключи API, Authorization, куки сессии. Лог с токеном даёт действующий доступ, и лежит он в системе, открытой всей команде и всем подрядчикам по мониторингу.
• Платёжные данные: PAN и CVV в логе нарушают PCI DSS напрямую, вплоть до потери возможности принимать карты.
• Персональные данные: email, телефон, адрес, ФИО, документы. Помимо закона есть практическая проблема: удалить пользователя по запросу «право на забвение» из логов почти невозможно.
• Тела запросов и ответов целиком. Самая частая причина утечки: сегодня в теле безобидный JSON, завтра туда добавили паспорт. Плюс непредсказуемый объём: один эндпоинт с большим ответом может кратно увеличить счёт за логи.
• Полные URL с query-параметрами: туда попадают токены сброса пароля, поисковые запросы, реферальные метки.
• %+v по структуре даёт то же самое, только с отсрочкой: структура обрастёт полями, и никто не вспомнит про лог.

Механика

1. Генерируем на входе. Первый компонент (ingress или edge-сервис) проверяет X-Request-Id; если его нет, генерирует UUID. Доверять входящему значению от внешнего клиента можно только с валидацией (длина, алфавит), иначе получишь инъекцию мусора в логи.
2. Кладём в контекст и в логгер. Middleware создаёт логгер slog.With("request_id", …, "trace_id", …) и кладёт его в context.Context. Все слои ниже берут логгер из контекста и получают поля автоматически.
3. Возвращаем клиенту. X-Request-Id в заголовке ответа и в теле ошибки. Тогда пользователь из поддержки называет одну строку, и по ней находится всё.
4. Прокидываем дальше. В исходящие HTTP-запросы кладём заголовками (traceparent добавляет otelhttp сам, если задан глобальный пропагатор, иначе заголовка не будет; X-Request-Id ставит свой middleware на транспорте), в gRPC метаданными, в Kafka заголовками сообщения.

// Транспорт сам кладёт request_id во все исходящие вызовы
type ridTransport struct {
    base http.RoundTripper
}

func (t ridTransport) RoundTrip(r *http.Request) (*http.Response, error) {
    if id := RequestIDFrom(r.Context()); id != "" {
        r = r.Clone(r.Context())
        r.Header.Set("X-Request-Id", id)
    }
    return t.base.RoundTrip(r)
}

client := &http.Client{
    Transport: otelhttp.NewTransport(ridTransport{http.DefaultTransport}),
}

Связь лога и трейса - в обе стороны

• Трейс → логи. В UI трейсинга виден медленный или упавший спан; по его trace_id открываешь фильтр в логах и получаешь все записи всех сервисов по этому запросу. Grafana умеет делать это одной кнопкой (настройка trace to logs у источника данных Tempo).
• Логи → трейс. Нашёл ошибку в логе и оттуда же открыл трейс. Работает только если trace_id есть в логе и этот трейс был сохранён при сэмплировании (см. флаг sampled в traceparent: логировать его тоже полезно, чтобы понимать, почему трейс не нашёлся).
• Метрика → трейс. Exemplars: к точке гистограммы прикрепляется trace_id одного из наблюдений. Кликнул по всплеску на графике p99 и сразу оказался в конкретном медленном трейсе. Это лучший из существующих переходов, и его мало кто настраивает.

Что даёт pull

• Мониторинг доступности бесплатно. Синтетическая метрика up появляется сама: цель не ответила, значит, недоступна. В push-модели «сервис молчит» и «сервис умер» неразличимы без отдельного механизма heartbeat.
• Нельзя завалить отправками. Частоту сбора определяет Prometheus. В push-модели взбесившийся сервис (или сотня новых подов) уложит приёмник, а это ровно тот момент, когда мониторинг нужнее всего. От взрыва числа рядов pull, правда, не защищает.
• Простота приложения. Оно держит счётчики в памяти и умеет отрендерить текст. Никаких очередей, ретраев, буферов и «что делать, если бэкенд лежит».
• Отладка и воспроизводимость. curl localhost:8081/metrics покажет те же значения, что видит мониторинг (exemplars - только с заголовком Accept для OpenMetrics). В push эту точку наблюдения приходится изобретать.
• Естественная работа с несколькими потребителями: два Prometheus (прод и разработчик) независимо скрейпят одну цель, ничего не настраивая.

Чем платим

• Service discovery обязателен. В динамическом кластере адреса меняются постоянно. В Kubernetes это решено из коробки (kubernetes_sd_configs, ServiceMonitor у оператора), вне его берут Consul, файлы, DNS.
• Сетевая связность в нужную сторону. Мониторинг должен достучаться до цели: за NAT, за файрволом, на площадке клиента, в браузере пользователя pull не работает в принципе.
• Дискретизация. Всё, что произошло между скрейпами, счётчик покажет только в агрегате. Пик длиной 5 секунд при интервале 30 секунд покажется не пиком, а вшестеро меньшим ростом среднего. Всплеск gauge такой длины не виден совсем.
• Короткоживущие задачи могут завершиться раньше первого скрейпа.

Что делать с короткоживущими задачами

1. Pushgateway работает как шлюз: задача перед смертью пушит туда метрики, Prometheus скрейпит шлюз. Работает, но у него есть неприятные свойства, о которых надо знать: значения живут вечно, пока их не удалят (метрика умершего задания продолжает отдаваться и выглядит как «всё хорошо»), сам шлюз становится точкой отказа и не даёт up по исходной задаче. Правило: Pushgateway берут только для батчей уровня сервиса, никогда для обычных сервисов и никогда как «мы хотим push».
2. Для CronJob в Kubernetes часто честнее не метрики задачи, а метрики о задаче: kube_job_status_succeeded, время последнего успеха, и алерт «задача не завершалась успешно дольше N».
3. Паттерн «время последнего успеха». Батч пишет batch_last_success_timestamp_seconds, а алерт смотрит time() - batch_last_success_timestamp_seconds > 26h. Это устойчивее, чем ловить сам факт запуска.
4. OpenTelemetry Collector как компромисс: приложение шлёт OTLP push, коллектор отдаёт Prometheus-эндпоинт для скрейпа. Так живут serverless и всё, до чего мониторингу не дотянуться.
5. remote_write отдаёт уже собранные данные в долговременное хранилище (Mimir, Thanos, VictoriaMetrics). Это не «push вместо pull»: модель сбора остаётся pull.

Counter и gauge

• Counter монотонно растёт и сбрасывается только при рестарте процесса. Смысл имеет не значение, а производная: rate(x[5m]) даёт «в секунду за последние 5 минут», increase(x[1h]) - «сколько за час». Читать абсолютное значение counter-а почти всегда ошибка. Счётчики безопасны при перезапусках подов именно потому, что rate() переживает сброс на нуль.
• Gauge показывает мгновенный снимок: горутины, соединения в пуле, длина очереди, число реплик, свободное место. Здесь rate() бессмысленен, зато осмысленны max_over_time, avg_over_time, deriv() и predict_linear() («когда кончится диск»).
• Частая ошибка: делать gauge из того, что должно быть counter-ом («текущее число ошибок в минуту, посчитанное приложением»). Тогда всё, что произошло между скрейпами, теряется, и данные зависят от того, как приложение считает окно. Правильно тут только counter с rate().

Histogram против summary - главная часть вопроса

Спрашивают всё это ради одного: перцентиль не аддитивен. Из «p99 первого пода = 100 мс» и «p99 второго = 200 мс» нельзя получить p99 сервиса никакой арифметикой. Histogram решает это тем, что хранит не перцентиль, а сырые кумулятивные счётчики. Их складывать законно, и уже из суммы считается общий перцентиль. Поэтому в мире с горизонтальным масштабированием summary почти всегда неправильный выбор: он отвечает на вопрос, который никто не задавал («какой p99 у пода номер 7»).

Когда summary всё-таки уместен: одиночный инстанс (агент, демон на ноде), заранее неизвестный диапазон значений, нужна точность, а агрегировать не надо. И не забудь native histograms (эксперимент с Prometheus 2.40, стабильны с 3.8, но включаются отдельной настройкой скрейпа): они снимают главный недостаток гистограмм, подбирая экспоненциальные бакеты автоматически с заданной относительной точностью и укладывая всё в один временной ряд.

Конкретный пример взрыва

# Норма: 8 маршрутов × 5 методов × 6 кодов = 240 рядов
http_requests_total{route="/users/{id}", method="GET", code="200"}

# Добавили «на всякий случай» user_id и сырой path:
http_requests_total{path="/users/12345", method="GET", code="200", user_id="u-12345"}
#   1 000 000 путей × 1 000 000 user_id × 5 × 6 ≈ рядов больше, чем атомов в бюджете.
#   На практике: через час Prometheus занимает 40 ГиБ, свопится, потом OOMKilled.
#   Мониторинг мёртв. Инцидент разбирать нечем.

Порядок величин, полезный для ответа: один активный ряд стоит примерно 1–4 КиБ оперативной памяти в Prometheus (индекс + текущий чанк). Миллион рядов съедает несколько гигабайт только под «сейчас», плюс диск, плюс замедление всех запросов, потому что каждый селектор идёт по раздутому инвертированному индексу. Отдельно бьёт churn: ряды, которые постоянно рождаются и умирают (лейбл с версией пода, с id задачи), плохи даже при небольшом мгновенном числе, потому что индекс растёт кумулятивно за весь период хранения.

Что нельзя класть в лейблы

• Идентификаторы: user_id, order_id, session_id, request_id, trace_id.
• Сырой URL вместо шаблона маршрута. Нужен /users/{id}, а не /users/12345. И осторожно с шаблонами: если маршрут не найден, многие библиотеки подставляют сырой путь - и получается взрыв от сканера уязвимостей, который перебирает тысячи несуществующих путей. Лечится подстановкой route="__unmatched__" для 404.
• err.Error() целиком. В тексте ошибки живут айдишники, IP и таймстемпы, а нужен короткий классифицированный код: timeout, conflict, invalid_input.
• Email, IP, User-Agent дают кардинальность и заодно тащат персональные данные в мониторинг.
• Всё, что меняется при каждом деплое, если это не нужно осознанно (лейбл version оправдан для канареечного анализа, но за него платят).

Как чинить

1. Найти виновника. Страница /tsdb-status в Prometheus показывает топ метрик и топ лейблов по кардинальности. Запрос topk(10, count by (__name__)({__name__=~".+"})) делает то же самое на скорую руку. Ещё помогает promtool tsdb analyze.
2. Убрать лейбл в коде. Только это и чинит по-настоящему.
3. Отрезать на скрейпе как временная мера: metric_relabel_configs с действием labeldrop или drop по всей метрике. Работает мгновенно и не требует релиза. Но ряды, которые без лейбла совпали, Prometheus молча схлопнет в один, и значения остальных пропадут.
4. Поставить ограничения как страховку: sample_limit и label_limit в конфиге скрейпа. Цель, которая начала отдавать миллион рядов, будет отброшена целиком, и упадёт только она, а не весь мониторинг.
5. Перенести измерение туда, где ему место. Разрез по конкретному пользователю смотрят в логе или трейсе, не в метрике. А «топ-10 медленных запросов» даёт трейсинг с tail-based сэмплированием.

RED - обязательный минимум любого сервиса

# Rate
sum(rate(http_requests_total{service="api"}[5m]))

# Errors: доля, а не абсолютное число. 100 ошибок при 1 rps и при 10 000 rps значат разное
sum(rate(http_requests_total{service="api",code=~"5.."}[5m]))
  / sum(rate(http_requests_total{service="api"}[5m]))

# Duration
histogram_quantile(0.99, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

Практический трюк: одна гистограмма закрывает весь RED. У http_request_duration_seconds есть _count (это rate) и лейбл code (это errors), плюс сами бакеты (это duration). Одна метрика с тремя лейблами (route, method, code) собирает весь верхний ряд дашборда.

USE - для ресурсов

• Utilization показывает долю времени, когда ресурс занят: rate(process_cpu_seconds_total[5m]), использование диска.
• Saturation меряет длину очереди к ресурсу: run queue, ожидание в пуле соединений, лаг консьюмера, глубина очереди задач, container_cpu_cfs_throttled_seconds_total.
• Errors считает ошибки самого ресурса: сетевые дропы, ошибки диска, отказы в выдаче соединения из пула.

Что конкретно инструментировать в Go-сервисе

Почему среднее скрывает именно то, что важно

• Форма распределения. У latency есть физический минимум (сеть, диск) и нет максимума: ретраи, промахи кэша, паузы GC, блокировки в БД, «холодный» под после деплоя. Распределение всегда с длинным правым хвостом, а среднее в таком распределении даёт величину, которую не испытывает почти никто.
• Мультимодальность. Реально там обычно две горки: попадания в кэш (2 мс) и промахи (200 мс). Среднее 40 мс не соответствует ни одному реальному запросу.
• Устойчивость к деградации. Если 1 % запросов стал в 50 раз медленнее, среднее вырастет на десятки процентов - и это легко списать на шум. p99 вырастет в разы, и это видно сразу.
• Хвост не редкость, а массовое явление. Если страница делает 20 обращений к бэкенду, вероятность, что ни одно не попало в «худший процент», равна 0.99²⁰ ≈ 82 %. То есть почти каждый пятый показ страницы сталкивается с p99. При 50 обращениях получается 1 − 0.99⁵⁰ ≈ 40%, а до половины доходит только к 69 обращениям.

Что смотреть вместо: p50 даёт типичный опыт; p95/p99 показывают опыт худших пользователей, по которому и формируется мнение о продукте; p99.9 и max ловят аномалии (GC-пауза, блокировка, только что стартовавший под). Лучше держать три линии сразу: расхождение p50 и p99 само по себе диагностично. Ровное p50 при растущем p99 означает «проблема у части запросов» (одна нода, один шард, один тип запроса), а одновременный рост обоих читается как «плохо всем, ищи общий ресурс».

Почему нельзя усреднять перцентили

Перцентиль считается как порядковая статистика, а не как сумма или доля. Из p99 отдельных подов невозможно вывести p99 сервиса никакой арифметикой: среднее из «100 мс» и «200 мс» даёт 150 мс, тогда как настоящий p99 объединённой выборки зависит от того, сколько запросов обработал каждый под и как распределены их хвосты. Он может оказаться и 105, и 195 мс, но за пределы 100–200 мс не выйдет.

# Неправильно: усреднять уже посчитанные перцентили
avg(histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m])))

# Правильно: сначала складываем бакеты всех подов, потом считаем квантиль от суммы
histogram_quantile(0.99,
  sum by (le) (rate(http_request_duration_seconds_bucket[5m]))
)

Поэтому histogram и агрегируется, а summary нет: histogram хранит складываемые счётчики, summary хранит уже вычисленный несуммируемый ответ.

Почему нельзя складывать p99 разных сервисов

Фраза «p99 gateway = p99 orders + p99 payments» неверна, и по двум причинам сразу. Во-первых, медленные запросы в разных сервисах случаются в разные моменты и с разными запросами: тот запрос, который попал в хвост orders, почти наверняка не тот, который попал в хвост payments. Сумма перцентилей поэтому обычно завышает реальный p99 цепочки, хотя может и занизить. Во-вторых, вызовы могут идти параллельно, и тогда общее время не сумма, а максимум.

На вопрос «где потерялось время» отвечает не арифметика по метрикам, а трейс: он показывает распределение времени внутри конкретных медленных запросов. Метрики говорят «стало хуже», трейс говорит «вот здесь».

Алгоритм по шагам

Пусть в окне 10 000 наблюдений и такие бакеты: le=0.05 → 4200, le=0.1 → 8900, le=0.25 → 9700, le=0.5 → 9930, le=1 → 9975, +Inf → 10000.

1. Ранг: 0.99 × 10000 = 9900.
2. Счётчик ≥ 9900 впервые встречается у le=0.5 (там 9930), предыдущий бакет le=0.25 (9700).
3. Значит, искомое значение лежит внутри (0.25, 0.5].
4. Линейная интерполяция: 0.25 + (0.5 − 0.25) × (9900 − 9700) / (9930 − 9700) ≈ 0.467 с.

Почему приблизительный: внутри бакета лежит 230 наблюдений, и о них известно ровно одно - что все они в интервале (0.25, 0.5]. Функция предполагает, что они распределены равномерно, а в реальности latency скошена, и значения прижаты к левому краю. Реальный p99 тут может быть любым числом из (0.25, 0.5]: из-за перекоса он скорее ниже 0.467, но насколько, по бакетам не узнать.

Как выбирать бакеты

• От SLO. Цель «p99 < 300 мс» → обязательно нужны границы 0.2, 0.25, 0.3, 0.4, 0.5. Тогда, во-первых, перцентиль точен именно там, где это важно, во-вторых, можно вообще уйти от интерполяции и считать долю напрямую: sum(rate(..._bucket{le="0.3"}[5m])) / sum(rate(..._count[5m])) даёт «долю запросов быстрее 300 мс». Это и есть правильная формулировка SLI.
• Покрыть реальный диапазон. Дефолтные DefBuckets (0.005…10) годятся для «среднего HTTP», но для gRPC с ответами по 2 мс всё упадёт в первый бакет, а для тяжёлых отчётов уйдёт в +Inf. Посмотри на реальное распределение, прежде чем фиксировать границы.
• Экспоненциальная сетка как разумный дефолт: prometheus.ExponentialBuckets(0.001, 2, 14) покрывает от 1 мс до ~8 с. Логарифмическое разрешение соответствует тому, как мы воспринимаем latency: разница между 10 и 20 мс важна так же, как между 1 и 2 с.
• Считать цену. Каждый бакет становится временным рядом, умноженным на все остальные лейблы. 15 бакетов × 20 маршрутов × 5 методов = 1500 рядов с одной метрики, и ещё 200 добавят суммы и счётчики. Обычно достаточно 8–12 бакетов.
• Смена бакетов рвёт историю. Старые ряды с прежними le остаются, новые появляются; сравнение «до и после» ломается. Поэтому границы стоит продумать один раз.
• Native histograms (эксперимент с Prometheus 2.40, стабильны с 3.8, но включаются отдельной настройкой скрейпа) снимают эту проблему: экспоненциальные бакеты подбираются автоматически по заданной относительной точности, всё лежит в одном ряду, кардинальность не растёт.

Три уровня

• SLI. Хороший SLI меряется на границе с пользователем и выражается долей: успешные запросы / все запросы, запросы быстрее 300 мс / все запросы, свежесть данных < 5 мин. В плохие SLI попадают CPU, память, «сервис запущен»: пользователю от этого ни тепло, ни холодно.
• SLO. Цель на окне: «99.9 % за 30 дней скользящим окном». Скользящее окно лучше календарного месяца, иначе первого числа бюджет магически обнуляется и первого числа же начинается вакханалия релизов.
• SLA. То же самое в договоре с деньгами за нарушение. Внутреннее SLO делают строже SLA, чтобы был запас до штрафов.

Эта таблица работает как аргумент. «Хотим 99.99 %» перестаёт быть красивой фразой, когда видно, что это четыре минуты в месяц на всё: на деплои, на миграции, на сбои облака, на человеческие ошибки. Обычно после этого разговор переходит к тому, какие именно операции критичны и какое SLO нужно им, а не сервису целиком.

Как это меняет разговор с продуктом

1. Появляется общая единица измерения. Раньше спор был про ощущения («стало медленно» против «надо фичи»), теперь спорят про число: «бюджет израсходован на 80 %, из них 60 % съел инцидент с миграцией».
2. У заморозки есть объективный триггер. Политику фиксируют заранее: бюджет исчерпан → заморозка рискованных выкаток, приоритет на надёжность, пока бюджет не восстановится. Это решение принято до инцидента и не зависит от того, кто сегодня громче.
3. У надёжности появляется потолок. К 100 % стремиться не надо. Более того, неизрасходованный бюджет тоже плох: значит, команда движется слишком осторожно и могла бы быстрее поставлять ценность. Для многих это неожиданный аргумент.
4. Разговор идёт на языке пользователя. SLO меряется по тому, что видит клиент, и потому обсуждаем с продактом без перевода. «Сколько заказов в месяц мы согласны потерять» звучит как вопрос, на который у продукта есть мнение.

Симптом против причины

• Алерт на симптом срабатывает, только когда действительно плохо; он не зависит от того, какая именно из десяти возможных причин случилась; он переживает рефакторинг, переезд на новое железо и смену архитектуры; и он один, а не двадцать.
• Алерт на причину ловит только те причины, которые уже были. «CPU 90 %» может быть штатной работой под нагрузкой; «под перезапустился» вообще обычная жизнь кластера; а один настоящий инцидент рождает шторм из сорока уведомлений от всех связанных систем, в котором тонет главное.
• Законное исключение: причины годятся, когда предсказывают отказ с большим запасом и требуют действий заранее: «диск заполнится через 4 часа при текущем темпе» (predict_linear), «сертификат истекает через 7 дней», «пул соединений занят на 95 %». Такие алерты идут в тикет, а не в звонок.

Алерт-фатиг

Это состояние, когда 90 % срабатываний ничего не значат и дежурный перестаёт на них смотреть. Опаснее полного отсутствия мониторинга, потому что создаёт иллюзию контроля. Что помогает:

• Разделить по срочности: page (звонок, реагировать сейчас) / ticket (в рабочее время) / dashboard-only. После честной ревизии большинство существующих алертов переезжает вниз.
• Пересматривать список после каждого дежурства: что сработало, что было ложным, что удалить. Алерт, который за квартал ни разу не привёл к действию, удаляем. Это не потеря, а возврат внимания.
• Группировка и подавление в Alertmanager: group_by, чтобы 50 подов дали одно уведомление; inhibit_rules, чтобы «нода недоступна» глушила все алерты про поды на ней; silence на плановые работы.
• Runbook в тексте алерта. Ссылка на «что проверить, что сделать». Алерт без инструкции стоит дежурному 20 минут на то, чтобы вспомнить контекст.
• Метрики про сам алертинг: сколько сработало, сколько привело к действию, сколько ложных. Без этих цифр разговор о качестве алертов превращается в обмен мнениями.

Что делать с флапающими алертами

1. for: идёт первым номером. Условие должно держаться непрерывно заданное время: for: 5m отсекает одиночные всплески. Поставишь мало, получишь флап; поставишь много, узнаешь поздно. Но он задерживает только срабатывание: горящий алерт гаснет на первой же проверке, где условие ложно. Задержку на выключение даёт keep_firing_for (Prometheus 2.42+).
2. Гистерезис. Порог зажигания и погашения должны различаться: загорается при > 5 %, гаснет при < 2 %. Иначе метрика, колеблющаяся вокруг единственного порога, шлёт «горит/потухло» каждые полминуты.
3. Шире окно усреднения. rate(...[5m]) вместо [1m]; для редких событий короткое окно швыряет значение между нулём и бесконечностью.
4. Условие на минимальный объём. При 3 запросах в минуту одна ошибка даёт 33 %. Добавляем and sum(rate(http_requests_total[5m])) > 1, чтобы не алертить по статистике на пустом трафике.
5. Многооконный burn rate вместо одного порога: длинное окно подтверждает, что бюджет сгорел заметно и это не всплеск, а короткое - что он горит прямо сейчас, поэтому после починки алерт гаснет за минуты, а не через час. Против ложных срабатываний ничего лучше пока не придумали.
6. Если флапает по-настоящему, значит, система реально балансирует на границе, и чинить надо систему: добавить ресурсов, поправить пороги автоскейлера, убрать источник пилы. Заглушить алерт проще всего и хуже всего.

Модель данных

• trace_id занимает 16 байт и одинаков у всех спанов запроса, span_id - 8 байт, свой у каждой операции. parent_span_id связывает спаны в дерево.
• Span несёт: имя (низкой кардинальности - GET /users/{id}, не конкретный URL), время начала и конца, статус (unset/ok/error), атрибуты (сюда как раз можно и нужно класть высококардинальные user_id и order_id - в трейсах это не проблема) и события (точки во времени: «retry», «cache miss»).
• Span links нужны для асинхронных границ: консьюмер Kafka часто обрабатывает пачку сообщений из разных трейсов, а родитель у спана один, поэтому по конвенциям OpenTelemetry вместо parent-child по умолчанию ставят link (для одиночного сообщения допускается и родитель).
• Baggage везёт произвольные пары ключ-значение вместе с контекстом через все сервисы (например, «это тестовый трафик»). Мощно и опасно: растёт размер заголовков, и туда легко утекает лишнее.

Propagation

traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
             ^^ версия
                ^^^^ trace-id: ОДИН на весь запрос
                                                 ^^^^ span-id отправителя
                                                 (у получателя станет parent_span_id)
                                                                  ^^ флаги: 01 = sampled

В Go всё это едет в context.Context. На входе middleware (otelhttp.NewHandler) достаёт заголовок и создаёт серверный спан; на выходе транспорт (otelhttp.NewTransport) кладёт уже свой span_id в исходящий запрос. В gRPC то же самое едет в метаданных, а в Kafka - в заголовках сообщения. От кода требуются две вещи: один раз зарегистрировать пропагатор (otel.SetTextMapPropagator; по умолчанию он пустой, и middleware с транспортом заголовки не читают и не пишут) и передавать ctx везде. Ушёл в горутину с context.Background() - и трейс порвался. Это причина обрывов номер один.

Есть ещё исторические форматы: b3 (Zipkin), x-datadog-*, jaeger-заголовки. В смешанной инфраструктуре настраивают композитный пропагатор, который умеет читать несколько форматов, иначе трейс рвётся ровно на границе со старым сервисом.

Сэмплирование: зачем

При 10 000 rps и десяти спанах на запрос набегает 100 000 спанов в секунду, терабайты в сутки, и подавляющее большинство описывает обычные успешные запросы, на которые никто никогда не посмотрит. Плюс накладные расходы в самом приложении и на сети. Поэтому вопрос не «сэмплировать или нет», а «как выбрать, что сохранить».

Практический рецепт: ParentBased обязателен всегда. Решение принимается один раз на входе и уважается всеми участниками, иначе трейсы получаются дырявыми (часть спанов есть, часть нет - и картинка врёт). Дальше берут либо TraceIDRatioBased(0.01…0.1) для дешёвого варианта, либо OpenTelemetry Collector с политикой «все трейсы с ошибкой, все медленнее 1 с, 1 % остальных». Помогает и форсирование трейса для конкретного запроса по внутреннему заголовку: так проблему можно воспроизвести и гарантированно получить трейс.

Что проверять

• /health отдаёт плоский 200 OK. Добавлять туда стоит только признаки состояния, которые лечатся перезапуском: зависший фоновый воркер (последний тик был больше N минут назад), обнаруженный дедлок, исчерпание внутреннего ресурса, из которого нет выхода. Всё это значит «процесс сломан изнутри», и рестарт действительно помогает.
• /ready проверяет реальную готовность обслуживать: соединение с БД, подключение к брокеру, прогретый кэш или загруженный справочник, признак «идёт graceful shutdown». Проверки должны быть дешёвыми: фоновая горутина раз в несколько секунд опрашивает зависимости и обновляет атомарные флаги, хендлер только читает их.

Почему БД в liveness - катастрофа

1. База недоступна несколько минут (переключение реплики, сетевой сбой).
2. Liveness падает одновременно у всех реплик, ведь они смотрят в одну и ту же базу.
3. kubelet убивает все контейнеры. Теряются установленные соединения, прогретые кэши, все запросы в обработке.
4. Поды стартуют, снова не видят базу, снова падают. Первый перезапуск идёт сразу, а дальше Kubernetes удваивает паузу перед каждым следующим: 10 с, 20 с, 40 с и так до 5 минут.
5. База вернулась, а сервис лежит дальше, до нескольких минут, потому что поды досиживают свою паузу.

Итог: перезапуск не чинит недоступную базу, зато многократно увеличивает ущерб. Правильно держать БД в readiness: поды остаются живыми, пул соединений переустанавливает их сам, трафика на них временно нет, и как только база вернулась, readiness проходит и трафик возвращается - без единого рестарта.

Первый экран, по рядам

1. RED. Rate (rps со стеком по кодам ответа), Errors (доля 5xx, отдельно 4xx), Duration (p50/p95/p99 тремя линиями плюс пунктир SLO). Три панели - и уже понятно, есть проблема или нет.
2. SLO и бюджет ошибок. Сколько бюджета осталось на окне и текущий burn rate за 1 час и за 6 часов. Это переводит «плохо» в «насколько срочно».
3. Saturation. Пул соединений к БД, запросы в обработке (in-flight), длина очередей, число горутин, CFS-троттлинг, память относительно лимита. Этот ряд предупреждает заранее, а не констатирует.
4. Зависимости нашими глазами. Latency и ошибки запросов в БД, к соседним сервисам, лаг консьюмера. Отвечает на главный вопрос первых двух минут инцидента: «это мы или это нас».
5. Разбивки. Топ маршрутов по времени и по ошибкам показывает, «кому именно плохо».
6. Ресурсы и события. RSS против лимита, CPU против лимита, рестарты и OOMKilled, число реплик - и аннотации деплоев, миграций и переключений флагов вертикальными линиями на всех графиках.

Порядок действий на инциденте

1. Подтвердить по метрике. go_goroutines растёт и не возвращается после спада трафика - значит, утечка, а не всплеск нагрузки. С Go 1.26 то же самое видно детальнее через runtime/metrics: к /sched/goroutines:goroutines (он там с 1.16) добавились разбивка по состояниям (/sched/goroutines/running:goroutines, runnable, waiting, not-in-go; она приблизительная, суммироваться в общее число не обязана) и /sched/threads/total:threads.
2. Взять профиль с нужного пода, а не через Service: kubectl port-forward pod/<имя> 6060:6060.
3. Сначала goroutineleak. Он короткий и содержит только безнадёжные: curl 'localhost:6060/debug/pprof/goroutineleak?debug=1' или в коде pprof.Lookup("goroutineleak"). В выводе будут стеки, на которых горутины стоят: «столько-то горутин утекло, и все висят вот здесь».
4. Потом goroutine?debug=2. Там видны все горутины со статусом и временем ожидания; нужен, если утечка не «навсегда», а «очень надолго» (горутина ждёт ответа без таймаута - примитив-то достижим, поэтому goroutineleak её не покажет).
5. Починить причину, а не симптом: почти всегда это горутина без context.Context, отправка в канал, который никто не читает после ранней ошибки, или цикл по тикеру из time.NewTicker без выхода по ctx.Done().