Kubernetes поставляется со встроенной функцией отслеживания загрузки CPU и использования памяти, но большинство решений по масштабированию в реальных условиях зависят от сигналов, которые находятся за пределами этого узкого диапазона: сколько сообщений ожидает в очереди, сколько времени заняла последняя пакетная задача, сколько активных WebSocket-соединений поддерживает под. Когда встроенных метрик недостаточно, экспортер метрик восполняет этот пробел.

В этой статье подробно описано, как создать такой контейнер с нуля, упаковать его в подобие контейнера и подключить к кластеру, чтобы Prometheus — и в конечном итоге HorizontalPodAutoscaler — могли его использовать.

В этой статье мы проследим путь одной записи лога — от поступления в VictoriaLogs до окончательного размещения на диске. Это поможет представить, что происходит внутри системы, и понять наблюдаемое поведение: почему запросы выполняются быстро, почему на диске иногда появляется множество файлов и какие флаги и метрики важны при поиске неполадок. Статья рассчитана на широкую аудиторию: не требуется ни опыт программирования, ни знание Go.

Кажется, в observability снова выбор без выбора: Grafana или ClickStack?

Статья разбирает вопрос выбора на примере ClickHouse. Если ClickHouse — центральное хранилище телеметрии, а инженеры чаще расследуют инциденты, чем смотрят на заранее созданные графики, авторы предлагают смотреть в сторону ClickStack: поиск, корреляция логов, метрик и трейсов, session replay и отдельный акцент на AI/SRE-агентов через MCP.

Grafana остаётся сильнее там, где инфраструктура неоднородная: Prometheus, ClickHouse и ещё десяток источников, которые нужно собрать на одном дашборде, добавить алертинг и не заставлять команду менять привычные процессы.

Так как статья опубликована в блоге Clickhouse, практичный вывод напрашивается сам собой: «А зачем выбирать?» Grafana можно оставить для дашбордов и мониторинга, а ClickStack использовать для глубоких расследований по данным ClickHouse. Причём данные и ingestion pipeline дублировать не придётся.

Функция Kubernetes NodeSwap, которая, вероятно, перейдет в статус стабильной в предстоящем выпуске Kubernetes v1.34, позволяет использовать swap: это значительный сдвиг от обычной практики отключения swap для обеспечения предсказуемости производительности. Эта статья посвящена исключительно настройке swap на узлах Linux, углубляясь в критические параметры ядра Linux, которые управляют поведением swap, и в том, как они влияют на производительность рабочих нагрузок, использование swap и механизмы изгнания.

Docker Swarm может быть жив или мёртв — вопрос спорный, но сама ниша никуда не делась. И такие проекты, как Kamal (от 37signals) и Uncloud (от Паши Свидерского), пытаются её закрыть.

Если вы ещё не слышали про последний, Uncloud — это лёгкий (по сравнению с Kubernetes) инструмент для деплоя и управления контейнеризованными приложениями в сети Docker-хостов.

Антон Овчинников недавно опубликовал пошаговый гайд на iximiuz Labs, в котором показано, как развернуть кластер Uncloud на нескольких VM. Традиционно, все команды из туториала можно прогнать прямо в приложенной песочнице.

В вашем кластере есть Pod с ошибкой. Он пытается запуститься, но не может пройти инициализацию. Судя по всему, недавно в его спецификацию добавили новый контейнер, и с этого момента Pod перестал нормально работать. Сможете починить?