Наблюдаемость: perf, eBPF, метрики, логи

Что отвечать

`strace` использует ptrace - останавливает процесс на каждом syscall'е, копирует регистры в userspace, потом возвращает управление. Overhead огромный (10-100x замедление), но работает везде. eBPF цепляется к tracepoints/kprobes в ядре, выполняет байткод там же без переключения контекста. Overhead копеечный (единицы процентов), но требует ядро 4.x+ и BPF capabilities. На проде - eBPF (bpftrace, bcc). На дев-машине, где нужно «быстро понять что одна команда делает» - strace.

Что хотят услышать

Senior должен: - объяснить ptrace overhead - каждый syscall = два context switch - назвать что strace на multi-threaded процессе с большим RPS может сериализовать всё в один поток и развалить тайминги - сказать что eBPF verifier гарантирует завершение программы и memory safety - поэтому ядро разрешает запускать BPF-программы в проде - назвать bpftrace one-liner'ы Brendan Gregg как канонический набор - упомянуть что perf, ftrace, BPF Compiler Collection (BCC) - всё семейство Linux tracing-инструментов, у которых разные точки входа в одну инфраструктуру

Подводные камни

• ✗ Запустить strace на production-процессе с тысячами syscall/sec - процесс встанет
• ✗ Думать что eBPF может всё что strace - нет, BPF не может блокировать syscall, только наблюдать
• ✗ Не знать что strace по умолчанию следует только за главным потоком, нужен `-f` для дочерних

Follow-up

• ? Что делает `strace -c` и зачем он нужен в первую очередь?
• ? Как BPF verifier гарантирует завершение программы?
• ? Чем kprobe отличается от tracepoint? Что стабильнее?

Что отвечать

`perf record -F 99 -p <pid> -g -- sleep 30` - sample stack-traces 99 раз в секунду 30 секунд. `perf report` показывает топ функций по CPU-time. Для визуализации - flame graph (Brendan Gregg). `perf script | stackcollapse-perf.pl | flamegraph.pl > flame.svg` - SVG-картинка где ширина блока = доля CPU, высота = глубина стека. Виновник - самый широкий «плоский» блок наверху.

Что хотят услышать

Senior должен: - объяснить sampling vs tracing: perf sampler берёт snapshot стека 99 раз/сек, не трейсит каждый вызов - назвать `-g` для сбора call-graph (без него видно только верхушку) - сказать что для proper symbols нужны debug-символы (`-debuginfo` пакеты на RHEL, `dbgsym` на Debian) - назвать flame graph как стандарт визуализации - читается слева направо как «весь wall-time», снизу вверх как стек - упомянуть continuous profiling (Pyroscope, Parca) как prod-эволюцию ручного perf

Подводные камни

• ✗ Запустить perf без `-g` и не понять кто реально жрёт CPU
• ✗ Не установить debug-символы - в flame graph будут `[unknown]`
• ✗ Сэмплить с частотой 999/100/000 - либо мало данных, либо огромный overhead

Follow-up

• ? Чем `perf record -e cycles` отличается от `-e cpu-clock`?
• ? Что такое off-CPU flame graph и зачем он нужен?
• ? Как читать inverted flame graph (icicle graph)?

Что отвечать

USE (Brendan Gregg) - для ресурсов хоста: Utilization (% занятости), Saturation (очередь сверх возможностей), Errors (ошибки). Применяется к CPU, RAM, дискам, сети. RED (Tom Wilkie) - для сервисов: Rate (RPS), Errors (доля ошибок), Duration (latency). USE отвечает на «что сейчас перегружено», RED - на «здоров ли сервис с точки зрения клиента». На проде нужны оба: USE для capacity-planning, RED для SLO.

Что хотят услышать

Кандидат должен: - различить два уровня абстракции: USE про железо/ОС, RED про application-метрики - назвать пример: высокий CPU utilization (USE) сам по себе не проблема, если RED-latency сервиса в норме - упомянуть «4 golden signals» Google SRE как другой набор: latency, traffic, errors, saturation - пересекается с обоими - сказать что RED легко мапится на SLO (Service Level Objective): error budget из E, latency-target из D

Подводные камни

• ✗ Использовать только USE и не следить за latency - можно проспать деградацию сервиса при низкой утилизации
• ✗ Использовать только RED и не знать что CPU 90% - может ловить перегрев ноды до того как клиент заметил
• ✗ Путать saturation и utilization - utilization 100% и saturation 0 бывает (CPU занят, но очереди нет)

Follow-up

• ? Что такое saturation для CPU? А для диска?
• ? Чем golden signals отличаются от USE+RED?
• ? Как из RED-метрик собрать SLO и error budget?

Что отвечать

Метрики - агрегированные числа (counter, gauge, histogram) с низкой cardinality. Дешёвые, для alerting и трендов. Логи - текст событий с контекстом. Дорогие, для post-mortem «что именно произошло». Трейсы - причинно-следственная цепочка одного request'а через сервисы. Самые дорогие, для distributed-debugging. На проде нужны все три, но в разной доле: метрики на каждый scrape, логи sampled, трейсы 1-10%.

Что хотят услышать

Senior должен: - назвать cardinality как ключевой бюджет: метрика с user_id label ломает Prometheus, лог с user_id - нет - сказать что OpenTelemetry унифицирует все три (раньше каждый стек свой: Prometheus, Fluentd, Jaeger) - упомянуть что для каждого request'а нужен trace_id, который проходит через ВСЕ компоненты - это требует propagation в каждом HTTP-клиенте и worker'е - объяснить sampling в трейсах: head-based (решение на входе) vs tail-based (после завершения, видя ошибки)

Подводные камни

• ✗ Класть user_id в metric label - получишь cardinality explosion
• ✗ Думать что логи заменяют метрики - не масштабируется по cost
• ✗ Не передавать trace_id между сервисами - трейсы оборвутся

Follow-up

• ? Что такое exemplars в Prometheus и зачем они нужны?
• ? Чем head-based sampling отличается от tail-based?
• ? Почему Loki хранит логи дешевле Elasticsearch?

Что отвечать

`journalctl --since "1 hour ago" -p err` - все записи priority >= err за последний час. `-u nginx.service` фильтр по unit. `_PID=1234` по конкретному PID. `-f` для live tail. `-o json-pretty` для structured output, удобно парсить через jq. Главное преимущество journalctl над `tail /var/log/syslog` - structured-поля и фильтрация без grep-цепочек.

Что хотят услышать

Кандидат должен: - назвать priority-уровни (0=emerg, 3=err, 4=warning, 7=debug) - стандарт syslog RFC 5424 - различить временные фильтры (`--since`, `--until`, `--since today`) и unit-фильтры (`-u`, `--user-unit`) - сказать что journald хранит persistent при `Storage=persistent` в `/etc/systemd/journald.conf`, иначе в RAM и теряется при ребуте - упомянуть `journalctl --vacuum-size=1G` для очистки - назвать `_TRANSPORT`, `_SYSTEMD_UNIT`, `_PID`, `_UID` как примеры structured-полей, по которым можно фильтровать

Подводные камни

• ✗ Использовать `grep ERROR | journalctl` - порядок неправильный, и теряется structured
• ✗ Не настроить persistent storage - после ребута логи пропали
• ✗ Не знать что `journalctl -k` - kernel-ring-buffer (dmesg), отдельный канал

Follow-up

• ? Чем `journalctl -k` отличается от `dmesg`?
• ? Как настроить forwarding journald в syslog или Loki?
• ? Что делать если journal вырос до 50G и забил диск?

Что отвечать

Каждая уникальная комбинация (metric_name, labels) - отдельный time series. Один высоко-кардинальный label (user_id, trace_id, path с ID) умножает count series в тысячи раз. 10M series ≈ 30GB RAM на Prometheus. Лечение: drop label через `metric_relabel_configs`, нормализовать URL paths в коде (`/api/users/:id` вместо `/api/users/12345`), либо перевести в логи/трейсы (там high-cardinality нормально).

Что хотят услышать

Senior должен: - назвать «правило 3 KB на series» как rule of thumb для Prometheus - объяснить почему cardinality multiplicative: 2 method x 5 status x 100 endpoint x 1000 user = 1M series (а не сумма) - сказать про `topk(20, count by (__name__)({...}))` как первую команду диагностики при OOM - упомянуть VictoriaMetrics/Thanos как масштаб-решение, но не замена дисциплины с label'ами - назвать что Loki structured_metadata (Loki 3.0+) - правильное место для high-cardinality идентификаторов

Подводные камни

• ✗ Добавить request_id в metric label потому что «удобно фильтровать»
• ✗ Думать что VictoriaMetrics решит cardinality - даст запас, но не починит причину
• ✗ Не делать route normalization - каждый ID в URL = новый label

Follow-up

• ? Какой PromQL покажет series-count по каждой метрике?
• ? Что делает `histogram_quantile` и почему histograms cardinality-friendly?
• ? Чем Loki structured_metadata отличается от обычных labels?