Публикации про инцидент с xz на Хабре:

• «Можно ли было обнаружить бэкдор xz при более продуманной работе с пакетами в Git и Debian?»

• «Бэкдор в xz нашли из‑за замедления работы sshd в полсекунды».

«Я создал Castor, потому что не мог транслировать веб‑видео со своего ноутбука на телевизор: не было Chromecast, не было AirPlay. Наведите его на любую веб‑страницу, и Castor найдет видео, извлечет поток, перекодирует его для вашего телевизора и транслирует в реальном времени. Он также принимает прямой URL‑адрес потока или идентификатор IMDB/TMDB и может встраивать автоматически сгенерированные субтитры», — пояснил автор проекта.

Castor запускает Chrome в headless режиме с рандомизированным фингерпринтом и скрытыми скриптами для маскировки автоматизации. Решение отслеживает весь сетевой трафик через протокол Chrome DevTools для захвата видеопотока, а затем запускает короткий конвейер действий: кликнуть по странице, перейти в самый большой iframe, решить проблему с Cloudflare Turnstile, если таковая появится, и снова кликнуть в качестве резервного варианта.

Рассказываем, что произошло в июне и объясняем, зачем это может пригодиться.

🧠 AI Factory  —  цифровая среда для работы с генеративным ИИ
AI Agents — EvoClaw в Evolution AI Agents вышел в общий доступ и теперь покрыт SLA: сервис можно закладывать в прод без опасений.
Managed RAG — в сервисе появились OCR для doc/docx с картинками, загрузка данных через API источником Custom и полноценный API для работы с чанками. Документы из объектного хранилища синхронизируются по расписанию, а новый экстрактор разбирает аудио и видео.
ML Inference — появилась возможность при пиковых нагрузках маршрутизировать запросы с Foundation Models, чтобы производительность не падала.
Notebooks — в сервисе добавили совместное редактирование ноутбуков, управление логами и алертами без выхода из интерфейса, а также готовые дашборды мониторинга. Команда может работать над экспериментами параллельно и мгновенно обнаруживать проблемы, если они возникают.

📈 Evolution Data Platform — комплекс управляемых сервисов для работы с данными
Managed Airflow — сервис вышел в общий доступ: оркестрация данных теперь под SLA.
Managed Trino — топики Kafka теперь читаются прямо SQL-запросом без ETL, а кластер можно развернуть с одной нодой и автомасштабированием. Аналитика стриминга стала проще и дешевле.
Managed Spark —  добавили несколько улучшений в сервис; задачи теперь создаются за секунды, добавлена поддержка Gang Scheduling, чтобы они блокировали друг друга по ресурсам.
Evolution Managed Flink — сервис для работы с потоковыми данными вышел на стадию открытого тестирования, а значит настал момент, когда его функции можно оценить бесплатно и без обязательств.

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

☁️ Новости других сервисов Cloud.ru Evolution
Evolution Artifact Registry — поддержка PyPI-реестров перешла в публичный доступ: Docker-, RPM- и Python-артефакты теперь хранятся в одном месте без отдельной инфраструктуры.
Evolution Managed Kubernetes — обновили ключевые плагины (Istio, KEDA, Trivy Operator и другие), добавлен Spegel для ускорения загрузки образов, а Ingress Nginx получил поддержку PROXY-протокола.
Evolution Managed PostgreSQL — кластеры можно вручную останавливать на срок до 30 дней, платя только за диск, — заметная экономия на неактивных базах.
Evolution Managed Redis — добавлено мультизональное размещение кластеров Master/Replica: одна зона упала — кластер жив.
Evolution Distributed Train — появился Jupyter Server с мультидоступом: несколько пользователей работают в изолированных окружениях под одним сервером. Совместная работа над ML-задачами стала стабильнее и удобнее.

🏢 Cloud.ru Advanced и Облако VMware
В сервисе Advanced Data Warehouse Service поменялся интерфейс создания кластера и появились новые возможности, а в Terraform добавились новые ресурсы. 

Подробнее читайте в полной версии дайджеста.

📽️Вебинары
В июне провели четыре вебинара, записи которых уже доступны на страничке с мероприятиями. Там же можно зарегистрироваться на июльские вебинары от экспертов. 

💼 Свежие кейсы
Рассказали, как Agentic Lab запустили в продакшен ИИ-помощника для юристов, который способен выстраивать хронологию событий любого дела и быстро находить нужные сведения в огромных массивах данных.

Остаемся на связи! ✌️

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

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

21 июля в 20:00 на бесплатном уроке разберём, как сравнивать Serverless и Kubernetes для AI-ворклоадов и какие ограничения учитывать до того, как архитектурное решение превратится в дорогую миграцию. Отдельно посмотрим на холодный старт, работу с состоянием, поддержку GPU, масштабирование и гибридные сценарии.

Другие бесплатные уроки от экспертов по инфраструктуре, Linux, K8s, сетям, безопасности и наблюдаемости собрали в дайджесте.

Эта статья должна была выйти на Хабре ещё две недели назад. Но спасибо администрации Хабра за безвовзратное удаление самописной статьи: освободившееся время я потратил на финальное доведение проекта до ума. Исправил мелкие баги, улучшил документацию и так далее.

Правда, связываться с Хабром после этого желания больше нет. Поэтому полноценное описание проекта опубликовано на Hackaday, а этот короткий пост — просто выполнение обещания опубликовать статью (в прошлом месяце, ага).

---

Что такое yggvault

yggvault — самостоятельное зеркало релизов и зависимостей, упакованное в один бинарный файл.

Оно забирает выбранные версии проектов с GitHub, GitLab, Bitbucket, Gitea или другого узла yggvault, проверяет их, сохраняет локально и публикует сразу в нескольких форматах.

Один процесс предоставляет:

• совместимые с GOPROXY маршруты для Go-модулей;

• репозиторий Composer v2;

• исходные архивы .zip и .tar.gz;

• JSON API и OpenAPI;

• Atom-ленты обновлений;

• веб-интерфейс с каталогом, версиями, хешами, командами установки и ссылками на архивы.

Вся фишка в том что внешняя база данных, JVM и тд не нужны. Данные хранятся локально, а уже загруженные версии продолжают раздаваться, даже если исходный forge временно недоступен, заблокирован или упёрся в rate limit.

Зеркало можно поднять локально, на VPS или в домашней сети. Дополнительно yggvault умеет работать внутри сети Yggdrasil — без публичного IP, DNS, проброса портов, root-доступа и отдельного системного демона. (Еще одна причина для статьи — популяризация Yggdrasil)

Несколько узлов могут использовать друг друга как доверенные «братские» зеркала и синхронизировать релизы через обычный Web или Yggdrasil.

Проект не пытается быть полным реестром всех пакетов или прозрачным прокси для всего Go. Его задача проще: надёжно хранить и раздавать выбранные зависимости через контролируемую вами точку.

Репозиторий:
https://github.com/voluminor/yggvault

Работающее публичное зеркало:
https://www.ratatoskr.space/pkg/

Полная статья и технические заметки:
https://hackaday.io/project/206175-yggvault-mirror-your-dependencies-in-one-binary

FinOps по фасттреку: как искать экономию в облаке и не сломать сервис

FinOps часто описывают как полноценную методологию: Inform, Optimize, Operate, процессы, роли, регулярная аналитика, отчётность и культура потребления.

Но на практике российские компании часто приходят с другим запросом: “мы много платим за облако, нужно быстро понять, где можно снизить расходы”.

В новом выпуске «Практики FinOps» поговорили с Вячеславом Бессоновым, генеральным директором Hilbert Team.

Обсудили, как выглядит FinOps по фасттреку: когда не строят сразу всю методологию, а начинают с quick wins, анализа биллинга, гипотез оптимизации, расчёта ROI и проверки, не сломает ли экономия рабочий сервис.

В выпуске разбираем:

• почему облачного биллинга часто хватает только для первого среза

• какие задачи закрывают FinOps-инструменты, Excel и Python notebooks

• почему гипотеза оптимизации не равна готовому решению

• как считать оптимизацию как отдельный IT-проект

• когда quick win может дать 5–10%, а когда 20–30% требуют серьёзной переработки архитектуры

• почему теги у заказчиков всё ещё скорее исключение, чем правило

• как делить общую инфраструктуру между продуктами и cost centers

• чем отличается экономика on-prem от облака

• почему будущее FinOps движется к подходу workload first

• как AI-токены становятся новой частью unit-экономики

Отдельно поговорили о российском рынке: неунифицированном биллинге, сложностях мультиоблачной и гибридной инфраструктуры, резервах, внутреннем биллинге и том, почему полноценная фаза Operate часто не начинается, даже если компания уже нашла первые точки экономии.

Смотреть выпуск

YouTube
Rutube
VK Видео

Слушать выпуск

Telegram Player
Яндекс Музыка
VK Музыка

«Практики FinOps» — cообщество для тех, кто управляет затратами на IT-инфраструктуру и хочет обсуждать FinOps на практических кейсах. Мы в телеграм.

16 июля в 11:00 наши эксперты расскажут в прямом эфире о ключевых изменениях релиза 4.6 нашего флагманского продукта. Главной частью программы станет практическая демонстрация, в ходе которой специалисты покажут основные нововведения на стенде и разберут, как они работают в реальных сценариях эксплуатации виртуальной инфраструктуры. После демонстрации команда ответит на вопросы участников.

На Open Demo будут рассмотрены следующие задачи и варианты их решения:

• Неравномерная нагрузка на инфраструктуру

Продемонстрируем возможности динамической балансировки (DRS), которая автоматически перераспределяет нагрузку между узлами по гибко настраиваемым правилам, выравнивает загрузку кластера и повышает надежность.

• Рост требований к оборудованию

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

• Сервисы разного приоритета в одном кластере

Представим расширенные «Зоны», которые позволяют логически разделять ресурсы и формировать более управляемую архитектуру без лишнего усложнения инфраструктуры.

• Избыточный расход дискового пространства

Покажем возможности MultiImage и связанных клонов, которые упрощают массовое развертывание однотипных виртуальных машин и позволяют более эффективно использовать ресурсы хранилищ.

• Повышение производительности СХД по Ethernet

Рассмотрим поддержку NVMe over TCP, которая позволяет подключать современные системы хранения данных по стандартной Ethernet-инфраструктуре и получать высокую производительность без перехода на специализированные сети.

Дата: 16 июля, 11:00
Продолжительность: 60 минут
Ссылка на регистрацию: https://opendemo.ru/online_160726

Регистрация обязательна. Ссылка на трансляцию будет направлена на почту всем зарегистрированным участникам.

Когда бизнес-сервис деградирует, причина может быть где угодно: в приложении, инфраструктуре, сети, базе данных или Kubernetes-кластере. Если метрики, логи и трассировки живут в разных системах, команда тратит ценное время не на устранение инцидента, а на сбор контекста: что сломалось, где началась деградация и какие ещё сервисы затронуты.

На вебинаре 17 июля покажем, как Deckhouse Observability Platform (DOP) связывает данные по инфраструктуре и приложениям в единую картину и помогает быстрее пройти путь «алерт → локализация → первопричина». В программе:

• Обзор новых возможностей DOP: APM, распределённый веб-мониторинг, система инцидент-менеджмента, SLA/SLO-дашборды и другое.

• Разбор задач эксплуатации и инфраструктурных команд: как быстрее находить причины сбоев и снижать риск пропустить критический инцидент.

• Демо: развёртывание мониторинга с получением первых данных «из коробки» без ручной настройки.

Спикер — Владимир Гурьянов, технический директор DOP, которого вы можете знать по множеству выступлений о наблюдаемости на конференциях. Регистрируйтесь и подключайтесь 17 июля в 12:00.

Проект NtWARden:

• сканирует процессы, службы, сеть, внутренние механизмы ядра;

• обнаруживает скрытые вредоносы;

• убивает майнеры и трояны;

• показывает реальную картину нагрузки на процессор;

• помогает контролировать, что находится в системе прямо сейчас: службы, сетевые соединения, скрытые процессы;

• может подключиться к другому ПК и также отслеживать его процессы.

Открытый проект T3MP3ST превращает ИИ‑агентов в системы для поиска уязвимостей в IT‑проектах:

• это мультиагентная система, которая ищет любые уязвимости в сервисах;

• нужно только указать цель и агенты сами проведут разведку, найдут баги и предоставят отчёт;

• результаты — из 104 тестовых задач ИИ нашёл уязвимости в 90% с первой попытки.

• удобный инструмент для изучения кибербезопасности на практике.

FinOps часто начинается с облачных счетов. Но в компаниях с гибридной инфраструктурой этого быстро становится мало.

В реальной модели затрат рядом оказываются on-prem, colocation, Kubernetes, сервисные команды, закупки железа, лимиты, ФОТ, лицензии, публичные облака и новые AI-проекты. Если всё это смотреть отдельными кусками, общий IT-бюджет вроде бы есть, а ответа на вопрос «куда именно уходят деньги» всё равно нет.

В новом выпуске «Практики FinOps» поговорили с Дмитрием Деевым (@Dimperus), руководителем отдела ИТ-инфраструктуры и сервисов компании «ВсеИнструменты.ру».

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

В выпуске разбираем:

• чем ITFM отличается от классического FinOps;

• как считать гибридную инфраструктуру: ЦОДы, облака, colocation;

• почему on-prem нужно приводить к ежемесячной стоимости;

• как работают лимиты, ресурсные пулы и служба единого окна;

• зачем нужны теги, метаинформация и дашборды для владельцев бюджета;

• почему FinOps не всегда про экономию;

• как учитывать AI-затраты, GPU и новые инфраструктурные сценарии;

• куда может прийти FinOps через автоматизацию, алерты и LLM.

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

Смотреть выпуск
YouTube
Rutube
VK Видео

Слушать выпуск
Telegram Player (Mave)
Яндекс Музыка
VK Музыка

«Практики FinOps» — cообщество для тех, кто управляет затратами на IT-инфраструктуру и хочет обсуждать FinOps на практических кейсах. Мы в телеграм.

• без графического интерфейса — максимальная автоматизация;

• Stealth Mode, который скрывает признаки ИИ‑агентов. Так сайты не будут распознавать устройство как бота;

• использует лишь 30 МБ оперативной памяти;

• сам браузер весит около 70 МБ;

• грузит страницы за 85 мс;

• после запуска браузер готов к работе практически сразу без дополнительных настроек.

LAG часто воспринимают как простую и понятную вещь: объединили несколько линков — получили больше пропускной способности и отказоустойчивость. Но в реальности всё упирается не только в наличие агрегированного канала, а в то, как именно по нему раскладываются потоки.

Из-за этого и появляются знакомые инфраструктурные сюжеты: один линк забит, другой почти пустой; после изменения топологии поведение трафика меняется неочевидно; ECMP вроде есть, но равномерности всё равно нет; в VxLAN/EVPN-фабрике проблема становится ещё менее прозрачной.

7 июля в 20:00 на бесплатном уроке вместе с преподавателями-практиками разберём, как на самом деле работает балансировка трафика в сетях ЦОД: от LAG и хеширования до ECMP, vPC/MLAG и VxLAN/EVPN. Фокус — на том, какие решения в дизайне сети помогают избежать перекосов, перегрузок и сценариев уровня «всё упало, всё пропало». Присоединяйтесь.

Больше бесплатных уроков июля по инфраструктуре, сетям, разработке, AI и другим направлениям собрали в дайджесте — там можно посмотреть все темы месяца.

Творите, выдумывайте, пробуйте!)

В июне открыли новый регион Москва-3 и запустили там GPU-инстансы на базе NVIDIA Blackwell. Также запустили Free Tier для миграции с хостинга в облако вместе с ispmanager и поделились исследованием о тратах на GPU-серверы и кейсом аптечной сети «36,6». Ниже — главное.

Открыли регион Москва-3

Новая зона размещения работает в дата-центре Datahouse «Магистральный-1» уровня Tier III. У региона отдельный control plane и собственные вычислительные ресурсы, поэтому инфраструктуру можно масштабировать без риска перегрузить текущие мощности.

Запустили GPU-инстансы на базе NVIDIA Blackwell

В регионе Москва-3 ввели в эксплуатацию GPU-инстансы на архитектуре NVIDIA Blackwell. В основе — ускорители NVIDIA RTX 6000 Pro Blackwell Server Edition с 96 ГБ видеопамяти GDDR7. Доступны конфигурации до 30 vCPU, до 190 ГБ оперативной памяти и до 1,7 ТБ NVMe на инстанс, ресурсы тарифицируются по модели почасового потребления. По сравнению с A100 стоимость задач снижается до трех раз.

Запустили бесплатный облачный сервер для миграции с хостинга
Вместе с ispmanager запустили Free Tier — первый в России формат, где вместо тестового VPS пользователь получает бесплатный облачный сервер с панелью ispmanager и возможностью бесшовно масштабироваться в основной инфраструктуре Рег.облака. Конфигурация включает 1 виртуальное ядро, 1 ГБ оперативной памяти, 10 ГБ на NVMe-диске, публичный IPv4 и резервное копирование, с возможностью расширения мощности в два раза по запросу. Формат рассчитан на владельцев сайтов, интернет-магазинов и небольших проектов без опыта администрирования серверов — особенно актуально на фоне ухода cPanel и Plesk с российского рынка. К программе Free Tier уже подключилось более 1800 компаний и частных пользователей.

Кейс: аптечная сеть «36,6» перенесла ИТ-инфраструктуру в Рег.облако
Компания перенесла инфраструктуру в Рег.облако и увеличила скорость бизнес-расчетов на 50%, сократив затраты на ИТ в 1,5 раза. Переход на bare-metal серверы поднял производительность вычислительного кластера на 40%. В рамках проекта более 400 виртуальных машин мигрировали на выделенные серверы за 2 месяца без простоев, а время выполнения расчетов сократилось с 22 до 16 часов. Сегодня 2/3 инфраструктуры «36,6» размещено в Рег.облаке.

Исследование: траты на GPU-серверы выросли в четыре раза

За полтора года крупный и средний бизнес увеличил расходы на GPU-конфигурации вчетверо, при этом общее число серверов почти не изменилось. Компании переходят с бюджетных решений на более производительные — H200, H100, A6000.

Несколько цифр из исследования: доля премиальных GPU-конфигураций выросла с 51% до 78%. На конфигурации с видеопамятью до 24 ГБ приходится 46% спроса, на решения от 80 ГБ — 27%. Основные сценарии — ИИ и машинное обучение (33%), рендеринг (30%), тестирование и разработка (25%).

Желаем всем продуктивного месяца и спасибо, что следите за обновлениями Рег.облака!

Собрать данные с датчиков — это полбеды. Главная боль — заставить Kafka, PostgreSQL и ClickHouse стабильно работать в приватном облаке без выгорания команды на Day-2-операциях и ручном масштабировании stateful-сервисов.

На вебинаре покажем, как на Deckhouse Kubernetes Platform (DKP) и managed-сервисах упаковать IoT-сценарии и аналитический контур в единую платформу, чтобы снизить стоимость эксплуатации и уйти от DIY-подхода к data-инфраструктуре.

Зарегистрироваться на вебинар

В программе:

• Разберём схему event-driven-платформы и разделение операционного и аналитического контуров.

• Покажем live-demo: ingest событий с датчиков, потоковая обработка и вывод в дашборды.

• Проверим, как паттерны из умного дома масштабируются до промышленного IoT на DKP.

• Разберём жизненный цикл data-сервисов (backup, scaling, observability) и то, сколько времени занимает их обслуживание.

Бонусы: промокод на все курсы Deckhouse Академии.

Будет полезно DevOps и SRE-инженерам, инфраструктурным и платформенным командам, enterprise-архитекторам и всем, кто строит IoT- и data-платформы в private cloud или on-prem.

Спикер — Дмитрий Гайворонский, менеджер по развитию направления Deckhouse Data Orchestration.

Регистрируйтесь и подключайтесь 10 июля в 12:00 (МСК). 

Получите практические навыки по обнаружению и устранению неисправностей в системе резервного копирования.

09.07.2026 в 11:00 МСК проведем онлайн вебинар, на котором обсудим:

• Структуру и основные компоненты Кибер Бэкапа

• Функционирование компонентов системы

• Средства внутреннего мониторинга

• Назначение панелей мониторинга «Оповещения» и «Действия»

• Расположение журналов основных компонентов продукта

• Подходы к анализу и устранению проблем

Также покажем, как пользоваться этими инструментами на примерах типовых ошибок.

Ведущий: Егор Киселев, Инженер по сопровождению, Киберпротект

Зарегистрироваться

Принцип работы проекта: предоставляется ссылка на репозиторий, а инструмент сам анализирует проект: ищет Dockerfile, docker‑compose, package.json, requirements.txt, Go/Rust/Python/Node‑признаки, определяет тип приложения и пытается развернуть его в Docker. После запуска показывает локальный URL, контейнеры, логи и дает управлять сервисами прямо из TUI: старт, стоп, рестарт, удаление. По сути это автоматизированная оболочка над git clone, docker build, docker run и docker compose up, только с автоанализом проекта и удобным интерфейсом в терминале.

Важно: инструмент реально запускает код из чужих репозиториев, поэтому случайные проекты лучше гонять в VM/песочнице и внимательно смотреть Dockerfile/docker‑compose перед запуском. Сам Ghostprovider выглядит прозрачным, но риск всегда в том, что именно вы через него запускаете.

• решать на раз‑два более 30 видов капчи, имитирует поведение человека, чтобы обойти любые ограничения.

• ставится локально, в сервисе не надо регистрироваться и устанавливать дополнительное ПО..

Большинство крупных инцидентов происходят сразу после релиза. Не во время нагрузочного теста, не в случайный вторник — а именно тогда, когда команда только что что-то выкатила и выдохнула. Почему так, если всё прошло тестирование?

В новом выпуске «В SREду на кухне» вместе с Артёмом Гетманским, техруком юнитов в Авито, и Андреем Мухиным, TechLead из MWS, разобрались: что вообще считается релизом, чем он отличается от деплоя — и как не превратить каждое обновление в рулетку.

Что на повестке

Оказывается, релиз может сломать прод даже без единой строчки нового кода — и это не баг, а особенность современных систем. Разбираем, как Feature Flags, Canary, Blue-Green и Rolling-стратегии помогают снизить риск, когда hotfix тоже считается релизом и что с этим делать, и как error budget влияет на то, насколько смело команда вообще решается катить изменения.

Отдельно досталось вопросу, должны ли SRE участвовать в продуктовых релизах — и у участников выпуска на этот счёт нашлись весьма конкретные мнения.

🔵 VK Видео 
📺 YouTube
📌 RuTube
Ⓜ️ Mave

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

Мы упаковали наш опыт работы с десятками компаний из госсектора, финансов, ритейла, промышленности, НГХ и создали Сезон ИИ-инфры: пройдите весь путь к ИИ — от первичной оценки готовности инфраструктуры до конкретных решений и рекомендаций экспертов, которые внедряют ИИ в продакшн.

• утилита проверяет все источники, находит только проверенные и подбирает альтернативы при отсутствии файла на одном из них;

• показывает размер, количество сидов и запускает загрузку прямо из терминала;

• без регистрации. без ограничений.

https://github.com/vitaly-zdanevich/telegram_channel_to_static_website

Сайт генерируется через Zola.

Визуальный дизайн пока прост, минималистичен - без JavaScript. Чёрная и белая темы. Пагинация, теги, страницы. Свой CSS можно вставить через env.

Проект на Rust. Сделал через Codex gpt 5.5 xhigh.

Работает через GitHub Actions - раз в сутки перегенерирует весь сайт. Если пост изменился - он изменяется и на сайте - но в гите остаётся история.

Можно использовать и через cli - для бекапа.

Пока без использования ботов и API - через парсинг t.me - таким образом сохраняются даже короткие видео, но не аудио.

Линки на Ютуб превращаются в embed.

Комментарии пока не достаются, реакции тоже - потому что их нету на t.me

На Гитхабе и Гитлабе бесплатного места для статического сайта - гигабайт.

У меня около 1800 постов - отрабатывает за несколько минут

Определённые посты в канале - можно сделать страницами сайта. Как и заданные теги.

Пишите ваши фидбеки.

Собрали свежие статьи из нашего блога — те, что легко затерялись в ленте, но которые стоит дочитать до конца. Если на неделе было не до Хабра, вот короткий дайджест с самым полезным.

Ваш docker-compose.yml сломается: 5 настроек, которые все забывают
Локально всё крутится, на сервере неделю тоже — а потом Postgres съедает всю память, OOM-киллер убивает соседний сервис, а логи забивают диск. Всё лечится парой строк в compose-файле, но про них забывают: на машине разработчика они просто не проявляются. Разбираем пять настроек, без которых compose не доживёт до второй недели на проде.

Прощай, Fail2Ban: усиливаем защиту Netbird и Caddy с CrowdSec
Fail2Ban десять лет был золотым стандартом, но он реактивен: чтобы он сработал, атакующему сначала нужно постучаться в ваш SSH пять раз. А что, если блокировать вредоносные IP ещё до того, как их трафик дойдёт до сервера? История о переходе на CrowdSec с пошаговыми примерами кода — и о том, как «шум» от атак упал на 99%.

Разбираемся с форвардингом IP-пакетов в сетевых уровнях L2 и L3
Чем коммутатор отличается от маршрутизатора, зачем нужен TTL, как устроена CAM-таблица и почему без ARP ваш пакет никогда не доедет до получателя. Спокойный разбор основ, который наводит порядок в голове — для тех, кто хочет наконец перестать путать L2 и L3.

Self-service деплой: как перестать ждать DevOps и ускорить команду
Знакомая картина: разработчик полчаса висит в Slack, ожидая, пока кто-то накатит сборку на стенд. С ростом команды DevOps-инженер становится единственным шлюзом между кодом и продакшеном — и это горлышко съедает до 30% времени. Tech Lead рассказывает, как self-service платформа убирает узкое место, с кейсами Monzo и Spotify.

Kubernetes: архитектура и абстракции — полный гайд
K8s называют стандартом, но понимание его механик встречается редко. Control Plane и Worker Nodes, Pod, Service, Deployment, Namespace — «прожиточный минимум» абстракций, без которых нельзя выходить в прод. Плюс отрезвляющая история о том, как Tinder год переезжал на кластер из 1000 узлов и что у них при этом ломалось.

От capabilities к AppArmor: что реально остановит атакующего в контейнере
Уязвимость в веб-приложении, злоумышленник уже выполняет команды внутри контейнера — что именно его остановит? На одной и той же рабочей нагрузке показано, как последовательно срабатывают три слоя защиты: capabilities, seccomp и AppArmor. Где каждый помогает, где бессилен и почему работать они должны только вместе.

Хотите системно закрыть пробелы по инфраструктуре? Собрали большой дайджест по Linux, Docker, Kubernetes, CI/CD и сетевой безопасности: бесплатные уроки, практические гайды и курсы — всё в одном месте.

Домен можно сторожить по WHOIS: взял имя, посмотрел дату, повесил триггер «истекает через 30 дней». Но WHOIS видит ровно один домен и ничего вокруг. Он не знает, что на счёте кончились деньги, что висит неоплаченный счёт, из-за которого услугу снимут раньше срока, что в том же аккаунте ещё десяток доменов, SSL и хостинг. Поэтому я опрашиваю не WHOIS, а биллинговый API самого регистратора - он отдаёт весь аккаунт целиком. Собрал из этого шаблон под Zabbix 7.0, MIT. Расскажу, как он устроен и что в нём, на мой взгляд, сделано правильно.

Архитектура Три HTTP-айтема ходят в api.reg.ru - список услуг, неоплаченные счета и баланс - и складывают сырой JSON. Дальше всё считается из него: dependent items тянут баланс, сумму и число счетов через JSONPath, а LLD разворачивает прототипы под каждую услугу (ненужные типы отсекаются макросом-регуляркой). Каждая цепочка начинается с error_handler - битый или пустой ответ API не роняет айтем, а подставляет безопасное значение. На весь аккаунт получается несколько запросов в час, а не отдельная проверка на каждую услугу.

Что считаю правильным дизайном - две цепочки зависимостей Первое - nodata. Когда API регистратора отваливается целиком, каждый триггер «нет данных» (услуги, счета, баланс) хочет сработать сам, и ты получаешь пачку алертов про одну причину. Я завязал nodata услуг и счетов на корневой «No data from balance API». Полный отвал API теперь - один алерт, а не три. Корень я специально оставил без зависимостей, чтобы случайно не завязали и его, - об этом есть комментарий прямо в шаблоне.

Второе - сроки. На каждую услугу не один триггер, а каскад: ИСТЕКЛА (Disaster) → ≤7 дней (High) → ≤14 (Warning) → ≤30 (Info). Каждый уровень зависит от более тяжёлого. Поэтому услуга, которой осталось три дня, даёт один алерт High - а не три штуки (Info, Warning, High) одновременно. По мере приближения срока ты видишь ровно один триггер нужной серьёзности.

Для работы API, необходимо прописать разершенные IP в кабинете https://www.reg.ru/user/account/settings/api/, в настройках API задать адьтернативный пароль, и сохранить в макрос хоста {$RR_PASSWORD} как Secret. Логин - {$RR_USERNAME}. Для рег.облако взять API в https://cloud.reg.ru/panel/settings и сохранить в {$RRC_API_KEY}

Итог Баланс, неоплаченные счета и сроки всех услуг - под алертами в одном дашборде, без отдельного демона-прослойки. В репозитории два шаблона: разобранный выше под api.reg.ru (домены, хостинг, SSL) и отдельный под облачный api.cloudvps.reg.ru - там к балансу и срокам добавлен мониторинг самих VPS: реглеты, снапшоты, сети. Шаблоны, README и changelog - GitHub, PR и issues welcome.

А чем вы следите за биллингом у провайдеров и регистраторов - дёргаете API, или живёте на письмах «ваша услуга истекает»?

Когда часть сервисов находится в облаке, а остальное — в изолированных контурах, доставка серверного ПО и контроль лицензий превращаются в настоящий квест для команды DevOps.

На вебинаре расскажем, как собрать весь зоопарк решений в единую систему с помощью MWS B2B Store. Разберем деплой инсталляций, когда разные ноды находятся на разных инфраструктурных провайдерах, доставку и обновления в закрытых контурах, версионирование и распространение внутренних и внешних решений.

В прямом эфире в режиме демо покажем:

• Деплой сервисов (VMware + K8S) для разных сред, имплементацию Terraform as a service.

• Автоматическое развертывание в изолированные контуры: от стандарта упаковки до «раскатки» в гибридную инфраструктуру.

• Как управлять лицензиями на серверное ПО и контролировать, кто, где и сколько использовал.

• Работу с инстансами из разных инфраструктур в едином окне: мониторинг, аудит и управление жизненным циклом.

Будет полезно CTO, DevOps, директорам по инфраструктуре и тимлидам инфраструктурных команд.

📅 Когда: 30 июня в 11:00 мск.

📍 Где: онлайн. Зарегистрируйтесь, подключайтесь и задавайте вопросы нашим экспертам в чате трансляции.

Смотрим описание в переведённой документации:

Определяет представление планировщика об эффективном размере дискового кеша, доступном для одного запроса. Это представление влияет на оценку стоимости использования индекса; чем выше это значение, тем больше вероятность, что будет применяться сканирование по индексу, чем ниже, тем более вероятно, что будет выбрано последовательное сканирование.

Вот прямо с первых строк мозги выносит: при чём тут оценка (ОЦЕНКА!) размера дискового кэша и выбор между индексным или полным сканированием? Не знаю, кому как, но лично мне совсем непонятно.
Следующее, если effective_cache_size показывает оценку размера ДИСКОВОГО кеша (для меня одного словосочетание “дисковый кэш” означает “кэш файловой системы”?), то откуда взялась рекомендация в значение 3/4 размера оперативной памяти, если 1/4 - это shared_buffers? Рекомендатели, ау! 1/4 + 3/4 = 1, арифметика, начальная школа. А где СУБД должна выполнять манипуляции с данными? В свопе?
Всё остальное описание совершенно не добавляет ясности по использованию данного параметра, увы нам, постгресовым администраторам баз данных.

Но счастье есть, оно не может не есть, появилось более вменяемое описание этого параметра: All Your GUCs in a Row: effective_cache_size.

Кратко.
Главное. Данный параметр показывает ОБЩИЙ размер кэша: постгресовый shared_buffers плюс (плюс выделен жирным шрифтом в оригинальной статье!) кэш файловой системы. С этим уточнением рекомендация в 3/4 размера оперативной памяти выглядит приемлемой.
Следующее. Обсуждаемый параметр применяется для вычисления вероятности того, что однажды прочитанные данные будут находиться в кэше при повторном обращении в рамках ОДНОГО запроса. Т.е. для предпочтения соединения таблиц вложенным циклом (Nested loop join) при выборе методов соединения. Если высока вероятность того, что данных при повторном запросе в кэше не окажется, то будет выбрано либо полное сканирование таблиц(ы), либо сканирование по битовой маске, либо соединение хешем (hash join), либо соединение слиянием (merge join).
Далее. Этот параметр - верхняя оценка, завышенное значение не приводит к серьёзным проблемам (по крайней мере в статье об этом говорится).
Ограничение. effective_cache_size должен быть больше shared_buffers, ибо меньшее значение является бессмысленным (по статье).

Обновили ядро Linux на всех Ryzen-серверах в Москве

В копилку стабильности — и с конкретным обновлением под капотом.

Во время работы с высокопроизводительными серверами на Ryzen 7950X нашли причину редких зависаний нод. На старом ядре Ubuntu 22.04 эти процессоры могли работать нестабильно.

Это могло обернуться внезапной недоступностью виртуальных машин, хотя с самими проектами все было в порядке.

Чтобы устранить проблему, обновили ОС и ядро на всех Ryzen-серверах в московской локации.

Переезд выполнили поэтапно: сначала подняли резервные серверы, перенесли на них проекты и только потом приступили к обновлению основных хостов. Поэтому пользователи не столкнулись с простоем.

Теперь гипервизоры работают на новом ядре, а риски возможных зависаний нод осталась в прошлом.

Если вам нужны мощные серверы в Москве, есть еще одна новость — расширили парк Ryzen 7950X, чтобы было больше доступных конфигураций под ваши проекты.

Для поиска и отображения информации о фильмах и сериалах Streambert использует базу TMDB и для работы понадобится бесплатный API-ключ TMDB. Программа поддерживает русский интерфейс и субтитры, а также даёт возможность скачивать любые медиафайлы для офлайн-просмотра.

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

В программе:

• эволюция архитектуры Tantor XData и ключевые изменения в Gen3: независимое масштабирование подсистем вычислений и хранения, полноценная обработка смешанной нагрузки (HTAP) на едином наборе данных;

• новые возможности платформы и сценарии их применения;

• устройство и особенности распределенной СУБД Tantor Polar;

• организация вычислительных ресурсов и ресурсов хранения;

• инструменты управления и мониторинга.

Отдельный блок будет посвящён практической работе с машиной баз данных. Пройдем интерактив с реальным ситуациями, демонстрирующими преимущества новой машины баз данных перед классическими СУБД.

Эксперты мероприятия:

• Вадим Яценко, генеральный директор «Тантор Лабс»

• Сергей Серегин, руководитель технического пресейл «Тантор Лабс».

Когда: 30 июня, начало в 11:00 (онлайн)

Зарегистрироваться

Обычно всё растёт постепенно: сервисов стало больше, команды активнее используют инфраструктуру, появились новые тестовые среды, где-то добавились AI-нагрузки, где-то остались временные инстансы после задачи.

Потом приходит счёт, и начинается разбор.

— Кто создал ресурс?
— Он ещё нужен?
— Можно ли его выключить?
— Почему рост увидели только в конце месяца?
— Кто должен отвечать за такие расходы: финансы, инженеры, продуктовая команда или владелец сервиса?

На этом месте появляется ещё один вопрос, уже к рынку:

зачем облачному провайдеру помогать клиенту платить меньше?

На первый взгляд это конфликт интересов. Клиент оптимизирует расходы, провайдер получает меньше. Но в облачной модели всё устроено сложнее, чем простая связка «меньше потребил, меньше заплатил».

В новом выпуске «Практики FinOps» мы поговорили об этом с Александром Либкиндом, руководителем направления развития сервисов управления затратами в Cloud.ru.

О чём выпуск

Разговор получился не про разовые скидки и не про универсальный способ «порезать облако».

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

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

Какие вопросы разобрали

• почему FinOps в России развивается медленнее, чем на западных рынках;

• зачем Cloud.ru помогает клиентам снижать счета;

• где обычно находятся первые 15–30% экономии;

• почему отчёт раз в месяц плохо работает для управления затратами;

• чем FinOps для AI отличается от классического FinOps;

• почему автоматические рекомендации не решают проблему без владельцев ресурсов и процессов;

• как компании проходят этап Inform и почему на нём часто начинаются сложности.

Для кого выпуск

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

Смотреть выпуск:
YouTube
Rutube
VK Видео

Мы в телеграм. Подписывайтесь.

Эта неделя хорошо закрывает сразу несколько рабочих зон: инфраструктуру, backend, безопасность, ИИ, аналитику и управление. Темы подобраны так, чтобы за один открытый урок можно было не просто «послушать про тренды», а разобраться в конкретной задаче: от cache и swap в Linux до проектирования аутентификации, SRE-инцидентов, NLP и системного анализа.

Все уроки бесплатные и проходят с преподавателями-практиками OTUS — можно познакомиться с экспертами, протестировать формат обучения и задать вопросы по теме.

Linux, DevOps и инфраструктура

• 22 июня, 20:00. «Память в Linux. Cache, swap, dirty pages». Записаться

• 22 июня, 20:00. «Роль и задачи DevOps в современном IT». Записаться

• 24 июня, 20:00. «Инцидент-менеджмент в SRE. Как быстро находить, устранять и предотвращать сбои в системе». Записаться

• 25 июня, 19:00. День открытых дверей курса «Администратор Linux. Продвинутый уровень». Записаться

Backend и разработка

• 22 июня, 20:00. «Контейнеризация Java-приложений с Docker». Записаться

• 24 июня, 20:00. «RabbitMQ против Kafka — что выбрать для вашей структуры: сравнение и лучшие практики». Записаться

• 24 июня, 20:00. «Отказоустойчивый и высокодоступный кластер RabbitMQ». Записаться

• 25 июня, 20:00. «Кеширование в ASP.NET Core: от IMemoryCache до Redis». Записаться

Информационная безопасность

• 22 июня, 20:00. «OAuth 2.0, JWT и коварные куки: проектируем безопасную аутентификацию». Записаться

• 22 июня, 20:00. «Киберпанк для CISO — щит и меч ИИ». Записаться

• 22 июня, 20:00. «Анализ журналов событий ОС Windows». Записаться

ИИ, ML и NLP

• 22 июня, 20:00. «Продвинутое структурирование промптов: как получать предсказуемый результат». Записаться

• 22 июня, 20:00. «ИИ-агенты против младших разработчиков: кто кого заменит к концу 2026 года». Записаться

• 23 июня, 20:00. «Обзор инфраструктуры Ollama». Записаться

• 25 июня, 18:00. «Ландшафт современного NLP: от эмбеддингов и классических ML-методов до современных LLM». Записаться

Data, аналитика и базы данных

• 23 июня, 20:00. «ClickHouse: интеграция с Postgres, Kafka, S3 и Superset — готовые решения». Записаться

Системный анализ

• 24 июня, 20:00. «Внедрение новой функции системным аналитиком на примере услуги на Госуслугах». Записаться

• 25 июня, 20:00. «Какие навыки прокачать, чтобы стать экспертом в системном анализе в 2026 году». Записаться

Управление, продукт и Agile

• 23 июня, 20:00. «Как тимлиду победить синдром самозванца». Записаться

• 24 июня, 20:00. «Ретроспектива в Agile: что это, нужна ли она и как сделать её полезной». Записаться

• 24 июня, 20:00. «Топ-навыки менеджера продукта в 2026 году». Записаться

• 24 июня, 20:00. «Кто такой COO и почему он нужен сейчас». Записаться

Это только часть программы недели. Ещё больше тем, направлений и открытых уроков собрали в дайджесте — выбирайте то, что ближе к вашим задачам сейчас.

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

Host     homyak home house
HostName localhost
User     root

Будет обработан вот так:

Творите, выдумывайте, пробуйте!)

Многодоменная архитектура: почему бэкап одного домена не восстанавливает сервис

В инфраструктурных проектах иногда возникает идея разделить окружение на несколько доменов:

• пользователи – в одном контуре;

• серверы и рабочие станции – в другом;

• тестовая среда – в третьем.

На схеме это выглядит логично: сегментация, изоляция ошибок, разные зоны ответственности, поэтапная миграция без шуму и пыли.

Но в эксплуатации важен не только вопрос «где лежит объект».

Важнее другое: какие зависимости связывают объекты между собой.

Многодоменная архитектура не опасна сама по себе. Проблема начинается тогда, когда её начинают восстанавливать как набор независимых доменов.

Сценарий

Пользователь – в домене A.
Рабочая станция – в домене B.
Группа доступа к приложению – в домене C.

Цепочка доступа:

учётная запись → группа → DNS → доверие между доменами (Kerberos) → права на сервере.

Каждый компонент по отдельности может выглядеть исправным:

KDC отвечает. LDAP-серверы доступны. DNS разрешает имена. Билеты выдаются. Группа существует. Пользователь в группе.

А доступ к приложению всё равно не работает.

Почему? Потому что сломался не отдельный объект, а связь между объектами.

Именно здесь обычная логика «объект изменился → нашли резервную копию → восстановили объект» перестаёт быть достаточной.

В многодоменной среде важно уметь восстановить не только объект, но и связность: группы, доверительные отношения между доменами, DNS SRV-записи, Kerberos-зависимости и порядок применения политик.

Что стоит проверить заранее

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

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

• Контур восстановления – какие домены можно восстанавливать отдельно, а какие требуют жёсткой последовательности: например, сначала восстановить домен A, проверить состояние доверия к B и только потом тестировать доступ.

• DNS и Kerberos – понимаем ли мы, как после восстановления домены находят друг друга? Не разъедутся ли ключи на сервисах и контроллерах, если восстановление идёт из старого снепшота? При откате может измениться KVNO в SPN-записях, и Kerberos-аутентификация для ресурсов сломается, хотя формально всё «зелёное».

• Сквозной тест доступа – проверяем не только доступность серверов, а весь путь: пользователь из одного домена должен получить доступ к ресурсу в другом.

Главный вывод

Многодоменная архитектура – это не просто «удобно разделили контуры». Это более сложная эксплуатационная модель.

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

Иначе гибкость на этапе проектирования превращается в непрозрачность при первой серьёзной аварии.

Коллеги, тестируете восстановление всей цепочки доступа или только каждый домен по отдельности?

#Linux #Инфраструктура #Backup

В июне вас ждут еще три онлайн-встречи с экспертами Cloud.ru — о Spark, облачных расходах и Redis. Регистрируйтесь заранее, чтобы ничего не пропустить.

🎥Spark Connect для ИТ-команд: упрощаем разработку и работу с данными

Покажем, как сделать использование Apache Spark удобным для всей команды с помощью Spark Connect и Evolution Managed Spark. Затронем вопросы разработки в IDE, анализа данных в Jupyter и построения ETL на чистом SQL в dbt. Не бойтесь споткнуться о порог входа — здесь он минимальный. 

🧑‍💻 Для кого: дата-инженеры, аналитики, руководители дата-отделов.

📅 Когда? 23 июня 11:00 мск.

📍 Где? Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

🎥Как управлять расходами в облаке и не удивляться счетам

Разберем, как сделать облачные расходы прозрачными с помощью FinOps-инструментов. Вы узнаете, почему важно назначать владельцев ресурсов, как правильно выбирать тариф, выставлять автоматические квоты и настраивать алерты, чтобы сократить затраты на 20–30%. Всё — с живым демо в личном кабинете.

🧑‍💻 Для кого: ИТ-менеджеры, DevOps, финансовые директора.

📅 Когда? 25 июня 11:00 мск.

📍 Где?  Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

🎥Эволюция приложения в облаке: как настроить кеш с Redis и ничего не сломать

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

🧑‍💻 Для кого: бэкенд-разработчики, DevOps-инженеры, архитекторы.

📅 Когда? 30 июня 11:00 мск.

📍 Где?  Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

Привет, Хабр! 24 июня в 11:00 мы проведем вебинар о различных подходах к автоматизации.

Автоматизация — это способ сделать ИТ-ландшафт более прозрачным, управляемым и предсказуемым. На вебинаре разберем, как применять Terraform в zVirt, чтобы сократить объем рутинных операций, снизить риск ошибок и перейти к управлению инфраструктурой с помощью кода.

Что разберем:

- Различные подходы к автоматизации: когда и зачем нужен Terraform?

- Технический обзор: архитектура поддержки Terraform в zVirt

- Управление примитивами виртуализации: виртуальные машины, диски и сети

- Live-demo: от ознакомительных сценариев до устранения неисправностей

Кому будет полезен вебинар?

- Руководителям ИТ-инфраструктуры

- Системным инженерам

- Системным администраторам

- DevOps-инженерам

Участники вебинара первыми получат доступ к Cookbook zVirt Terraform — практическому гайду, составленному на опыте реальных кейсов управления комплексной инфраструктурой zVirt средствами Terraform.

Присоединяйтесь! Регистрация открыто по ссылке.

Метрики, лейблы, Prometheus, PromQL, Grafana, дашборды, алерты, каналы уведомлений. Тема мониторинга большая и сложная, но базовый пайплайн от сбора метрик до визуализации данных и настройки алертов можно разобрать за 60 минут. Этим и займёмся на вебинаре Deckhouse Академии на примере живого сценария.

• Разберём, как формируется метрика, что такое лейблы и кардинальность, а также как не допустить взрыва кардинальности.

• Рассмотрим, как Prometheus собирает данные и как начать собирать их со своего приложения, добавив три строчки в Deployment.

• Визуализируем метрику и покажем пример агрегации сырых данных с помощью PromQL.

• Создадим правило для алерта, настроим свой канал уведомлений и получим уведомление по агрегированной метрике.

Регистрируйтесь и подключайтесь 23 июня в 12:00 (МСК). После вебинара вы поймёте, как работает цепочка App → Metric → Prometheus → PromQL → Grafana → Alert, сможете подключить своё приложение к Prometheus без правки scrape_config, написать простой запрос на PromQL и настроить оповещения с защитой от шума.