Sampling: прореживание потока

Семплер — это интерфейс Sampler с одним методом Sample(lvl Level) bool: вернуть true — событие пишется, false — отбрасывается. Вешается он на копию логгера методом Sample: sampled := base.Sample(&zerolog.BasicSampler{N: 10}) — и дальше все события этой копии проходят через семплер. Интерфейс экспортирован не зря: свой семплер — это один метод Sample(lvl Level) bool, и правило вроде «прореживать всё, кроме Warn и Error», пишется четырьмя строками, если встроенных не хватило. Важно понимать, где он стоит: метод should сначала проверяет порог локального уровня и глобальный SetGlobalLevel из урока про уровни, и только потом вызывает семплер — то есть прореживаются только те события, которые уже прошли порог. Уровень при этом передаётся в Sample первым аргументом, и поуровневый семплер из середины урока именно им пользуется. Счётчики детерминированных семплеров — BasicSampler и BurstSampler — крутятся на атомарных операциях, поэтому одна копия логгера с семплером безопасна для сотен горутин: счётчик общий, а не у каждого воркера. RandomSampler кладёт монетку через глобальный генератор случайных чисел — тоже потокобезопасно, но счётчика у него нет вовсе. И не забывайте про value-семантику: Sample возвращает новую копию, base продолжает писать без прореживания — включать и выключать семплер можно на отдельных ветках дерева логгеров. Порядок проверок в should при этом стоит держать в голове при отладке: если события пропали после подъёма глобального порога, семплер ни при чём — до него очередь не дошла.

Два простых семплера отвечают на два разных вопроса. BasicSampler — детерминированный: каждый N-й, ровно и предсказуемо; удобно, когда важна равномерность потока — heartbeat-ы, статистика цикла. RandomSampler — вероятностный: zerolog.RandomSampler(chance) — преобразование uint32-а в семплер, который пропускает событие с шансом один из chance; никаких счётчиков и равномерности — чистая монетка. В пакете есть готовые ярлыки: zerolog.Often, zerolog.Sometimes и zerolog.Rarely — это RandomSampler(10), RandomSampler(100) и RandomSampler(1000) соответственно. Имена честные до прямолинейности: Often пропускает примерно каждый десятый, Rarely — примерно один из тысячи; док-комментарии пишут «~» не зря — вероятность не обещает ровности. Выбор между ними — вопрос следствия ошибки выборки: детерминированный семплер на периодическом сигнале может войти в резонанс и всегда попадать на одну и ту же фазу цикла; случайный резонансом не болеет, но при малом шансе короткий всплеск может пролететь мимо ленты целиком. Для мониторинга частоты событий детерминированный честнее — объём предсказуем; для генерации уникальных сэмплов отладки — случайный живее. Оба не смотрят на уровень: что прошло порог, то и прореживается — к последствиям этого мы вернёмся в «живом месте».

BurstSampler — самый полезный из семьи: он пропускает первые Burst событий за окно Period, а дальше передаёт решение следующему семплеру NextSampler. Структура с тремя полями: Burst uint32, Period time.Duration, NextSampler Sampler — и собирается литералом: &zerolog.BurstSampler{Burst: 5, Period: time.Minute, NextSampler: nil}. Окно фиксированное, не скользящее: при первом событии после истечения Period счётчик обнуляется, и начало окна переносится на этот момент — «пять событий в минуту» считается от начала текущего окна, а сброс выполняется атомарным сравнением-и-заменой, без блокировок. NextSampler — место для второго правила: nil означает «после всплеска всё отбрасывать», а &zerolog.BasicSampler{N: 100} — «после всплеска писать одну из ста». Двухступенчатая схема покрывает классику: всплеск при старте или деградации попадает в ленту целиком — вы видите все первые ошибки, — а устойчивый поток прореживается, и диск живёт. Нюанс, о котором мало кто читает док-комментарий: всплеск срабатывает только когда и Burst, и Period больше нуля; при Period 0 семплер сразу передаёт решение NextSampler, а без него — отбрасывает всё. Проверяйте конфигурацию двумя событиями рядом, прежде чем доверять ей прод. Док-комментарий обещает ровно это: «BurstSampler lets Burst events pass per Period then pass the decision to NextSampler. If Sampler is not set, all subsequent events are rejected» — источник правды, когда конфигурация разошлась с поведением.

Три инструмента объёма решают разные задачи, и путать их дорого. Disabled — когда события не нужны вообще: известный горячий путь, debug-трассы в проде — нулевая цена и нулевой объём из урока про производительность. Sampling — когда события нужны, но не все: репрезентативная выборка статистики, всплески при деградации, шумные ветки, чей код вы не контролируете. Порог уровня — когда не нужен целый класс: Debug выключен глобально. Семплер выбирают, когда класс нужен, а частота — нет. У LevelSampler нет полей для Fatal и Panic: не заданный явно семплер уровня возвращает true, поэтому самые срочные события проходят даже поверх настроек прореживания. Стоп-кран для всего этого — zerolog.DisableSampling(true): глобальный переключатель, который при разборе инцидента выключает все семплеры во всех логгерах разом, и вы на время видите полный поток без переконфигурации; вернуть как было — одной строкой. Расписывайте семплеры в конфигурации рядом с уровнями из урока про окружение: «debug — всплеск 5 в секунду, дальше 1 из 100» — это читаемое правило, которое ревьюер понимает без исходников. И помните про value-семантику: Sample возвращает копию, поэтому семплер вешается на ветку — на модуль, на воркер, а не обязательно на весь сервис. Копии при этом делят один семплер-указатель: несколько веток, собранных из одной Sample-копии, считают общее окно — иногда это то, что нужно, а иногда сюрприз, который виден только под нагрузкой.

Прореживание — последний инструмент объёма до продакшена: дальше курс идёт в горутины — что происходит, когда сотня воркеров пишет в один логгер, — и затем в конфигурацию по окружению, где уровни и семплеры собираются из переменных окружения. Справочное закрепление: найдите в своём сервисе самый шумный цикл, повесьте на его модуль LevelSampler с BurstSampler для debug и сравните объём ленты до и после — правило «всплеск 5 в секунду, дальше 1 из 100» обычно сокращает debug-объём на два порядка без потери всплесков деградации.