Logrotate — тот самый компонент, про который обычно вспоминают в двух случаях:

— когда закончилось место на диске;

— когда после ротации внезапно выяснилось, что приложение продолжало писать не туда

Статья разбирает, что происходит под капотом утилиты: когда использовать size, чем minsize отличается от maxsize, почему create обычно безопаснее и за что можно не любить copytruncate — у него есть небольшое окно, в котором часть логов действительно может потеряться.

Управление секретами в масштабе — это не просто безопасность, это доступность, отказоустойчивость и экономическая эффективность. В BioCatch мы используем HashiCorp Vault для управления секретами в нашей среде Kubernetes, но наша начальная конфигурация оставляла место для улучшений.

Вот как мы перепроектировали архитектуру Vault, используя хранилище Raft, автоматизацию Kubernetes и аварийное восстановление на основе снимков, в результате чего получилась система, которая обладает высокой доступностью, экономически эффективна и готова к работе в производственной среде.

Хороший мониторинг помогает быстро понять, что происходит с приложением и куда смотреть в первую очередь. Для этого не нужно пытаться измерить всё: базовый набор технических метрик покрывает большинство типовых проблем, а бизнес-метрики, SLO и анализ аномалий помогают заранее замечать нетипичные отклонения. В Календаре мы называем этот подход правилом 80/20.
Всем привет! Меня зовут Настя, я бэкенд-разработчик в Яндекс 360 и отвечаю за надёжность Календаря. В этой статье я покажу, какие метрики стоит взять за основу, как выбирать полезные алерты и чем дополнять базовый набор для оставшихся 20%.

В статье хороший разбор подхода 80/20: какие метрики реально ловят большую часть проблем, зачем следить за RED, лагами очередей, connection pool и JVM, когда нужны бизнес-метрики и SLO, и почему аномалии иногда полезнее очередного статического порога.

Отдельно плюсую за onepager, drill-down и ранбуки. Потому что хороший мониторинг — это не «у нас есть график на всё», а «мы быстро поняли, что сломалось и что делать дальше».

Kubernetes Podcast про Project Kepler — open-source проект для наблюдения за энергопотреблением Kubernetes-нагрузок.
В гостях Ники Маноледаки, Staff Platform Engineer в Grafana Labs и мейнтейнер Project Kepler. Вместе с ведущими она обсуждает, как оценивать энергопотребление рабочих нагрузок, какие метрики для этого можно собирать и почему получить реально точные данные не так просто.
Отдельно поговорили о том, зачем Kepler недавно переписали, как проект использует eBPF и Prometheus и при чём здесь растущие вычислительные нагрузки AI.

Фреймворк строит верхние и нижние границы для метрик, учитывает краткосрочную изменчивость и сезонность, а затем алертит, когда значение выходит за ожидаемый диапазон. Есть несколько стратегий детектирования: от адаптивной на основе среднего и стандартного отклонения до более устойчивой к выбросам через median/MAD.

Поддерживаются типовые сценарии для request rate, latency, errors и resource-метрик, а сами anomaly bands можно накладывать поверх графиков в Grafana.

Хороший вариант, когда хочется добавить динамический anomaly detection поверх обычного Prometheus, не таща отдельную систему анализа временных рядов.