MemOps 😃

VictoriaLogs Deployment: Single Node vs Cluster Mode — A Comprehensive Guide

В статье разбираются оба варианта: single-node и cluster mode, с практическими примерами установки, настройкой Filebeat, подключением Grafana и базовым алертингом.

Ключевая мысль простая: single-node хорошо подходит для небольших и средних нагрузок, а кластер имеет смысл разворачивать, когда появляются требования к горизонтальному масштабированию, высокой доступности и устойчивости при больших объёмах логов.

Автор показывает архитектуру кластера VictoriaLogs: vlinsert принимает данные, vlstorage отвечает за хранение, а vlselect — за запросы. Также есть понятный сценарий миграции с одной ноды на кластер без полной перестройки ingestion-пайплайна.

В статье разбираются оба варианта: single-node и cluster mode, с практическими примерами установки, настройкой Filebeat, подключением Grafana и базовым алертингом.

Ключевая мысль простая: single-node хорошо подходит для небольших и средних нагрузок, где важны простота и экономия ресурсов. Кластер имеет смысл, когда появляются требования к горизонтальному масштабированию, высокой доступности и устойчивости при больших объёмах логов.

Автор показывает саму архитектуру кластера VictoriaLogs: vlinsert принимает данные, vlstorage отвечает за хранение, а vlselect — за запросы. Плюс есть понятный сценарий миграции с одной ноды на кластер без полной перестройки ingestion-пайплайна.

📌 Подробнее: https://medium.com/@btech-engineering/victorialogs-deployment-single-node-vs-cluster-mode-a-comprehensive-guide-24284c0d1134

MemOps 🤨

MemOps 😃

Из статьи "Automating Penetration Testing with SecureCodeBox on Kubernetes Kind Clusters Using GitHub Actions" вы узнаете как можно автоматизировать пентест с помощью проекта SecureCodeBox, который работает как Kubernetes оператор.

📌 Подробнее: https://medium.com/@gyasmine29/automating-penetration-testing-with-securecodebox-on-kubernetes-kind-clusters-using-github-actions-27230b8b087c

MemOps 🤨

MemOps 😃

Metric cardinality limits in OpenTelemetry: a practical guide

Метрики OpenTelemetry разработаны таким образом, чтобы их было безопасно использовать в проде. Одним из элементов этой безопасности является ограничение кардинальности в SDK метрик. Это ограничение защищает от неограниченного роста объема памяти, когда метрика получает слишком много уникальных комбинаций атрибутов.

Такая защита полезна, но у неё есть последствие, которого многие пользователи не ожидают: при переполнении потока метрик общее значение остаётся корректным, в то время как запросы, фильтрующие или группирующие данные по атрибутам, могут занижать его. Это может повлиять на панели мониторинга, цели уровня обслуживания (SLO) и оповещения, которые выглядели корректно до начала переполнения.

В документации теперь есть раздел Ограничения кардинальности, который объясняет поведение SDK.

Эта статья в блоге OpenTelemetry — оперативное дополнение к этой части документации. В ней объясняется, что означает ограничение на практике, почему это влияет на каждый атрибут измерения, в котором произошло переполнение, как выбрать разумное ограничение, как проверить, достигнуто ли оно уже, и как отслеживать его в проде.

📌 Подробнее: https://opentelemetry.io/blog/2026/cardinality-limits-in-opentelemetry/

MemOps 🤨

MemOps 😃

Mastering Log Rotation in Linux with Logrotate

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

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

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

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

📌 Подробнее: https://www.dash0.com/guides/log-rotation-linux-logrotate

MemOps 🤨

MemOps 😃

Как мы перестроили архитектуру нашего Vault с использованием Raft, снимков и аварийного восстановления

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

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

📌 Подробнее: https://medium.com/@BioCatchTechBlog/how-we-rebuilt-our-vault-architecture-with-raft-snapshots-and-dr-b6789ea5fa28

MemOps 🤨

MemOps 😃

Как мониторить Java-приложения: метрики, алерты и правило 80/20

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

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

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

📌 Подробнее: https://habr.com/ru/companies/yandex/articles/1068874/

MemOps 🤨

MemOps 😃

Kubernetes и энергопотребление

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

📌 Подробнее: https://kubernetespodcast.com/episode/270-kepler/

MemOps 🤨

MemOps 😃