DevOps MemOps
6.26K subscribers
3.22K photos
528 videos
16 files
5.15K links
Всё о DevOps

Для связи - @raz_raz
Заказать рекламу через биржу: https://telega.in/c/devops_memops
Download Telegram
MemOps 😃
Please open Telegram to view this post
VIEW IN TELEGRAM
😁16
Из статьи "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 🤨
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
MemOps 😃
Please open Telegram to view this post
VIEW IN TELEGRAM
😁29
Metric cardinality limits in OpenTelemetry: a practical guide

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

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

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

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

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

MemOps 🤨
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
MemOps 😃
Please open Telegram to view this post
VIEW IN TELEGRAM
😁10
Please open Telegram to view this post
VIEW IN TELEGRAM
Mastering Log Rotation in Linux with Logrotate

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

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

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

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


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

MemOps 🤨
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
Как мы перестроили архитектуру нашего 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 🤨
Please open Telegram to view this post
VIEW IN TELEGRAM
1
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
Как мониторить 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 🤨
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
Please open Telegram to view this post
VIEW IN TELEGRAM
14🫡2🤯1
Please open Telegram to view this post
VIEW IN TELEGRAM
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 🤨
Please open Telegram to view this post
VIEW IN TELEGRAM
3
MemOps 😃
Please open Telegram to view this post
VIEW IN TELEGRAM
😁4