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 🤨