Senior Go Interview Prep - Core Go: https://go.vbloher.org/docs/01-core-go/ - Механика defer в Go: https://go.vbloher.org/docs/01-core-go/defer/ - Встраивание структур и интерфейсов (Embedding): https://go.vbloher.org/docs/01-core-go/embedding/ - Ошибки в Go: error, wrapping, errors.Is/As/Join: https://go.vbloher.org/docs/01-core-go/errors/ - Дженерики в Go (1.18+): https://go.vbloher.org/docs/01-core-go/generics/ - Интерфейсы в Go: https://go.vbloher.org/docs/01-core-go/interfaces/ - Устройство map в Go: https://go.vbloher.org/docs/01-core-go/maps/ - panic / recover: механика, раскрутка стека и runtime-паники: https://go.vbloher.org/docs/01-core-go/panic-recover/ - Указатели в Go: https://go.vbloher.org/docs/01-core-go/pointers/ - Рефлексия в Go (reflect): https://go.vbloher.org/docs/01-core-go/reflection/ - Внутреннее устройство слайсов в Go: https://go.vbloher.org/docs/01-core-go/slices/ - Строки, руны и байты в Go: https://go.vbloher.org/docs/01-core-go/strings-runes-bytes/ - Система типов Go: defined types, alignment, memory layout: https://go.vbloher.org/docs/01-core-go/type-system/ - Concurrency: https://go.vbloher.org/docs/02-concurrency/ - sync/atomic: https://go.vbloher.org/docs/02-concurrency/atomic/ - Буферизованные vs небуферизованные каналы: https://go.vbloher.org/docs/02-concurrency/buffered-unbuffered/ - Канал vs Mutex: когда что выбрать: https://go.vbloher.org/docs/02-concurrency/channel-vs-mutex/ - Каналы: устройство hchan: https://go.vbloher.org/docs/02-concurrency/channels/ - Утечки горутин, дедлоки, livelock, starvation: https://go.vbloher.org/docs/02-concurrency/common-leaks-deadlocks/ - sync.Cond: https://go.vbloher.org/docs/02-concurrency/cond/ - context: https://go.vbloher.org/docs/02-concurrency/context/ - Горутины: жизненный цикл, стоимость, стек: https://go.vbloher.org/docs/02-concurrency/goroutines-lifecycle/ - sync.Mutex и sync.RWMutex: https://go.vbloher.org/docs/02-concurrency/mutex-rwmutex/ - sync.Once: https://go.vbloher.org/docs/02-concurrency/once/ - Паттерны конкурентности: https://go.vbloher.org/docs/02-concurrency/patterns/ - Race Detector (гонки данных и -race): https://go.vbloher.org/docs/02-concurrency/race-detector/ - Планировщик GMP: https://go.vbloher.org/docs/02-concurrency/scheduler-gmp/ - select: https://go.vbloher.org/docs/02-concurrency/select/ - sync.WaitGroup: https://go.vbloher.org/docs/02-concurrency/waitgroup/ - Runtime и память: https://go.vbloher.org/docs/03-runtime-memory/ - Паттерны аллокаций и снижение давления на GC: https://go.vbloher.org/docs/03-runtime-memory/allocation-patterns/ - Escape Analysis: когда переменная убегает в кучу: https://go.vbloher.org/docs/03-runtime-memory/escape-analysis/ - Сборщик мусора Go: concurrent tri-color mark-sweep: https://go.vbloher.org/docs/03-runtime-memory/gc/ - Тюнинг GC: GOGC и GOMEMLIMIT: https://go.vbloher.org/docs/03-runtime-memory/gogc-gomemlimit/ - GOMAXPROCS: параллелизм планировщика и проблема контейнеров: https://go.vbloher.org/docs/03-runtime-memory/gomaxprocs/ - Утечки горутин (goroutine leaks): https://go.vbloher.org/docs/03-runtime-memory/goroutine-leaks/ - Утечки памяти в Go (несмотря на GC): https://go.vbloher.org/docs/03-runtime-memory/memory-leaks/ - Модель памяти Go (Go Memory Model): happens-before и синхронизация: https://go.vbloher.org/docs/03-runtime-memory/memory-model/ - pprof: профилирование CPU, памяти и блокировок в Go: https://go.vbloher.org/docs/03-runtime-memory/pprof/ - Execution Tracer и runtime/trace: тайминги вместо агрегатов: https://go.vbloher.org/docs/03-runtime-memory/runtime-tracing/ - Стек vs Куча: где живут данные в Go: https://go.vbloher.org/docs/03-runtime-memory/stack-vs-heap/ - Тестирование: https://go.vbloher.org/docs/04-testing/ - testify, assert/require и golden files: https://go.vbloher.org/docs/04-testing/assertions-testify/ - Бенчмарки в Go: https://go.vbloher.org/docs/04-testing/benchmarks/ - Покрытие, -race и флаки-тесты: https://go.vbloher.org/docs/04-testing/coverage-race/ - Нативный fuzzing в Go (1.18+): https://go.vbloher.org/docs/04-testing/fuzzing/ - Интеграционные тесты, testcontainers-go, TestMain: https://go.vbloher.org/docs/04-testing/integration-testcontainers/ - Моки, стабы и тестируемость: https://go.vbloher.org/docs/04-testing/mocks/ - Table-driven тесты, subtests и параллельность: https://go.vbloher.org/docs/04-testing/table-driven/ - Backend: https://go.vbloher.org/docs/05-backend/ - Аутентификация и авторизация: AuthN/AuthZ, сессии vs токены, RBAC/ABAC, API keys, mTLS, секреты: https://go.vbloher.org/docs/05-backend/auth-authz/ - Graceful Shutdown HTTP/gRPC сервера в Go: https://go.vbloher.org/docs/05-backend/graceful-shutdown/ - gRPC: типы RPC, интерсепторы, контекст, метаданные, error model: https://go.vbloher.org/docs/05-backend/grpc/ - JWT (JSON Web Token): https://go.vbloher.org/docs/05-backend/jwt/ - Middleware-паттерн в Go: https://go.vbloher.org/docs/05-backend/middleware/ - net/http: Server, Handler, ServeMux, таймауты, Client и контекст: https://go.vbloher.org/docs/05-backend/net-http/ - OAuth2: роли, grant types, OIDC, токены и типовые ошибки: https://go.vbloher.org/docs/05-backend/oauth2/ - OpenAPI/Swagger, code generation, contract-first vs code-first, валидация: https://go.vbloher.org/docs/05-backend/openapi/ - Protocol Buffers: схемы, wire format, эволюция и совместимость: https://go.vbloher.org/docs/05-backend/protobuf/ - REST: принципы, версионирование, идемпотентность, статусы, пагинация, ошибки: https://go.vbloher.org/docs/05-backend/rest/ - Сети и протоколы: https://go.vbloher.org/docs/06-networking/ - Пулы соединений: http.Transport, БД, утечки: https://go.vbloher.org/docs/06-networking/connection-pooling/ - DNS: записи, резолвинг, кэширование, DNS в Go: https://go.vbloher.org/docs/06-networking/dns/ - Версии HTTP: 1.1, 2, 3: https://go.vbloher.org/docs/06-networking/http-versions/ - TCP/IP: модель, транспорт и что важно бэкендеру: https://go.vbloher.org/docs/06-networking/tcp-ip/ - TLS: handshake, сертификаты, mTLS, производительность: https://go.vbloher.org/docs/06-networking/tls/ - UDP и надёжность поверх UDP: https://go.vbloher.org/docs/06-networking/udp/ - WebSocket: upgrade, фреймы, масштабирование: https://go.vbloher.org/docs/06-networking/websocket/ - Базы данных: https://go.vbloher.org/docs/07-databases/ - Пул соединений к PostgreSQL в Go: database/sql, pgx, pgxpool, PgBouncer: https://go.vbloher.org/docs/07-databases/connection-pooling-pgx/ - Взаимоблокировки (Deadlocks) в PostgreSQL: https://go.vbloher.org/docs/07-databases/deadlocks/ - Индексы в PostgreSQL: https://go.vbloher.org/docs/07-databases/indexes/ - Уровни изоляции транзакций в PostgreSQL: https://go.vbloher.org/docs/07-databases/isolation-levels/ - MVCC в PostgreSQL: версии строк, видимость, VACUUM и bloat: https://go.vbloher.org/docs/07-databases/mvcc/ - Обзор NoSQL и Redis: https://go.vbloher.org/docs/07-databases/nosql-redis/ - Партиционирование таблиц в PostgreSQL: https://go.vbloher.org/docs/07-databases/partitioning/ - Архитектура PostgreSQL: https://go.vbloher.org/docs/07-databases/postgresql-architecture/ - Планирование и оптимизация запросов в PostgreSQL: https://go.vbloher.org/docs/07-databases/query-planning/ - Репликация в PostgreSQL: https://go.vbloher.org/docs/07-databases/replication/ - Шардирование (горизонтальное масштабирование): https://go.vbloher.org/docs/07-databases/sharding/ - Транзакции в PostgreSQL и Go (database/sql, pgx): https://go.vbloher.org/docs/07-databases/transactions/ - Распределённые системы: https://go.vbloher.org/docs/08-distributed-systems/ - CAP теорема: https://go.vbloher.org/docs/08-distributed-systems/cap-theorem/ - Circuit Breaker: https://go.vbloher.org/docs/08-distributed-systems/circuit-breaker/ - Консенсус и Raft: репликация состояния в присутствии отказов: https://go.vbloher.org/docs/08-distributed-systems/consensus-raft/ - Модели согласованности: https://go.vbloher.org/docs/08-distributed-systems/consistency/ - Гарантии доставки сообщений: at-most-once / at-least-once / exactly-once: https://go.vbloher.org/docs/08-distributed-systems/delivery-guarantees/ - Eventual Consistency: https://go.vbloher.org/docs/08-distributed-systems/eventual-consistency/ - Идемпотентность в распределённых системах: https://go.vbloher.org/docs/08-distributed-systems/idempotency/ - Apache Kafka: https://go.vbloher.org/docs/08-distributed-systems/kafka/ - Transactional Outbox: https://go.vbloher.org/docs/08-distributed-systems/outbox/ - RabbitMQ: AMQP 0-9-1, маршрутизация, надёжность доставки и сравнение с Kafka: https://go.vbloher.org/docs/08-distributed-systems/rabbitmq/ - Ретраи: backoff, jitter, budgets и идемпотентность: https://go.vbloher.org/docs/08-distributed-systems/retries/ - Saga Pattern: https://go.vbloher.org/docs/08-distributed-systems/saga/ - Observability: https://go.vbloher.org/docs/09-observability/ - Grafana: https://go.vbloher.org/docs/09-observability/grafana/ - Метрики: RED, USE, Golden Signals: https://go.vbloher.org/docs/09-observability/metrics/ - OpenTelemetry: https://go.vbloher.org/docs/09-observability/opentelemetry/ - Prometheus: https://go.vbloher.org/docs/09-observability/prometheus/ - SLI / SLO / SLA: https://go.vbloher.org/docs/09-observability/slo-sli/ - Структурированное логирование (slog): https://go.vbloher.org/docs/09-observability/structured-logging/ - Distributed Tracing: https://go.vbloher.org/docs/09-observability/tracing/ - System Design: https://go.vbloher.org/docs/10-system-design/ - Analytics Pipeline: https://go.vbloher.org/docs/10-system-design/analytics-pipeline/ - Chat System: https://go.vbloher.org/docs/10-system-design/chat/ - Фреймворк System Design интервью: https://go.vbloher.org/docs/10-system-design/framework/ - Notification Service: https://go.vbloher.org/docs/10-system-design/notification-service/ - Order Service: https://go.vbloher.org/docs/10-system-design/order-service/ - Payment Service: https://go.vbloher.org/docs/10-system-design/payment-service/ - Rate Limiter: https://go.vbloher.org/docs/10-system-design/rate-limiter/ - URL Shortener: https://go.vbloher.org/docs/10-system-design/url-shortener/ - DevOps: https://go.vbloher.org/docs/11-devops/ - CI/CD: пайплайны, стадии, стратегии деплоя: https://go.vbloher.org/docs/11-devops/cicd/ - Облака (AWS / GCP) для бэкендера: https://go.vbloher.org/docs/11-devops/cloud-aws-gcp/ - Docker для Go-разработчика: https://go.vbloher.org/docs/11-devops/docker/ - GitHub Actions и GitLab CI: https://go.vbloher.org/docs/11-devops/github-gitlab-ci/ - Kubernetes для Go-разработчика: https://go.vbloher.org/docs/11-devops/kubernetes/ - Terraform / Infrastructure as Code: https://go.vbloher.org/docs/11-devops/terraform/ - Алгоритмы: https://go.vbloher.org/docs/12-algorithms/ - Типовые алгоритмические задачи и паттерны: https://go.vbloher.org/docs/12-algorithms/common-problems/ - Асимптотическая сложность (Big-O): https://go.vbloher.org/docs/12-algorithms/complexity/ - Структуры данных в Go: https://go.vbloher.org/docs/12-algorithms/data-structures/ - Специфика live-coding на Go: https://go.vbloher.org/docs/12-algorithms/go-specifics/ - Behavioral: https://go.vbloher.org/docs/13-behavioral/ - Конфликты, разногласия и работа со стейкхолдерами: https://go.vbloher.org/docs/13-behavioral/conflicts/ - Как проходит senior-интервью: этапы, оценка, оффер: https://go.vbloher.org/docs/13-behavioral/interview-flow/ - Лидерство и менторство: https://go.vbloher.org/docs/13-behavioral/leadership-mentoring/ - Типовые поведенческие вопросы для Senior: https://go.vbloher.org/docs/13-behavioral/senior-questions/ > Модуль: Observability · Уровень: Middle+/Senior ## TL;DR Структурированное логирование = логи как набор **key-value** (обычно JSON), а не текстовая строка → машинно-парсятся, фильтруются и агрегируются в Loki/ELK по полям. В Go 1.21+ это стандарт `log/slog`: `Logger` → `Handler` (`JSONHandler`/`TextHandler`/кастомный) → `Record` из `Attr`. Уровни через `slog.LevelVar` можно менять **в рантайме без рестарта**. Контекстные поля добавляются через `With`/`WithGroup`. Ключевая senior-практика — **корреляция**: кастомный Handler достаёт `trace_id`/`span_id` из `context.Context` (OTel SpanContext) и пишет в каждую запись через `InfoContext`. **PII не логировать** (пароли, токены, карты, email) — маскировать через `LogValuer` или `ReplaceAttr`. При высоком RPS — **sampling/rate-limiting логов**. Производительность: `slog` имеет zero-alloc путь при использовании типизированных `Attr` и ленивых `LogValuer`, плюс проверку `Enabled`, чтобы не вычислять дорогие поля при отключённом уровне. ## Теория ### Зачем структурированные логи Текстовый лог `log.Printf("user %s failed login from %s", u, ip)` нельзя надёжно отфильтровать в системе логов: нужен парсинг строки регэкспами. Структурный: ```json {"time":"2026-06-15T10:00:00Z","level":"WARN","msg":"login failed","user_id":"u_42","ip":"10.0.0.1","trace_id":"4bf9..."} ``` → запрос `level=WARN AND msg="login failed"` в Loki/ELK, агрегация по `user_id`, дашборды по полям. Машинно-читаемо, консистентно, корректно при многострочных значениях. ### Архитектура slog ```text slog.Logger — фронт API (Info/Warn/Error/Debug, With, WithGroup) │ передаёт slog.Record — одна запись (time, level, message, []Attr) │ обрабатывает slog.Handler — интерфейс: Enabled, Handle, WithAttrs, WithGroup ├─ slog.JSONHandler (структурный JSON — для прода) ├─ slog.TextHandler (logfmt — для локалки) └─ кастомный Handler (обёртка: trace correlation, sampling, redaction) slog.Attr / slog.Value — типизированная пара ключ-значение (zero-alloc путь) ``` ```go import "log/slog" func setup() { h := slog.NewJSONHandler(os.Stdout, &slog.HandlerOptions{ Level: slog.LevelInfo, AddSource: false, // file:line — дорого, только при необходимости }) slog.SetDefault(slog.New(h)) // глобальный логгер для slog.Info(...) } ``` ### Уровни и динамическая смена ```go var lvl = new(slog.LevelVar) // потокобезопасный, меняется в рантайме lvl.Set(slog.LevelInfo) h := slog.NewJSONHandler(os.Stdout, &slog.HandlerOptions{Level: lvl}) logger := slog.New(h) // где-то в HTTP-хендлере /debug/loglevel — поднять Debug на лету без рестарта lvl.Set(slog.LevelDebug) ``` Уровни: `Debug(-4)`, `Info(0)`, `Warn(4)`, `Error(8)`. Числовые → можно кастомные (`Trace = -8`, `Fatal = 12`). В проде обычно `Info`, `Debug` поднимают временно через `LevelVar`. ### Контекстные поля: With / WithGroup ```go // Логгер с базовыми полями, переиспользуется reqLog := logger.With( slog.String("request_id", reqID), slog.String("route", "/checkout"), ) reqLog.Info("started") reqLog.Error("db error", slog.Any("err", err)) // Группировка (вложенный объект в JSON) logger.WithGroup("http").Info("done", slog.Int("status", 200), slog.Duration("latency", d)) // => {"http":{"status":200,"latency":...}} // Разовая группа в одном вызове logger.Info("payment", slog.Group("card", slog.String("brand","visa"))) ``` ### Корреляция с трейсами: кастомный Handler Лучший паттерн — Handler-обёртка, которая достаёт `trace_id`/`span_id` из `context.Context` и добавляет в каждую запись. Тогда `InfoContext(ctx, ...)` автоматически коррелирует лог с трейсом. ```go import ( "context" "log/slog" "go.opentelemetry.io/otel/trace" ) type traceHandler struct{ slog.Handler } func (h traceHandler) Handle(ctx context.Context, r slog.Record) error { if sc := trace.SpanContextFromContext(ctx); sc.IsValid() { r.AddAttrs( slog.String("trace_id", sc.TraceID().String()), slog.String("span_id", sc.SpanID().String()), ) } return h.Handler.Handle(ctx, r) } // WithAttrs/WithGroup должны сохранять обёртку func (h traceHandler) WithAttrs(a []slog.Attr) slog.Handler { return traceHandler{h.Handler.WithAttrs(a)} } func (h traceHandler) WithGroup(name string) slog.Handler { return traceHandler{h.Handler.WithGroup(name)} } func newLogger(w io.Writer, lvl slog.Leveler) *slog.Logger { base := slog.NewJSONHandler(w, &slog.HandlerOptions{Level: lvl}) return slog.New(traceHandler{base}) } ``` ```go // в хендлере: ВАЖНО использовать *Context методы и прокидывать ctx logger.InfoContext(ctx, "charge ok", slog.Int("amount", 100)) // => {... "trace_id":"4bf9...","span_id":"00f0..."} ``` Альтернатива — `otelslog` bridge (`go.opentelemetry.io/contrib/bridges/otelslog`), который ещё и экспортирует логи по OTLP с привязкой к трейсу. **logger-in-context vs trace-id-in-context**: можно класть в ctx сам логгер (с уже привязанными полями) или только trace_id, а логгер брать дефолтный + Handler достаёт trace_id. Второй вариант чище: ctx несёт минимум, а корреляция — в Handler. ### Что НЕ логировать (PII) и как маскировать Никогда: пароли, токены/секреты, полный PAN карты, CVV, email/phone в открытом виде, персональные данные под GDPR, тела запросов с чувствительным содержимым. **LogValuer** — тип сам решает, как себя залогировать (маскирует на источнике): ```go type Card struct{ Number string } func (c Card) LogValue() slog.Value { masked := "****" + c.Number[len(c.Number)-4:] return slog.StringValue(masked) // в лог попадёт только "****1234" } logger.Info("paid", slog.Any("card", Card{Number: "4111111111111111"})) // => "card":"****1111" — исходный номер НИКОГДА не материализуется в лог ``` **ReplaceAttr** — глобальный фильтр на уровне Handler (редактирование/удаление полей по ключу): ```go opts := &slog.HandlerOptions{ ReplaceAttr: func(groups []string, a slog.Attr) slog.Attr { switch a.Key { case "password", "authorization", "set-cookie": return slog.Attr{} // удалить полностью case "email": return slog.String("email", "") } return a }, } ``` `LogValuer` предпочтительнее для доменных типов (маскирование рядом с данными, типобезопасно); `ReplaceAttr` — глобальная страховочная сетка, но вызывается на **каждый** Attr → следи за производительностью. ### Sampling и rate-limiting логов При высоком RPS логировать каждый запрос дорого (стоимость хранения, шум, нагрузка на pipeline). Стратегии: - **Sampling**: писать N% info-логов, но **все** ошибки. - **Dedup/rate-limit повторяющихся ошибок**: «БД недоступна» в цикле → одна запись + счётчик, а не 10k строк. - **Tail sampling логов**: если запрос завершился ошибкой/медленно — поднять детальность логов этого запроса (буферизация per-request и flush при ошибке). Реализуется кастомным Handler, который в `Handle` решает, пропускать ли запись (token bucket, sampler по уровню). ```go type sampledHandler struct { slog.Handler limiter *rate.Limiter } func (h sampledHandler) Handle(ctx context.Context, r slog.Record) error { if r.Level < slog.LevelError && !h.limiter.Allow() { return nil // дропаем info под нагрузкой, ошибки всегда пишем } return h.Handler.Handle(ctx, r) } ``` ### Производительность slog - **Zero-alloc путь**: типизированные `Attr` (`slog.String`, `slog.Int`) и `Value` избегают аллокаций в boxing; `...any` (`"key", val`) медленнее и аллоцирует. - **`Enabled(ctx, level)`** — проверяй перед дорогой подготовкой полей: при отключённом Debug не вычисляй тяжёлый дамп. ```go if logger.Enabled(ctx, slog.LevelDebug) { logger.DebugContext(ctx, "state", slog.Any("dump", expensiveDump())) } ``` - **`LogValuer` ленив**: `LogValue()` вызывается только если запись реально пишется — дорогую сериализацию откладываем до момента вывода (и она не выполнится при отключённом уровне). ## Подводные камни / gotchas - **`log.Println`/`Printf` — не структурный**: строка, которую нельзя надёжно фильтровать. Миграция на slog. - **Нечётное число аргументов** в `...any` (`logger.Info("msg", "key")` без значения) → запись с `!BADKEY`. Используй типизированные `Attr`. - **Дорогие вычисления в полях считаются даже при отключённом уровне**, если переданы напрямую (`slog.Any("x", expensive())` — `expensive()` уже вызван). Спасают `Enabled` и `LogValuer`. - **Утечка PII** — самый частый инцидент безопасности логов; маскируй на источнике (`LogValuer`) + сетка `ReplaceAttr`. - **Логирование в hot path** — каждый лог это I/O/сериализация; в горячем цикле убивает латенси. Сэмплируй. - **Не прокинут `ctx`** или вызван `Info` вместо `InfoContext` → нет `trace_id`, корреляция теряется. - **`ReplaceAttr` дорогой** — вызывается на каждый Attr каждой записи; тяжёлая логика там бьёт по всему логированию. - **Дублирование логов и трейсов**: writing всё и в лог, и в span events удваивает стоимость; реши, где источник истины. - **`AddSource: true`** добавляет file:line через runtime.Caller — заметный оверхед, не включай глобально в проде. - **Не настроены динамические уровни** → нельзя поднять Debug в инциденте без рестарта; используй `LevelVar`. ## Вопросы на собеседовании **В:** Как добавить trace_id в каждую лог-запись через slog? **О:** Кастомный Handler-обёртка: в `Handle(ctx, record)` достать `trace.SpanContextFromContext(ctx)` и, если валиден, `record.AddAttrs(trace_id, span_id)`. Обязательно прокинуть обёртку в `WithAttrs`/`WithGroup`, и использовать `InfoContext(ctx,...)` с прокинутым ctx. Либо `otelslog` bridge, который ещё и шлёт логи по OTLP с привязкой к трейсу. **В:** Чем `LogValuer` лучше `ReplaceAttr` для маскирования PII? **О:** `LogValuer.LogValue()` маскирует прямо в доменном типе (карта сама отдаёт `****1234`), типобезопасно, лениво (вызывается только при реальной записи) и исходное значение не материализуется. `ReplaceAttr` — глобальный фильтр по ключам, вызывается на каждый Attr (оверхед) и завязан на имена полей. Лучшая практика: `LogValuer` для доменных типов + `ReplaceAttr` как страховочная сетка. **В:** Как менять уровень логирования без рестарта? **О:** `slog.LevelVar` — потокобезопасный изменяемый уровень, переданный в `HandlerOptions.Level`. По админ-эндпоинту вызвать `lvl.Set(slog.LevelDebug)` и поднять детальность во время инцидента, потом вернуть Info. Без рестарта и без потери стейта. **В:** Почему важна проверка `Enabled` и ленивость `LogValuer`? **О:** Если передать `slog.Any("x", expensiveDump())`, функция вычисляется до вызова Info, даже при отключённом Debug. `if logger.Enabled(ctx, LevelDebug)` пропускает дорогую подготовку. `LogValuer.LogValue()` вызывается только когда запись реально пишется, откладывая дорогую сериализацию и пропуская её при отключённом уровне. **В:** Когда и как сэмплировать логи? **О:** При высоком RPS, чтобы снизить стоимость и шум: писать долю info-логов, но все ошибки; дедуплицировать повторяющиеся ошибки (счётчик вместо 10k строк); tail-sampling — буферизовать per-request и flush детально только при ошибке/медленном запросе. Реализация — кастомный Handler с token bucket в `Handle`, дропающий info под нагрузкой и всегда пропускающий Error. **В:** Что НЕ логировать и почему? **О:** Пароли, токены, полный PAN/CVV, email/phone в открытом виде, PII под GDPR, чувствительные тела запросов. Причины: утечка через лог-пайплайн (логи часто менее защищены, чем БД), комплаенс (GDPR/PCI), и доступ к логам у широкого круга. Маскировать на источнике через LogValuer и фильтровать ReplaceAttr. **В:** В чём разница `Info` и `InfoContext`, и почему предпочесть второй? **О:** `InfoContext` принимает `context.Context`, который передаётся в `Handler.Handle` — это позволяет Handler'у достать trace_id из ctx, учесть отмену/дедлайны и per-request данные. `Info` использует `context.Background()` → теряется корреляция с трейсом. В сервисном коде всегда `*Context`-методы с прокинутым ctx. ## На что копают на senior+ - **Кастомный Handler для trace-корреляции**: правильная реализация `Handle/WithAttrs/WithGroup`, сохранение обёртки, интеграция с OTel. - **PII redaction**: LogValuer vs ReplaceAttr, маскирование на источнике, аудит логов на утечки, комплаенс. - **Динамические уровни** через LevelVar без рестарта и per-component уровни. - **Sampling/rate-limiting логов**: token bucket, dedup, tail-sampling per-request, баланс стоимость/детальность. - **Стоимость и cardinality в Loki**: лейблы Loki ≠ поля лога; высококардинальные поля в лейблах Loki убивают его так же, как в Prometheus. - **Logs vs traces — когда что**: span events vs log lines, избегание дублирования, источник истины. - **Производительность slog внутри**: zero-alloc Attr/Value, Record-механика, почему `...any` медленнее, ленивость.