HUATUO — eBPF-наблюдаемость и автоматическая диагностика ядра Linux

HUATUO — open source-платформа для глубокой наблюдаемости Linux, созданная в DiDi (китайская служба такси). Она работает на уровне ядра и помогает разбирать проблемы, которые сложно диагностировать с помощью обычных метрик приложений: задержки планировщика, блокировки процессов, memory reclaim, OOM, сетевые потери, аномалии дискового I/O и всплески системного CPU.

Под капотом HUATUO работают eBPF, kprobe, tracepoint и ftrace. Инструмент собирает данные без модификации приложений и может автоматически связывать их с Kubernetes-контейнерами, labels и annotations.

В HUATUO есть несколько режимов работы:

Metrics — постоянный сбор показателей CPU, памяти, сети, планировщика и дисковой подсистемы. Метрики публикуются в формате Prometheus.

Events — фиксация событий ядра: OOM, soft lockup, hung task, packet drop, аномальный memory reclaim и сетевые задержки.

AutoTracing — автоматический запуск углублённой диагностики при обнаружении аномалии. Например, при резком росте CPU sys, накоплении процессов в D-state, всплеске аллокаций памяти или проблемах с I/O.

Continuous Profiling — построение flame graph и анализ on-CPU, off-CPU и memory-профилей для C, C++, Go, Java и Python.

AutoTracing выглядит особенно полезным: детальная диагностика включается не после обращения пользователя, а непосредственно в момент срабатывания алерта. В результате сохраняются call stacks, список процессов, контекст контейнера и flame graph, необходимые для последующего RCA.

HUATUO нативно интегрируется с Prometheus, Grafana, Elasticsearch и Pyroscope.

Репыч на GitHub

Документация

@usr_bin_linux

Kubernetes NodeLocal DNSCache: ускоряем DNS-запросы 🚀

Без NodeLocal DNSCache DNS-запрос от Pod проходит через:

Service IP → kube-proxy → DNAT → conntrack → CoreDNS

В нагруженных кластерах это увеличивает задержки и создаёт дополнительную нагрузку на таблицу conntrack.

NodeLocal DNSCache запускает локальный DNS-кеш на каждой ноде как DaemonSet:

Pod → локальный DNS-кеш → CoreDNS

Если запись уже есть в кеше, Pod получает ответ прямо с текущей ноды. При промахе запрос передаётся в CoreDNS.

Преимущества

- быстрее обрабатываются повторные DNS-запросы;
- снижается нагрузка на CoreDNS;
- уменьшается межнодовый DNS-трафик;
- обходятся kube-proxy и DNAT;
- сокращается количество UDP-записей в conntrack;
- доступны DNS-метрики отдельно для каждой ноды.

NodeLocal DNSCache стабилен с Kubernetes 1.18, но обычно его нужно включать отдельно и развернуть node-local-dns как DaemonSet.

🔗 Официальная документация Kubernetes: https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/

Несколько лет назад я написал целый цикл постов на тему виртуализации. Мотивация - расставить все точки над и, разобраться что есть что. Провести параллели и границы между контейнерами, виртуалками, а также объяснить понянтным языком что же такое Docker. Получилось 4 поста:
- Введение в виртуализацию. Какая бывает, какие проблемы решает
- Аппаратная виртуализация
- Виртуализация на уровне ОС (Контейнеризация)
- Истинно ли утверждение что Контейнеры это Docker?

Почему я вспомнил об этих постах? Мой товарищ Никита у себя в канале взялся еще глубже препарировать тему и уже опубликовал пост о продвинутых технологиях на стыке виртуалок и контейнеров. Он посвящен OCI и тому что современные контейнеры стремятся быть абстракцией поверх VM, а не чем-то сбоку. И дальше идет разбор софта подтверждающего этот тезис.

🔖Контейнер ≠ Docker [1/3] by DevOps Brain

Буду читать сам, поэтому могу смело советовать😊 Если вам такие посты заходят поддержите Никитоса лайком и подпиской❤️

Docker для параноика: организация SSH‑доступа для rootless‑контейнера без передачи приватного ключа

Примонтировать ~/.ssh в контейнер с флагом :ro — и вроде как позаботился о безопасности. Только приватный ключ при этом всё ещё можно прочитать и утащить. От этого read-only не спасает.

В этом разборе на Хабре рассказывают о том, как дать rootless-контейнеру SSH-доступ через ssh-agent, оставив сам ключ на хосте. Пригодится для автоматизации, работы с приватными репозиториями и ИИ-агентов, которым нужен Git.

Rootless Docker имеет свои нюансы: UID пользователя внутри контейнера преобразуется в другой UID на хосте, поэтому просто пробросить сокет агента недостаточно.

Оказывается, доступ к сокету всё ещё позволяет пользоваться загруженным ключом. Если контейнер взломали, злоумышленник сможет выполнять доступные этой SSH-идентичности операции, пока имеет доступ к агенту. Сам приватный ключ через штатный протокол агента при этом не выдаётся.

@usr_bin_linux

KYAML vs YAML: зачем усложнять простое?

YAML давно стал привычным инструментом для DevOps. Но у него есть обратная сторона: неявные типы, зависимость структуры от отступов и множество возможностей, которые Kubernetes на самом деле не использует.

Kubernetes предлагает более строгий подход к конфигурациям — KYAML и описывает его преймущества в своем блоге. Идея в том, чтобы оставить от YAML только то, что действительно нужно Kubernetes, и убрать неоднозначности.

Что получает DevOps?
🟡 меньше зависимости от отступов;
🟡 более предсказуемую работу со строками и типами;
🟡 явное обозначение списков [] и структур {};
🟡 более удобную работу с генерацией, шаблонами и автоматизацией;
🟡 KYAML остаётся валидным YAML и рассчитан на совместимость с существующими YAML-парсерами.

Но есть и другая сторона. Среди обсуждений инженеров можно встретить мнение, что KYAML не избавляет Kubernetes-конфиги от сложности, объясняя это тем, что: 
🟡 KYAML не уберёт Helm-шаблоны, огромные манифесты и десятки взаимосвязанных параметров. А значит, вместо решения основной проблемы можно получить ещё один формат, который команде придётся изучать и поддерживать;
🟡YAML уже встроен практически во всю DevOps-экосистему — от IDE и линтеров до CI/CD-инструментов. KYAML — новый подход, а значит, не все инструменты одинаково хорошо его поддерживают.

И здесь возникает главный вопрос:
KYAML действительно решает проблемы YAML — или просто вводит более строгие правила там, где и так всё работало?

👀 А вы бы использовали KYAML в своих проектах, либо же обычного YAML вам вполне хватает? Поделитесь мыслями.

Wheel of Misfortune, но с настоящим прод‑инцидентом внутри
Полгода назад я писал, зачем SRE нужна Wheel of Misfortune: ролевая игра про инцидент, где ведущий рассказывает, что видит дежурный, а дежурный говорит, что бы он сделал.
Полезно, дёшево, но есть одна честная проблема: это разговор. Никто ничего не чинит. «Я бы посмотрел describe pod» звучит одинаково у того, кто делал это сто раз, и у того, кто ни разу.

И тут я подгорел и сделал платформу, где инцидент настоящий, тк инцидентное мышление тренируется руками, а не словами.

Вашему вниманию - тренажёр инцидентов с живыми окружениями.

WoM Platform

Заходишь, выбираешь сценарий (или крутишь колесо), и через пару секунд для Linux‑хоста или через минуту для Kubernetes у тебя в браузере терминал в изолированный стенд, который уже сломан.
Nginx отдаёт 502, диск базы забит бинлогами, rollout завис на квоте, HPA пилит сам себя, cert-manager не может продлить сертификат.
Чинишь как на настоящем дежурстве (как будто бл* на работе мне этого не хватает, ага): логи, ss, df, kubectl describe, kubectl edit.
Жмёшь «Проверить» - грейдер смотрит на результат, а не на способ: любой честный путь засчитывается, «убрать пробу» или «поднять лимит памяти» - нет.
После решения открывается разбор: что было сломано, как диагностируется, эталонное решение, ловушки, что почитать.

Что уже готово
22 живых сценария от Junior до Senior.
Для джунов - учебные копии. У каждого junior‑кейса две версии: обычная и учебная с панелью «Нужна помощь?», которая открывает этапы диагностики по одному и объясняет, зачем нужна каждая команда. Не «вот ответ», а «вот куда смотреть и почему». Плюс шпаргалка и что почитать заранее.
Стенды настоящие. Каждый сценарий проходит регресс: свежий стенд не решён, эталонное решение решает, ловушки не проходят.

Ограничения, чтобы не было сюрпризов
Одновременно живут до 6 Kubernetes‑стендов и до 20 сессий всего, а поднимаются они по два за раз: если увидите «ждём свободный слот» или «занято», это не поломка, подождите пару минут.
Неиспользуемые 7 дней учётки отключаются автоматически. Почты пока нет, так что если не пускает или еще какие то проблемы - напишите мне, пожалуйста.
Тяжёлые стенды (cert-manager, Prometheus, ingress) поднимаются 2–3 минуты, на странице видно, что именно сейчас происходит.

Что планирую дальше?
Заопенсорсить, что бы вы могли кидать свои кейсы сами и разворачивать это у себя. Ну или смотреть как это сделано у меня и сделать лучше для себя и под себя.
Прикрутить почту, что бы была нормальная регистрация по email. Ну и конечно же, больше и больше кейсов.

И еще пару слов
Бекенд писал сам, старался и мучался как мог что бы работало классно и интересно. Кейсы тоже из своей практики. Но вот UI пришлось допиливать через openai. Ну не умею я во фронт так хорошо что бы было не больно.

Вопрос к вам: какой инцидент из вашей практики вы бы превратили в сценарий первым? Присылайте пост‑мортемы, самые интересные сделаю и опубликую с указанием автора.

#SRE #WheelOfMisfortune #oncall #kubernetes #incident_response

Netronome — self-hosted-мониторинг качества сети и интернет-каналов

Если Speedtest Tracker, который я упоминал одном из прошлых постов, в первую очередь собирает историю тестов скорости, то Netronome идёт дальше: объединяет проверку пропускной способности, диагностику маршрутов и мониторинг удалённых серверов.

Что умеет Netronome:

— запускать тесты через Speedtest.net, LibreSpeed и iperf3;

— выполнять проверки автоматически по расписанию;

— сохранять историю скорости, задержки и других показателей;

— непрерывно контролировать потерю пакетов через ICMP;

— анализировать маршрут с помощью traceroute и MTR;

— показывать статистику потерь отдельно по каждому узлу маршрута;

— контролировать DNS-запросы;

— собирать с удалённых серверов загрузку CPU, память, диски, температуру и сетевой трафик;

— отправлять уведомления в Telegram, Discord, email и другие сервисы через Shoutrrr.

Для распределённого мониторинга используются легковесные агенты. Их можно установить на домашних серверах или удалённых площадках, а результаты свести в один веб-интерфейс. Есть интеграция с Tailscale и автоматическое обнаружение агентов внутри tailnet — удобно, если не хочется публиковать служебные порты в интернете.

Netronome потенциально может подойти в сценариях:

— контроля качества домашнего или офисного интернет-канала;

— сравнения фактической скорости с тарифом провайдера;

— мониторинга связи между филиалами через iperf3;

— поиска участка маршрута, на котором начинаются потери;

— наблюдения за серверами без развёртывания полноценного стека Prometheus;

— контроля трафика VPN-контейнеров, например Gluetun.

Само приложение написано на Go, а интерфейс — на React и TypeScript. Frontend и backend упакованы в один исполняемый файл. По данным разработчиков, типичное потребление памяти составляет около 35 МБ. Для хранения можно использовать SQLite или PostgreSQL.

Развернуть Netronome можно готовым бинарником либо в Docker. В контейнерный образ уже включены iperf3, LibreSpeed CLI, traceroute, MTR и vnstat. Есть встроенная авторизация, OIDC и ограничение доступа по IP.

Из нюансов: тесты скорости создают реальную нагрузку на канал, поэтому расписание нужно выбирать аккуратно. Для полноценной работы MTR потребуются дополнительные привилегии, а некоторые функции при установке без Docker зависят от внешних утилит.

Основная функциональность распространяется на бесплатной основе, но разрабы отдельно предлагают платный набор дополнительных тем интерфейса.

Репыч на GitHub

@usr_bin_linux

Когда мы слышим Redis, обычно первое, что приходит на ум - это кэш.
Но Redis удивительно простая и при этом универсальная технология, которую можно применять для широкого круга задач.

В новом видео за 36 минут кратко разобрали все что нужно знать про Redis для System Design: https://www.youtube.com/watch?v=mlIB7AOG-GU

Рассмотрели 7 различных сценариев Redis:
• cache
• rate limiter
• leaderboards / priority queues
• geosearch
• distributed locks
• Streams
• Pub/Sub

Выложили доклады с DevOops 2025

YT: https://www.youtube.com/playlist?list=PL-ety8gh7rTqGi8ulve-IUZ9O5tpUo0dX
VK: https://vkvideo.ru/playlist/-149053226_21

Программа
https://devoops.ru/archive/2025/schedule/table/

Вот вроде очевидно, но нет

Сбор метрик или отправка метрик - разница, которая может искривлять данные

Привет, киты 🐳!

Если вы думаете, что сбор метрик по pull-модели и отправка через push это примерно одно и то же, то я вас разочарую. Это не так. В push-модели есть особенности, которые заставят ваши данные выглядеть совсем не так, как вы ожидаете. А иногда разработчики пытаются писать метрики в VictoriaMetrics Remote-write эндпоинт в том же формате, что и для Prometheus PushGateway, а потом искренне удивляются, почему метрики не появляются. Многообразие форматов действительно может породить путаницу.

Зачем вообще отправлять метрики напрямую, вместо обычного вытягивания из эндпоинта /metrics?

Для короткоживущих приложений интервал сбора при pull-модели может оказаться больше времени работы самого приложения. Сборщик просто не придет. Частый пример: cron-задачи или PHP-приложения, которые живут только на время обработки запроса. Тут push метрик спасает. Хотя нет, вру, можно придумать свое костыльное хранилище на Redis и выставить их для сбора на /metrics. Но по факту это просто изобретение PushGateway, которое тащит лишнюю зависимость.

Кстати, для cron-задач, которые выполняются более 3-5 минут, я рекомендую выставлять отдельный /metrics эндпоинт и настраивать обычный pull-сбор. Это оправдано, когда вы хотите следить за прогрессом задачи в реальном времени, а не только получить данные о факте ее начала и окончания.

Но вернемся к граблям. Вот кусочек из кода модуля для отправки метрик в Prometheus PushGateway, с которым мы столкнулись:

return &Pusher{
    inner: push.New(endpoint, serviceName). // выставить в метрике job=serviceName
        Gatherer(gatherer).
        Grouping("k8s_cluster_name", cfg.clusterName).
        Grouping("k8s_namespace_name", cfg.namespace).
        Grouping("k8s_pod_name", cfg.podName).
        Grouping("k8s_cronjob_name", cfg.cronjobName).
        Grouping("k8s_job_name", cfg.jobName)
}

Вы можете по ошибке решить, что здесь добавляются лейблы в метрику. Но это не так (хотя Prometheus и увидит их как лейблы при сборе). Для самого PushGateway Grouping это как адрес книги в библиотеке (ряд, полка, раздел). Он отвечает за физическое хранение переданной в него группы метрик в памяти шлюза.

В PushGateway есть два поведения: перезаписывать (Push) и добавлять (Add). Для cron-задач подходит перезапись, так как нам важны данные о последнем запуске. Но в примере выше Grouping неверный. Если засунуть динамические значения (например имя пода) в Grouping, для каждого запуска cron или каждого пода создается новый адрес хранения. В итоге вы не видите полной картины по одной задаче. Хуже того, старые ячейки с метриками мертвых подов останутся в PushGateway навсегда. Он не удаляет метрики сам по TTL, поэтому они будут копиться как мусор, пока их не очистят через API. Это классическая утечка памяти.

Как это чинить?

Grouping key должен быть стабильным. Для cron-задач оставить в grouping только job (имя сервиса) и instance (имя самого крона). Всё остальное (namespace, pod_name и прочее) перенести в обычные лейблы метрик. Это решит проблему с мусором и некорректными графиками.

А вы используете PushGateway в своих проектах или стараетесь избегать его любой ценой, перестраивая архитектуру под pull? И сталкивались ли с проблемой вечных метрик в PushGateway после смерти подов?

#SRE #prometheus #PushGateway #observability #метрики #DevOps #ЛетитКит

20 октября в 12:00 (мск) пройдёт бесплатный вебинар «Мониторинг событий безопасности в MWS Cloud Platform».

Разработчики сервиса:

✅ Расскажут про возможности сервиса аудитных логов в облаке MWS Cloud Platform
Покажут в прямом эфире, как экспортировать их в SIEM-системы

✅ Вебинар будет полезен CISO, ИБ-специалистам, DevOps-инженерам и SOC-специалистам. Регистрируйтесь, подключайтесь к прямому эфиру и задавайте вопросы в чате.

🗓 20 октября в 12:00

Зарегистрироваться

Семь привычек Linux-инженера, которые спасают прод

Внутри — семь разборов сбоев: от прав на домашнюю директорию до деградации производительности после обновления ядра.

Интересный кейс про бэкапы между дата-центрами. Скорость упиралась примерно в 1 Гбит/с, и ровная полка на графике выглядела как сетевое ограничение. Но отдельный тест показал, что канал спокойно отдаёт свои 5 Гбит/с. Дальше выяснилось, что rsync поверх SSH упирался в производительность одного ядра, а сжатие и дедупликация добавляли дополнительную нагрузку.

Читать дальше на Хабре →

@usr_bin_linux