Michael JohnsonAWS оголосила про CloudWatch Omni 22 вересня 2026 року, а 23 вересня зазначила, що сервіс став загальнодоступним. Це дві окремі події: оголошення та початок загальної доступності. Omni об’єднує спостережуваність застосунків і ШІ-агентів в одному середовищі, доступному через окремий вебінтерфейс та розширення для IDE, а також інтегрованому з CloudWatch. Про це AWS повідомила у дописі про запуск CloudWatch Omni.
Таке поєднання допомагає виявити проблему, яку легко пропустити у виробничому середовищі: запит агента може завершитися без звичайної помилки сервісу, але дати погану відповідь або спричинити вибір неправильного інструмента. AWS заявляє, що команди зможуть аналізувати трасування й оцінювання агентів разом із телеметрією застосунків. Практичне питання полягає в тому, чи будуть ці сигнали корисними у спільному робочому середовищі та які дані, права доступу й витрати супроводжуватимуть їх передавання туди.
Продукт охоплює більше, ніж трасування агентів
Omni — це розширення CloudWatch, а не його заміна. За словами AWS, наявні сповіщення, панелі моніторингу, API та робочі процеси в консолі CloudWatch продовжують працювати. Телеметрія, яку вже передають до CloudWatch, може відображатися в Omni без переналаштування; інші інструментовані робочі навантаження можуть надсилати дані через протокол OpenTelemetry (OTLP). AWS також описує виявлення сервісів і мапування залежностей, а також простори, у яких за відповідного налаштування можна об’єднувати телеметрію з різних облікових записів і регіонів. Це описано в документації CloudWatch Omni.
Інтерфейс доступний не лише в консолі керування AWS. AWS пропонує окремий вебінтерфейс із єдиним входом, а також розширення для IDE VS Code, Cursor і Kiro. У повідомленні про випуск від 23 вересня зазначено, що сервіс загальнодоступний у регіонах Схід США (Північна Вірджинія), Захід США (Орегон) і Європа (Ірландія). Перш ніж закладати Omni в архітектуру виробничого середовища, командам варто перевірити підтримку потрібного регіону.
Для агентів AWS описує дослідження трасувань, оцінювання й експериментування з використанням таких фреймворків, як OpenAI Agents SDK, LangGraph, CrewAI, Vercel AI SDK і Strands. Під час дослідження застосунків користувачі можуть ставити запитання природною мовою або безпосередньо аналізувати телеметрію; AWS зазначає, що функції дослідження за допомогою ШІ працюють на основі DevOps Agent. У дописі про запуск функцій для застосунків також сказано, що DevOps Agent за замовчуванням увімкнений у кожному сеансі дослідження Omni. Адміністраторам варто враховувати цю поведінку під час оцінювання робочого процесу.
Чому об’єднання сигналів може бути важливим
Звичайний моніторинг може показати, чи відповідає сервіс, скільки часу це займає та чи повертає він помилки. Однак він може не виявити, що агент неправильно зрозумів запит, вибрав невідповідний інструмент або надав хибну відповідь. Перегляд результату оцінювання разом із трасуванням і сигналами застосунку може допомогти команді простежити проблему з якістю до конкретного етапу виконання агентом завдання.
Це потенційна операційна перевага, а не підтверджений результат підвищення ефективності. У матеріалах про запуск AWS описує об’єднаний робочий процес, але не доводить, що він дає змогу усувати інциденти швидше, ніж наявні інструменти. Командам потрібно перевірити, чи допомагають оцінювання та дослідження в Omni на їхніх робочих навантаженнях.
OpenTelemetry може спростити передавання телеметрії з наявних засобів інструментування, однак спільний протокол не робить платформи спостережуваності взаємозамінними. Специфікація OTLP визначає спосіб передавання телеметрії; командам усе одно потрібно перевірити, від яких сигналів, запитів і специфічних для платформи функцій залежать їхні робочі процеси.
Централізація потребує налаштування
Omni може об’єднувати дані з різних облікових записів і регіонів, але не варто вважати, що саме ввімкнення інтерфейсу автоматично збирає телеметрію з усіх облікових записів. У документації AWS із налаштування описано створення доменів і просторів, а потім конфігурацію способу передавання телеметрії з кількох облікових записів до простору. Наявні дані CloudWatch можна переглядати без повторного інструментування, але організації все одно потрібно налаштувати бажаний доступ і потік даних. Детальні кроки наведено в посібнику з налаштування Omni.
Ця відмінність важлива і для розгортання, і для витрат. На сторінці з цінами AWS окремо вказує плату за отримання телеметрії, її зберігання й аналіз. Там також описано оплату за додаткові централізовані копії, тоді як перша централізована копія, згідно з опублікованими тарифами, безкоштовна. Вартість запитів залежить від обсягу просканованих даних і доступних квот; оцінювання агентів тарифікується за ставками Amazon Bedrock AgentCore Evaluations. Тож для корисної оцінки потрібно врахувати обсяг даних, строк зберігання, шаблони запитів, кількість копій і частоту оцінювання, а не лише кількість агентів.
Вміст трасувань і доступ потребують перевірки
Трасування агентів може містити запити, відповіді, отримані документи та персональну інформацію. AWS зазначає, що Omni автоматично не виявляє й не приховує персональні дані. У рекомендаціях щодо захисту чутливих даних радять обрати місце фільтрації; приховування даних під час збору — це спосіб не допустити передавання чутливого вмісту за межі застосунку.
AWS також стверджує, що не використовує вміст клієнтів для навчання базових моделей або вдосконалення самого Omni. Однак це не означає, що вміст ніде більше не обробляється: деякі функції надсилають дані до таких сервісів, як Bedrock або AgentCore, а AWS документує міжрегіональний логічний висновок для функцій ШІ. Дані зберігаються в регіоні простору, але запити до ШІ можуть оброблятися деінде в межах того самого географічного регіону. Командам варто переглянути політику використання даних AWS та відомості про міжрегіональний логічний висновок, особливо якщо їхні політики обмежують місця обробки вмісту трасувань.
Контроль доступу потребує такої ж уваги, як і конвеєр телеметрії. AWS повідомляє, що учасники простору за замовчуванням можуть читати всю його телеметрію; області даних дають змогу обмежити, які рядки журналів і трасувань бачить учасник. Однак ці області не приховують поля всередині рядка, тож вони не замінюють приховування вмісту, який користувачі не повинні бачити. Докладніше про це йдеться в документації з обмеження видимості для учасників.
Зважений підхід до оцінювання Omni
Для команд, які вже використовують CloudWatch, обмежене тестування допоможе з’ясувати, чи корисне спільне подання застосунків і агентів в Omni для реального робочого процесу. Перш ніж надсилати трасування з робочих систем, визначте потрібні сигнали, налаштуйте фільтрацію, установіть правила доступу для облікових записів і регіонів та оцініть витрати на отримання, зберігання й аналіз даних, а також на оцінювання. Потім порівняйте результати створених досліджень і оцінювань із поточними процедурами реагування на інциденти.
Для організацій, які використовують інші платформи спостережуваності, запуск Omni — це привід оцінити робочий процес, але сам по собі не привід переходити на нову платформу. Omni наближає сигнали якості агентів до операцій із застосунками, однак цінність сервісу залежатиме від корисності досліджень, відповідності засобів контролю потребам і вартості потоку даних.
