MemOps 😃

Kafka в Kubernetes: Уроки производительности для любого сервиса обработки данных с большим объемом данных на диске

Недавно мы начали переносить кластеры Kafka с EC2 на EKS с помощью Strimzi. Как только мы переместили первый кластер, мы увидели постоянное чтение данных с диска через брокеров и более высокую задержку, чем мы ожидали на сопоставимом оборудовании.

📌 Подробнее: https://dev.to/yaakovamar/kafka-on-kubernetes-performance-lessons-for-any-disk-heavy-data-service-3bl5

MemOps🤨

MemOps 😃

Мои эксперименты с MCP: выход за рамки «обёртки агента»

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

📌 Подробнее: https://godfreym.medium.com/my-experiments-with-mcp-moving-beyond-the-agent-wrapper-4142bb920f4a

MemOps🤨

MemOps 😃

В официальном блоге Kubernetes появилась заметка "Kubernetes v1.37: Hardening Container Storage with Bind Mount Options and EmptyDir Permissions". Она описывает новые возможности по безопасности хранилищ (Storage):
1) Права доступа на emptyDir - на пример 01777 через emptyDir mode
2) bind mount опции - такие как noexec, nodev, nosuid через bindMountOptions 

Обе фичи находятся в Alpha статусе и называются VolumeBindMountOptions и EmptyDirVolumeMode.

📌 Подробнее: https://kubernetes.io/blog/2026/09/16/kubernetes-v1-37-hardening-container-storage/

MemOps🤨

MemOps 😃

Создание реального набора тестов k6 на основе живого приложения Kubernetes

В части 1 я рассказал о философии k6 и особенностях первого теста. В этом посте рассказывается о том, как все стало по—настоящему - о тестовом наборе производственного уровня, запущенном в реальном времени с приложением для микросервисов в кластере homelab Kubernetes, в том числе о том, что пошло не так при первом запуске и как я это отладил.

📌 Подробнее: https://dev.to/matthew_wimpelberg_79193b/part-2-of-4-building-a-real-k6-test-suite-against-a-live-kubernetes-app-1f81

MemOps🤨

MemOps 😃

Чем заменить top, ps и netstat в 2026 году, и когда их лучше не трогать

Netstat давно считается устаревшим, ps aux может обрезать командные строки, а стандартный top придётся донастраивать… Однако мы всё равно набираем эти три команды для проверки, потому что так было написано в учебниках.

Для тех, кто не в теме, top, ps и netstat — это классическая троица из каждого Linux-учебника. Эти утилиты нужны, чтобы следить за процессами, памятью и сетевыми соединениями. 

В статье рассказывают, что реально стоит использовать вместо классики, и где старое-доброе всё ещё уместно.

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

MemOps🤨

MemOps 😃

От входа к шлюзовому API: Как мы модернизировали сеть в нашем кластере GKE

Недавно мы перенесли наш производственный кластер GKE с традиционного контроллера Ingress на API Kubernetes Gateway — и, честно говоря, нам следовало сделать это раньше.

📌 Подробнее: https://the-devops-engineer.medium.com/from-ingress-to-gateway-api-how-we-modernized-networking-on-our-gke-cluster-8409ffb53173

MemOps🤨

MemOps 😃

Как находить нестабильные тесты с помощью merge queue и main

Если merge queue гарантирует, что каждый коммит в main прошёл тесты, любой последующий сбой полного прогона на main можно считать нестабильным тестом. Поэтому не отключайте такой прогон после слияния изменений.

Собирайте свежие падения на main в один доступный список. Он покажет, какие сбои повторяются чаще, и поможет увидеть связь между ними. Начинайте исправление с причин, которые ломают больше всего прогонов.

Причиной бывает ошибка в допущениях о порядке выполнения или сбой инфраструктуры: например, не скачался релиз с GitHub либо Windows не удалила каталог. В заметке Catch Flakes On Main автор объясняет, почему этот процесс отделяет нестабильность от настоящих регрессий.

📌 Подробнее: https://matklad.github.io/2026/05/14/catch-flakes-on-main.html

MemOps🤨

MemOps 😃

Как отслеживать сбои и замедление тестов Cypress в Grafana Cloud

Один лог CI не показывает, какой тест постепенно замедляется или периодически падает. В Cypress 14.x хук after:spec после каждого файла со сценариями получает число успешных и неуспешных тестов и их длительность. Код преобразует данные в метрики Prometheus.

Короткий процесс Cypress нельзя опросить напрямую, поэтому он отправляет метрики в Prometheus Pushgateway. Тот хранит их между запусками, а Alloy периодически забирает и пересылает в Grafana Cloud Metrics. Общий run_id объединяет файлы одного запуска на дашборде.

Ошибку отправки ловят через try/catch, чтобы сбой мониторинга не ронял успешный прогон. Код, конфигурация и набор метрик есть в пошаговом разборе Grafana Labs.

📌 Подробнее: https://grafana.com/blog/how-to-monitor-cypress-tests-with-grafana-cloud/

MemOps🤨

MemOps 😃

Nerdlog — просмотр логов с нескольких серверов без ELK, Graylog и центрального хранилища

Интересный инструмент для тех случаев, когда нужно быстро проанализировать логи на нескольких Linux-серверах, но разворачивать полноценную систему централизованного логирования избыточно.

Nerdlog — это терминальный UI-интерфейс, который подключается к удалённым машинам по SSH, выполняет обработку логов непосредственно на них, а затем объединяет результаты в одном окне.

По умолчанию Nerdlog умеет работать с:

— /var/log/messages и /var/log/syslog;

— ротируемыми логами;

— выводом journalctl;

— произвольными текстовыми логами;

— базовым форматом логов Apache.

Можно одновременно искать события на нескольких серверах, ограничивать запрос временным диапазоном и фильтровать строки с помощью выражений в awk-формате. Результаты от разных узлов объединяются в общую таблицу.

Главная особенность интерфейса — интерактивная временная гистограмма, напоминающая Kibana или Graylog. На ней виден всплеск ошибок. Есть история запросов, постраничная загрузка, Vim-подобное управление и возможность скопировать текущий запрос в виде команды, чтобы передать его коллеге.

При этом полные файлы на рабочую машину не скачиваются. Фильтрация и построение гистограммы выполняются на удалённых узлах, а по сети передаются только найденные сообщения и агрегированные данные.

Результаты дополнительно сжимаются. Количество загружаемых строк можно ограничить — по умолчанию это до 250 сообщений с каждого потока.

Клиент работает на Linux, macOS, FreeBSD и Windows, но получать логи с Windows-хостов пока нельзя. Nerdlog написан на Go, а готовые бинарники доступны в GitHub Releases.

📌 GitHub

📌 Готовые сборки

📌 Документация и ограничения

MemOps🤨