Встроенные метрики процесса Go

Самая частая серия — go_goroutines: gauge с числом живых горутин на момент скрейпа. Рядом go_threads: потоки ОС, которые рантайм держит под планировщик; их число растёт при блокирующих системных вызовах и возвращается не всегда — это нормально. Память занимает целая семья go_memstats_*: go_memstats_alloc_bytes — байты под живые объекты, go_memstats_sys_bytes — сколько памяти рантайм взял у системы, go_memstats_heap_inuse_bytes — куча, находящаяся в работе. Сборщик мусора представлен серией go_gc_duration_seconds — это summary с квантилями 0, 0.25, 0.5, 0.75 и 1: квантиль 1 показывает худшую паузу за жизнь процесса, а через _sum и _count выводится средняя. Отдельная серия go_info с лейблом версии — gauge со значением 1, маркирующий, каким компилятором собран процесс. Из process_-набора чаще всего смотрят process_cpu_seconds_total, process_resident_memory_bytes, process_open_fds и process_start_time_seconds — unix-время старта, из которого делается график аптайма.

Глобальный реестр удобен приложению, но библиотеке он не подходит: регистрируя метрики в DefaultRegisterer, вы мусорите в чужом процессе. Поэтому в библиотеках и тестах берут собственный: prometheus.NewRegistry() возвращает пустой изолированный набор, в котором есть ровно то, что вы зарегистрировали сами. И здесь поджидает ловушка из заголовка: go_ и process_ серии в новом реестре не появятся, потому что их туда никто не положил. Возвращаются они явно: prometheus.NewGoCollector() и prometheus.NewProcessCollector(prometheus.ProcessCollectorOpts{}) регистрируются в вашем реестре вместе с бизнес-метриками. Пустые ProcessCollectorOpts означают отсутствие namespace — имена останутся process_, а не myapp_process_. Для экспорта реестра нужен уже не promhttp.Handler(), а promhttp.HandlerFor(reg, promhttp.HandlerOpts{}), который собирает выдачу именно из вашего набора. В свежих версиях client_golang есть и тонкая настройка через пакет collectors — дополнительные метрики рантайма по runtime/metrics, — но это опциональный слой, для старта хватает базовой пары.

Из всего встроенного набора чаще всего спасает именно goroutines метрика. Нормальный профиль сервиса стабилен: число горутин зависит от пула воркеров и наплыва трафика, поднимается в пик-час, возвращается к ночной отметке. Опасная картина другая: линия растёт ступеньками после каждого релиза и никогда не опускается — значит, какая-то горутина не завершается. Классические причины — бесконечный цикл без условия выхода, чтение из канала, который никто не закроет, запрос без таймаута во внешний API. Каждая зависшая горутина висит и в памяти. График go_goroutines за неделю находит такую утечку раньше алерта по памяти: горутины занимают килобайты, и до OOM иногда неделями тишина, а линия-то уже ползёт. Разбор ловушек с каналами и счётчиками собственных горутин — в уроке про метрики горутин, а основы самих горутин при желании освежите в курсе продвинутого Go.

Пара go_goroutines и go_threads демонстрирует модель M:N: горутин могут быть тысячи, а потоков ОС — в пределах пары десятков, потому что планировщик рантайма мультиплексирует первые на вторые. Скачок go_threads без роста горутин подсказывает на блокирующие системные вызовы: файловые операции и cgo держат поток занятым. Процессор же честнее смотреть по process_cpu_seconds_total: rate(process_cpu_seconds_total[5m]) даёт потребление в ядрах, и в контейнере это число сравнивают с лимитом из cgroup. Нюанс, о котором больно узнают на дежурстве: исторически рантайм читал GOMAXPROCS из числа ядер машины и не знал о лимитах контейнера, поэтому подожатый лимитом сервис строил очереди планировщика внутри себя — деградация латентности при спокойном CPU-графике. В свежих версиях Go поведение починили, но проверьте версию рантайма через лейбл go_info, прежде чем списывать всё на троттлинг.

Четыре графика собираются из встроенных серий без единой собственной метрики, и каждый закрывает частый вопрос дежурства. Скорость потребления CPU: rate(process_cpu_seconds_total[5m]) — линия в ядрах, на которой троттлинг виден как упор в лимит. Резидентная память: process_resident_memory_bytes в динамике — медленный вечный рост при ровной куче подсказывает фрагментацию или побочный эффект очередей. Дескрипторы: process_open_fds за неделю — идеальный детектор незакрытых файлов и тел ответов, потому что дескрипторы конечны и лимит на них у процесса жёсткий. Аптайм: time() - process_start_time_seconds рисует пилу перезапусков — на одном экране видно, сколько раз сервис перезапустился за сутки, даже если никто не вёл журнал. Эти четыре панели стоит сделать первыми: они работают для любого Go-сервиса одинаково, и шаблон для них живёт в уроке про Grafana.

Встроенные метрики отвечают на вопрос «здоров ли процесс», но не на вопрос «здоров ли сервис». В них нет доли ошибок по маршрутам, нет латентности обработки, нет числа заказов и конверсий — всё это ваши метрики из предыдущих уроков. Практичный порядок такой: встроенный набор включён всегда, он бесплатен и ловит проблемы самого рантайма; поведенческие метрики вы добавляете по мере того, как сервис обрастает логикой, начиная с бизнес-событий. Полезно и обратное знание: если тестовый сервис внезапно отдаёт тысячи серий, проверьте, не создаёте ли вы вектор на каждый запрос — MustRegister паникует на дубликатах регистрации, а вот новый вектор с тем же именем плодит серии молча. Разделение «процесс» и «поведение» экономит время разбора: процесс здоров, а сервис болеет — виновата логика, и искать нужно в собственных сериях.